Message-ID: <Pine.LNX.4.58.0606072320530.32681@dione>
Date: Thu, 8 Jun 2006 22:48:18 +0200 (CEST)
From: Michal Zalewski <lcamtuf@...ne.ids.pl>
To: bugtraq@...urityfocus.com
Cc: full-disclosure@...ts.grok.org.uk
Subject: SSL VPNs and security


"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/

Powered by blists - more mailing lists