lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri Jun 9 09:13:44 2006 From: net4n6 at gmail.com (E Mintz) Subject: 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@...ne.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 > > > >
Powered by blists - more mailing lists