Clientless SSL VPNs expose corporate users to attacks
Cli
This security problem, discussed since at least 2006, could let an attacker could use these devices to bypass authentication or conduct other web-based attacks. Clientless VPN products from Juniper Networks, Cisco Systems, SonicWall and SafeNet are confirmed vulnerable.
The skinny:
By convincing a user to view a specially crafted web page, a remote attacker may be able to obtain VPN session tokens and read or modify content (including cookies, script, or HTML content) from any site accessed through the clientless SSL VPN. This effectively eliminates same origin policy restrictions in all browsers. For example, the attacker may be able to capture keystrokes while a user is interacting with a web page. Because all content runs at the privilege level of the web VPN domain, mechanisms to provide domain-based content restrictions, such as Internet Explorer security zones and the Firefox add-on NoScript, may be bypassed.
Clientless VPNs offer browser-based access to corporate intranets but US-CERT warns that they subvert the same-origin policy that prevents certain active content (JavaScript, etc.) from accessing to changing another site's data.
"Many clientless SSL VPN products retrieve content from different sites, then present that content as coming from the SSL VPN, effectively circumventing browser same origin restrictions," according to the advisory.
In one attack scenario, a malicious hacker can create a Web page that obfuscates the document.cookie element in such a way as to avoid being rewritten by the web VPN, then the document.cookie object in the returned page will represent all of the user's cookies for the web VPN domain.
US-CERT said this document.cookie can typicaly include the web VPN session ID cookie itself and all globally unique cookies set by sites requested through the web VPN. "The attacker may then use these cookies to hijack the user's VPN session and all other sessions accessed through the web VPN that rely on cookies for session identification."
Additionally, an attacker could construct a page with two frames: one hidden and one that displays a legitimate intranet site. The hidden frame could log all keys pressed in the second, benign frame and submit these keypresses as parameters to a XMLHttpRequest GET to the attacker's site, rewritten in web VPN syntax, US-CERT added.
The bigger problem here is that there is no solution to this problem. Depending on their specific configuration and location in the network these devices may be impossible to operate securely, the group said.
IT Administrators are urged to consider the following workarounds:
- Limit URL rewriting to trusted domains
If supported by the VPN server, URLs should only be rewritten for trusted internal sites. All other sites and domains should not be accessible through the VPN server.
Since an attacker only needs to convince a user to visit web page being viewed through the VPN to exploit this vulnerability, this workaround is likely to be less effective if there are a large number of hosts or domains that can be accessed through the VPN server. When deciding which sites can be visited through use of the VPN server, it is important to remember that all allowed sites will operate within the same security context in the web browser.
- Limit VPN server network connectivity to trusted domains
It may be possible to configure the VPN device to only access specific network domains. This restriction may also be possible by using firewall rules.
- Disable URL hiding features
Obfuscating URLs hides the destination page from the end user. This feature can be used by an attacker to hide the destination page of any links they send. For example, https://<vpn.example.com>/attack-site.com vs https://<vpn.example.com>/778928801