Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: SSL VPNs and security
From: "E Mintz" <net4n6 () gmail com>
Date: Fri, 9 Jun 2006 02:19:28 -0400

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 () dione ids pl > 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
>



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault