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”
@Chris
I can’t help what people call the wrong thing. True clientless involves no client-side software.
Go for it, drop in an SSL VPN to replace IPsec. I never said it wasn’t viable, it’s just a lot worse. You lose control over L4 and have to do a lot of finagling to do what a true VPN does (at L3). IPsec is only complicated because people think it is, but it’s far superior in terms of secure transport that covers a wide range of architecture and true transparency. From where I sit SSL VPNs will never replace IPsec from a number of angles. You’re only seeing it from a user access perspective, I see it from securing transport which SSL VPN is generally not very useful on a large scale. Try server to server and network to network. You think B2B connections are geared on SSL? Think again. IPsec is the mainstream VPN of choice for that.
Again, the posts are reviewed before they go up. If they’re that bad then they don’t fly. The post does stand on it’s own as a point-you-in-a-direction-to-make-your-own-decision. It’s not my fault if one makes a baseless argument before knowing the facts.
@Mortman
It’s pretty clear if the definition of clientless is not misinterpreted. It’s quick analysis, which means that the end reader might have to click through to gain understanding if they don’t already have that knowledge prior.
I don’t like SSL VPNs I stated it was my opinion, whether or not you believe my personal position based on my experience is your choice. I don’t need to prove it technically to anyone to feel any better about the statement. SSL VPN implementations are often times a bad hack — people want them to do things that a true L3 VPN will do. Do they work? Sure. Are they the right solution? For most of the architectures I’ve played my hand in they weren’t.
Don’t even get me started on GRE. Sure, it’s a “VPN”. But, when placed next to IPsec or SSL VPN people start to assume GRE has some sort of security functionality. It, however, does not.
You guys are easy to get riled up. What fun. 🙂
Meier,
No, I hadn’t read the CERT VU (I have since). But I’m a strong believer that the post should stand on its own, or you should save your time and ours, and just drop a link.
Unfortunately, I’ve heard many people describe full Java/ActiveX SSL VPNs as “clientless”, because there’s ‘no’ (actually minimal) client install process, and they’re playing up the ease-of-use aspect. When you’re educating, avoid feeding the (deliberate) confusion! “Your VPN server is a piece of crap!” is a very different message, with a different call to action, than “Your VPN server is probably misconfigured and unsafe — check it now!”
From where I sit, it looks like full SSL VPNs (with a lightweight client) are largely replacing IPsec VPNs, due to ease-of-use and IPsec clients’ incompatibility with each other.
True client-less VPN with all URLs being dynamically proxies and not proxying DNS is indeed a large problem. I don’t disagree with that. And yes, should someone catch a user in the configuration it can potentially reveal a huge amount critical data. However, this is no different that running with any number of patches missing for instance. There are workarounds which means it’s not the end of the world by any stretch of the imagination.
I hear you by what you mean by “game over” but that is not at all clear from your original post.
Making a blanket statement like SSL VPNs are rarely a good idea, is rarely a good idea :). There are a broad range of ways of deploying VPNs be it over SSL, IPSEC or even GRE. The devil is as usual in the details. If you’re going to make a claim like that, you have to support it up front, otherwise, it just looks like shallow thinking.
@Mortman
“Game over” is in context to the fact that if you’re using a true clientless setup and allow any URL to be dynamically proxied in this matter it would mean that you have just exposed any internal sessions (and the VPN session itself) through one misclick. I’m not sure you read the “If you implementation allows…” part. Because, yes, it is “game over” at that point – unless you’d like to trust all of your users all of the time.
SSL VPNs are rarely a good idea IMHO. I’ve done exhaustive RA architecture and wouldn’t agree with your statement that SSL VPNs are a “lightweight split-tunnel style”, because they can be used in other contexts. Likewise, an IPsec implementation can be split-tunneled, I’ve done them both.
Point is true (and I mean true – not Active-X / Java pushed clients) client-less VPNs *can* expose a considerable amount if not truly architected into the environment correctly. I see more done wrong than done right.
Dude, “game over” is a little melodramatic, as is the vulnerability notice from US-Cert. This is far from the first technology to violate same-origin-policy and it’s far from the last that will be in broad use. So what we need to focus on is what does it mean for us (security geeks and organizations in general) rather then getting trapped in hyperbole.
For starters, there are some reasonable workarounds, so clearly this isn’t game over by any stretch of the imagination.
Though the problem is technical in nature, the real issue is really about understanding how the technology works and how to properly deploy the technology. SSL VPNs were never intended to be a full on replacement for traditional exclusive gateway based IPSEC vpns, but rather a lightweight split-tunnel style VPN. As US-Cert suggests, the main workaround is to switch to how you handle things and reconfigure your VPN to only use this for trusted domains. This seems pretty straightforward and wouldn’t even require retraining end users and continues to allow your organization to get the value of hot-spots and remote access in a reasonable way.
Dave, Chris has a legitimate confusion, since the difference between these features isn’t always clear.
Pure clientless doesn’t use any sort of local agent… and is where this particular problem arises. There are also “clientless” SSL VPNs that download a Java or ActiveX agent, that may or may not be a problem.
Dave- can you look into it? If so, that’s something practical we can immediately advise clients on, since many of them think they are running clientless but are using the temporal agents.
I think you missed the point and need to read the VU Chris. Client-less != no-install-client (assuming you’re talking *Java* here, not *JS*). There’s a big difference.
Yes, but that’s not how I use our Juniper SSL VPN, and it’s not how I used to use the University’s F5 FirePass, although the FirePass was configured to allow accessing intranet pages through the FirePass as a prefix.
If you want to convince me that using Juniper’s ‘no-install’ client is unsafe, you’ll need to provide a bit more substance and detail. It doesn’t *look* like the browser treats all pages as coming from the SSL VPN webserver when I’m connected through it, but I cannot confirm right now because we don’t have the Snow Leopard compatibility update yet…
You did read the title, right? 🙂
Meier,
Just to clarify: Your beef is with the feature that lets SSL VPN users access the intranet through the VPN server in half-assed proxy mode, right — with the VPN server as a prefix in the URL bar?
Not saying SSL VPN technology is inherently broken, right?