Re: SSL VPNs and security



How about some real-world, application specific exploits?

SSL VPN is hardly a 'novelty' or 'recent' technology. I implemented my
first SSL VPN in '99 at a large financial, and it is still in
production, and secure

So, please show me an example of an actual compromise and I'll listen.
Otherwise, put up, or shut up!

-Erik




On 6/8/06, Michal Zalewski < lcamtuf@xxxxxxxxxxxx > wrote:
> "Web VPN" or "SSL VPN" is a term used to denote methods for accessing
> company's internal applications with a bare WWW browser, with the use of
> browser-based SSO authentication and SSL tunneling. As opposed to IPSec,
> no additional software or configuration is required, and hence, corporate
> users can use pretty much any computer they can put their hands on.
> [ Yes, this is a very bad idea, but often also a perceived business
> necessity. To counter the risk, some SSL VPN solutions may perform
> client-side security checks with the aid of an applet or control "not
> marked as safe". This is, of course, a silly and bypassable design,
> and has a side effect of teaching the user to click "yes" on
> scripting safety prompts. But I digress... ]
>
> [ These solutions are sold, among others, by Juniper, Nortel, Nokia,
> Cisco. The following observations are based on Cisco Web VPN (and your
> mileage with this and other vendors may vary).
>
> In their most basic operating mode, SSL VPN systems simply act as a HTTPS
> authentication and authorization proxy that relies on session cookies, and
> a URI-based request rewriting and forwarding engine. Such a configuration
> enables the user to access any HTTP or HTTPS based Intranet applications;
> web-based clients for some other protocols are also sometimes included.
>
> [ With the help of various controls and applets again "not marked as
> safe", SSL VPNs can also forward local TCP ports through that tunnel,
> if unsupported network protocols need to be used. ]
>
> A good example: let's say there's an user who wishes to access his
> corporate Outlook Web Access interface from a remote location. The usual
> URL for the intranet service is:
>
> http://owa/exchange/lcamtuf/inbox
>
> To access it over the Internet, that fellow needs to navigate to
> https://webvpn.foocorp.com/, enter his credentials, collect a session
> cookie, and then go to (or be redirected to) something along the lines of:
>
> https://webvpn.foocorp.com/http/0/owa/exchange/lcamtuf/inbox
>
> ...which, if the cookie validates, would be translated to the original URL
> and allowed to go through, with SSL VPN acting as a proxy.
>
> Commercial SSL VPNs are a fairly recent technology that has a considerable
> appeal to various corporations. Because of its novelty, however, in a
> typical setup it may be subject to several serious security flaws, unless
> very carefully designed.
>
> Possibly the most important problem is that web VPNs break the customary
> browser security model that relies on domain name separation for the
> purpose of restricting access to cookies and other objects. Browsers
> generally allow " foo.com" to interact with own cookies or windows, but
> prevent the site from accessing resources related to "bar.com". Yet
> through SSL VPN, they all may look the same:
>
> https://webvpn.foocorp.com/http/0/foo.com/serious_work
> https://webvpn.foocorp.com/http/0/bar.com/fun_and_games
>
> Because of this design, all pages displayed through a Web VPN interface
> are lumped together. Whenever a page (or just a HTML fragment) that can be
> controlled by the attacker is displayed by *any* of the applications
> behind Web VPN, Javascript can access:
>
> - Web VPN session cookie, which can be then passed to the attacker.
> This is equivalent to the attacker obtaining access to all protected
> systems and compromising Web VPN altogether. The threat could be
> mitigated by associating the cookie with client's IP, but such an
> approach is not always implemented, and is impractical with AOL and
> the likes.
>
> - Application cookies set by other applications. If passed to the
> browser (as some SSL VPNs do), these cookies are separated by the use
> of "path" parameter alone, which does not necessarily establish a
> browser security domain boundary. This is equivalent to the attacker
> obtaining user credentials to these applications.
>
> Some commonly used corporate applications may indeed serve
> attacker-supplied contents, making these attacks virtually inherent to
> most SSL VPN deployments:
>
> - Various web mail systems, such as Outlook Web Access (OWA),
> may serve HTML attachments and other documents received from the
> Internet without providing an adequate browser warning. Although
> this is a security challenge by itself for all web mail interfaces
> (where there is a risk of stealing web mail session coookie),
> the access to all SSL VPN cookies make the impact far more serious.
>
> - Trivial cross-site scripting flaws in *any* available intranet
> application may compromise the entire SSL VPN. Because these
> applications are usually complex, aplenty, and all under-audited,
> existence of such bugs is pretty much a certainty.
>
> - Trivial cross-site scripting bug in SSL VPNs themselves may endanger
> the entire system. Impossible? Cisco SSL VPN has this:
> https://<vpnhost>/webvpn/dnserror.html?domain=<u>foo</u>
> (and yes, they seem to be aware of this, but have no specific
> timeline for fixing it - so I suppose it's OK to report it;
> hi Larry Seltzer).
>
> [ The possibility of allowing Internet access through Web VPN is
> something I wouldn't even consider here. ]
>
> Additional problems may arise when SSL VPN gateway IP is added to "trusted
> zone" for the purpose of making certain intranet applications work the way
> they worked locally at the office.
>
> Yes, these problems are hardly new, and can be mitigated with some very
> careful design, and some vendors may be doing it properly - but I think
> that the following needs to be said:
>
> - SSL VPNs may easily turn negligible and common security issues such as
> XSS into a considerable corporation-wide threat; and preventing this
> is hard.
>
> - Most SSL VPNs may be "secure by design" only in fairly unrealistic
> situations or limited uses.
>
> - Unless the vendor takes the effort to precisely and honestly explain
> how they mitigate these specific threats, it is safe to assume they
> might be not doing it properly (or not doing it at all).
>
> Since these issues are generally not seriously discussed by vendors in
> assessments of their products (say,
> http://www.cisco.com/web/about/security/intelligence/05_08_SSL-VPN-Security.html),
> I would assume that extreme caution needs to be exercised.
>
>
> Flame on.
>
> Regards,
> /mz
>





Relevant Pages

  • [Full-disclosure] SSL VPNs and security
    ... In their most basic operating mode, SSL VPN systems simply act as a HTTPS ... enables the user to access any HTTP or HTTPS based Intranet applications; ... browser security model that relies on domain name separation for the ... all pages displayed through a Web VPN interface ...
    (Full-Disclosure)
  • SSL VPNs and security
    ... In their most basic operating mode, SSL VPN systems simply act as a HTTPS ... enables the user to access any HTTP or HTTPS based Intranet applications; ... browser security model that relies on domain name separation for the ... all pages displayed through a Web VPN interface ...
    (Bugtraq)
  • [Full-disclosure] Re: SSL VPNs and security
    ... SSL VPN is hardly a 'novelty' or 'recent' technology. ... The following observations are based on Cisco Web VPN (and your ... > enables the user to access any HTTP or HTTPS based Intranet applications; ... > purpose of restricting access to cookies and other objects. ...
    (Full-Disclosure)
  • [fw-wiz] Re: SSL VPN vs. IPSec VPN
    ... >SSL VPN vs. using IPSec VPN for remote access to our corporate office. ... push regular network traffic over this connection. ... Provide access to "legacy" applications through "webification", ...
    (Firewall-Wizards)