In a recent vulnerability note, VU#261869, updated in mid-January 2010, The U.S. Computer Emergency Readiness Team (US-CERT) warned of a clientless SSL VPN vulnerability found in many products. This SSL VPN vulnerability could allow an attacker to bypass authentication mechanisms or conduct other Web-based attacks.
So what's wrong with clientless SSL VPNs? First, it's important to understand how these applications retrieve information. Many clientless SSL VPN products -- a list of vulnerable products is included in US-CERT's vulnerability note -- retrieve content from different intranet sites and then present a consolidated view of the content, as if it were coming from a single source: in this case, from the SSL VPN service. This conjoined content circumvents the Same Origin Policy, which is an important security concept for a number of browser-side programming languages, such as JavaScript.
The policy allows scripts running on pages originating from the same site to access each other's methods and properties with no specific restrictions, but prevents access to methods and properties across pages on different sites. Because the SSL VPN products don't require a strict separation of active content provided by unrelated sites being maintained on the client side, a loss of data confidentiality or integrity can result. This is an especially important concept as today's Web servers provide access based on the client's HTTP cookie information to reveal sensitive information or make state-changing actions.
How does an attacker exploit the vulnerability? There are really two ways attackers can take advantage of the security loophole created by clientless SSL VPN services. The first occurs if the VPN session is configured to access both safe internal domains as well as external domains. In this scenario, an attacker can construct a malicious webpage in the external domain that is designed to access all of the protected domains on the client-side Web browser; the attacker can also steal session cookies and hijack the user's VPN session. In the second scenario, an attacker constructs a page with two frames: one hidden and one that displays the targeted intranet site. As the user logs into the intranet site, the hidden frame logs all the end user's keystrokes in the second frame (including username/password information) and the hidden frame submits the keystrokes back to the attacker's site. The attacker can then open a clientless SSL VPN session to the intranet site and use the information collected to gain access to the secured applications.
So what can you do if you administer your organization's SSL VPN services? If you choose to continue to allow end users to access both internal and external sites via a clientless SSL VPN, there's really not much you can do on your own. Administrators should start addressing this vulnerability by going to their vendor's support website for direction. In response to the disclosure of this vulnerability, many of the vendors have issued responses and guidelines specific to their products.
If your product consolidates all the intranet sites into one virtual domain operated by the service, there's no workaround that can keep the users from going to any other site on the Internet and possibly landing on an attacker's malicious webpage. Because of this, administrators should make extra efforts to inform their end users of the threat, and ask them to limit their access to external websites when they connect to the organization's intranet. Also, of course, advising them of the benefits of keeping their antivirus and antimalware software up to date on their end system is always a good idea.
However, to minimize risk, a good practice is to configure clientless SSL VPN sessions so that only trusted internal networks are accessed using the VPN session. All other connections should be accessed without using the SSL VPN session, though this can be tedious for users who need access to internal applications and external domains simultaneously.
In the end, the only true fix for this vulnerability is to re-architect the way clientless SSL VPN services work, and this could be a long time coming.
About the author:
Randall Gamby is an enterprise security architect for a Fortune 500 insurance and finance company who has worked in the security industry for more than 20 years. He specializes in security/identity management strategies, methodologies and architectures.
