Good job! You paid tens of thousands of dollars for that shiny new name-brand VPN, and then decided to deploy its web VPN functionality because, well, it was just easier than deploying software clients.
An underpinning of common web security that dates back to Netscape Navigator 2.0 is the “same origin” policy for JavaScript. Your clientless SSL VPN intentionally breaks this, and that’s considered a feature.
What does this mean for you? If your implementation allows dynamic URL rewriting (i.e., end users can put in any URL and have the web VPN fetch it) it’s GAME OVER, since every website a user views through that service appears to come from the same domain – your trusted VPN server. This is worst-case, but there are many other scenarios where an attacker could set up shop to exploit the session, especially if the end user is on a public network where DNS is compromised. There are a bunch of ways to exploit this, especially in multi-step attacks when the bad guy can get on the internal network (easy enough with malware). Don’t be surprised if this shows up in BeEF (a comprehensive tool for exploiting browser vulnerabilities) soon.
Friends don’t let friends connect clientless – fix it the right way. Read the US-CERT vulnerability note for more detailed information. You can mitigate many of the potential problems by only authorizing the SSL VPN to manage traffic for trusted domains, and avoid tunneling to random destinations. If it’s a full SSL VPN product with a re-browsing feature, turn that capability off!
Oh, not to add to the confusion, but Sun’s JRE is also recently vulnerable to same origin policy violations as well.
Reader interactions
12 Replies to “Serious Flaw in Clientless SSL VPNs”
Meier,
FWIW I agree that IPsec VPNs are stronger than SSL.
I agree that host-to-host and network-to-network VPNs are not going to switch — SSL would almost always be a mistake for such configurations. I’m more focused on the user side, because I don’t deal with the back-end stuff.
My point was that *user* VPN appears to be shifting rapidly away from IPsec. The client installation goes from finicky to almost-nonexistent, which is a big win for both users and the people who support them. Also avoids problems with incompatible IPsec clients.
Not riled here.
Dave,
Just because I reviewed it doesn’t mean I didn’t also screw up… we should have provided a bit more context. It seems *many* people are confused by the clientless definition, in large part because that’s what the vendors call it, even when it isn’t.
I think you need to explain the nuances of different SSL VPN implementations more- from full client, to downloaded/temporal client, to full clientless. Again, you are fighting marketing materials and documentation that confuses the issue, and we need to reflect how people *can* view the world, not just how they *should* read it. If Mort and Chris get confused, we clearly stated it poorly.
And yes- you always need to justify your opinion… we all do. Actually, it’s more showing people the basis of the opinion than pure defensive justification.
But the follow on post should clean it all up 🙂