A recent advisory from US-CERT has a lot of people who are thinking about deploying SSL VPN, or who have deployed SSL VPN, wondering if this is a good decision. There are a lot of articles on the subject, and many of them will leave you feeling like this is an unsolvable problem. But, there are a few (Dark Reading included) that do a good job of explaining exactly what the vulnerability is, and how to protect against it.
The core of the problem can be described quite simply. When a client (browser) connects to an SSL VPN, and then connects to ‘protected’ resources (let’s say your intranet page), the browser does not ‘see’ the connection to the intranet page. The browser is connected to the SSL VPN, and the data to the internal ‘protected’ site is proxied through the SSL VPN. All the browser ever sees is the SSL VPN, and all of the web sites the browser connects to ‘inside’ the SSL VPN look just like they are a part of it.
This is the problem. And the solution lies in the problem.
OK, so what exactly is the problem here. When the browser is connected to the SSL VPN a session is created, with cookies and other things set. If a malicious web site behind the VPN asks for a cookie the browser will send it. After all, the browser is not connected to the malicious web site, it is connected to the VPN.
The solution can be stated simply. Don’t let browsers connected to your SSL VPN connect to malicious web sites.
That may sound a little trite, but SSL VPNs have many mechanisms to help you prevent this kind of attack. Web ACLs can be used to only allow traffic to specific resources. Turn off the ‘address bar’ in the SSL VPN portal so that connected users cannot just browse around. Those are two simple steps you can take to limit the exposure of your SSL VPN to this kind of attack.
The thing is, this vulnerability is not really build in to the SSL VPN itself, but is dependent on how the SSL VPN is deployed. There is definitely a threat here, but this is exposure that can be mitigated with a well configured SSL VPN.