Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Become a Partner and License Our Database or Notification Service
Cisco WebVPN Input Validation Hole in 'dnserror.html' Permits Cross-Site Scripting Attacks
SecurityTracker Alert ID: 1016252|
SecurityTracker URL: http://securitytracker.com/id/1016252
(Links to External Site)
Updated: May 21 2009|
Original Entry Date: Jun 9 2006
Disclosure of authentication information, Disclosure of user information, Execution of arbitrary code via network, Modification of user information|
Vendor Confirmed: Yes Exploit Included: Yes |
A vulnerability was reported in Cisco WebVPN. A remote user can conduct cross-site scripting attacks.|
The WebVPN 'dnserror.html' and 'connecterror.html' scripts do not properly filter HTML code from user-supplied input in the 'domain' parameter before displaying the input. A remote user can create a specially crafted URL that, when loaded by a target user, will cause arbitrary scripting code to be executed by the target user's browser. The code will originate from the WebVPN device and will run in the security context of that device. As a result, the code will be able to access the target user's cookies (including authentication cookies), if any, associated with the device, access data recently submitted by the target user via web form to the device, or take actions on the device acting as the target user.
The clientless mode of the WebVPN feature of the Cisco VPN 3000 Series Concentrators and the Cisco ASA 5500 Series Adaptive Security Appliances (ASA) is vulnerable. The 'WebVPN full-network-access mode' is not affected.
A demonstration exploit URL is provided:
Cisco has assigned Cisco bug IDs CSCsd81095 (for the VPN3k) and CSCse48193 (for the ASA) to this vulnerability.
Michal Zalewski reported this vulnerability.
A remote user can access the target user's cookies (including authentication cookies), if any, associated with the device, access data recently submitted by the target user via web form to the device, or take actions on the device acting as the target user.|
No solution was available at the time of this entry.|
The Cisco Security Response notice is available at:
Vendor URL: www.cisco.com/warp/public/707/cisco-sr-20060613-webvpn-xss.shtml (Links to External Site)
Input validation error|
Source Message Contents
Date: Thu, 08 Jun 2006 22:48:18 +0200 (CEST)|
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:
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:
...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:
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
- 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
- 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:
(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
- 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,
I would assume that extreme caution needs to be exercised.
Go to the Top of This SecurityTracker Archive Page