"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
