SSL VPN detection

[SpaceHonkey]

Ok, all you pro security nuts. How/(can) do you handle detecting SSL VPNs? For instance, using my SSL Explorer setup here at the house, I can easily punch a hole right through any proxy I've tried, allowing me to say browse the net unfiltered, upload files, download files, even create a bridged vpn connecting both networks. On one hand SSL VPNs are great for businesses to allow them to secure access to internal resources easily, but when turned around they pose a security nightmare because the traffic is inherently trusted. All you need is a browser and possibly java.

I've only thought of 2 solutions. First, a snort rule that looks for an abnormally large amount of traffic via a 443 session. The problem here is that your only able to catch it after the fact, and after X amount of data has already been transmitted. Only a few KB would be needed to say infect the host, so this isn't a good solution. Another that would work against my situation would be to look for unsigned certificates. Not even sure how to go about that, but I'll bet some way exists to do this on the fly. But then again, if I wanted to spend $30, I'm in the clear again. The other thing already in place is black listing, however, homebrews are not by nature, so again, fail.

Thoughts?

 

[Captain Colonoscopy]

just block all 443 traffic!

Seriously, I'll have to try that through an astaro box. I have used Astaro to successfully block anonymous web proxies and LogMeIn/GoToMyPC, etc. I haven't specifically tried an SSL VPN yet.

 

[SpaceHonkey]

Well actually, that might be the only solution - but in most cases too restrictive. You could have good business reasons to let such traffic through.

I won't say where I've seen it work, but it's appalling that it seems to work anywhere.

Just goes to show that if you've got physical access, you've got full access.

 

[klbennet]

If you have the configuration of your machines locked down then you can point the Java proxy settings to a proxy that requires authorization. Then if there is a business need for a group of users to use Java to connect to the internet they can ask for access.

This only covers the Java agent part of SSL Explorer, you can tunnel some things without using the agent (webmail comes to mind, but there are other situations). I have seen this work in some environments. I have not investigated enough (nor do I intend to in this instance) to see what the settings are, where they are or how well they are protected.

This does not protect against rogue machines that you did not configure, but there are other options for that.

 

[SpaceHonkey]

If you have the configuration of your machines locked down then you can point the Java proxy settings to a proxy that requires authorization. Then if there is a business need for a group of users to use Java to connect to the internet they can ask for access.

This only covers the Java agent part of SSL Explorer, you can tunnel some things without using the agent (webmail comes to mind, but there are other situations). I have seen this work in some environments. I have not investigated enough (nor do I intend to in this instance) to see what the settings are, where they are or how well they are protected.

This does not protect against rogue machines that you did not configure, but there are other options for that.

I agree, but even if the JVM is going to a proxy, the data is encrypted. Similarly the web proxy may require it also, but again, encrypted.

You may know who (or what account) is doing the talking, but it does not prevent it from happening in the first place.

SSH tunnels are much easier to block, because you can easily detect the type of traffic, even on non-standard ports. The SSH handshake states clearly its intentions.

SSL however in most environments inherently trusted. Maybe this should no longer be so.

I thought of two other ways to approach this. Neither of which are unfortunately practical (yet). First mandatory weighted pseudo random number generation algorithms on client machines. Sounds complicated, but it's actually a pretty simple concept. Encryption requires use of pRNGs. If you use an algorithm that has a kind of 'master key', you could then guess with relative certainty the generated numbers. Using this knowledge of sequenced random numbers, you can quickly decrypt any encryption scheme using them. The NSA as a matter of fact proposed and successfully conviced adoption of such an algorithm, however they neglected to mention the whole back door part. Vista SP1 includes this algorithm. And of course rogue clients are not forced to use this scheme.

Second would be to use a sort of SSL/TLS proxy (i.e. man in the middle). All TLS traffic would be forced through the proxy which would make secure connections on behalf of the client. The proxy would see it in the clear, and then could be sniffed and alerted as necessary. Actually this approach may be practical, but as of yet, I don't see a project set to do just this. Instead it's just a MITM exploit. I'll see if I can test it out.

 

[DragonNOA1]

What is the major thing we are all missing here? The user has rights to install software, whether it be SSL Explorer or LogMeIn. Deny Admins rights on the local box to normal users.

Edit: May I add that you can also start proactively blocking applications that you know of on the users' PCs. There are ADM templates for LogMeIn for example that blocks the install and transmission of info from/to LogMeIn. Maybe setup a policy that blocks the install of SSLExplorer.

 

[SpaceHonkey]

Sorry, let me restate the situation. I think you might have misunderstood where the ssl-explorer setup lives.

Good employee turned bad decides he wants to steal personal information/financial data/state secrets, whatever from his employer. He sets up ssl explorer on a server, OUTSIDE the corporate network, accessible via the internet. Goes to work the next day, browses to his ssl-explorer web page, authenticates and uses the encrypted secure tunnel to funnel anything he can pipe over IP out of the secure network.

The server is not on a blacklist, it looks like normal traffic, and is even encrypted. You don't need a covert usb key, hidden WAP, nothing. Just your setup on the outside, and a browser with net access.

Now do you see the potential problem?

I also figured out that a TLS type proxy simply isn't practical, though it would work. The issue is that all certificates have to be forged, and the (good) user would not know if the connection is truly trusted as you could only verify the cert signing path to your proxy.

 

[DragonNOA1]

I haven't tried SSL-Explorer. There is no client needed? I know some SSL VPN's use clients (like Cisco) and I know some that do not, sorry for the misunderstanding. So far the only thing I see that seems like it might work is blocking non-trusted certs.

Can't some IDS's scan inside packets to see traffic coming in/out on diferent ports? SSH over 443 for example. IDS's know the protocols so maybe their is an IDS that can block SSL VPN's? Just guessing there.

The very purpose of SSL VPN is what you are trying to block. Gonna be a tough one.

 

[SpaceHonkey]

I haven't tried SSL-Explorer. There is no client needed? I know some SSL VPN's use clients (like Cisco) and I know some that do not, sorry for the misunderstanding. So far the only thing I see that seems like it might work is blocking non-trusted certs.

Can't some IDS's scan inside packets to see traffic coming in/out on diferent ports? SSH over 443 for example. IDS's know the protocols so maybe their is an IDS that can block SSL VPN's? Just guessing there.

The very purpose of SSL VPN is what you are trying to block. Gonna be a tough one.

Really tough! Yes, IDS can usually easily see services on non standard ports, such as SSH over 443 - in that case because of the SSH banner. But since ssl vpns use ssl as the datalink layer so to speak, connections continue to look no different from any other ssl connection. And the IDS can't sniff it because it's encrypted.

I'm trying to hard to find a solution to this one, and I'm just not seeing it yet - I hoped one of you fellas figured it out already

I encourage you to test this. SSL Explorer is available for windows (or your fav platform), and takes all of 5 minutes to setup. They dropped open source support, but the enterprise version lets you try for 30 days. I've tested it through what should be VERY secure networks, and it works everytime. Scary.

It really looks like the best way to prevent this kind of thing is to segregate the data from possible access in the first place. But still even in that case, you can use it to get unfiltered net access, leaving you vulnerable to stupid browsing consequences.

I'll keep looking...

 

[DragonNOA1]

I just thought of this, and it doesn't work everytime, but we have Websense block "Web Hosting" which blocks many people's homemade websites hosted at the facility (like hosted at Go-Daddy) and hosted at home. If SSL-Exporer connects back to a webpage on the users network like you say then it may get blocked. And who knows, it might get blocked by another category also. I'll have to test it out on our network and see.

 

[SpaceHonkey]

Please do test it. To date websense has not been able to detect it, and lets it through a-ok. From what I understand, websense can't detect SSH over nonstandard ports either. Very interested in your results.

 

[Hunterzyph]

Almost all SSL VPN solutions have an HTTPS header in them that broadcasts their function, and can thusly be blocked. Contact the developer or dig up the necessary documentation and drop it into your filtering.

 

[SpaceHonkey]

Almost all SSL VPN solutions have an HTTPS header in them that broadcasts their function, and can thusly be blocked. Contact the developer or dig up the necessary documentation and drop it into your filtering.

Well offhand, I don't see anything in the header that broadcasts it's function. I checked using http://web-sniffer.net/, and didn't see anything identifying itself overtly. Conversely using the same tool on Gmail, nothing popped out there either. Could you can point me to what I should be looking for?

 

[MorfiusX]

At a hospital I was recently at, they used Websense. They allowed 443 traffic, but only to classified sites. Your SSL explorer machine would fall into the unclassified section and would not be allowed through.

 

[SpaceHonkey]

At a hospital I was recently at, they used Websense. They allowed 443 traffic, but only to classified sites. Your SSL explorer machine would fall into the unclassified section and would not be allowed through.

Please keep the ideas coming, but here is the conclusion I've come to so far.

Setup: On the internet - an SSL VPN based solution. Products like OpenVPN, SSL Explorer, Hamachi, Juniper SSL VPN hardware, F5 Firepass hardware and any number of programs providing SSL tunnels. Cost: Free - $$$$$. Setup via ports you think may be available. 443 is standard, any could be used, keeping in mind what is most likely to get out of the target network. Hiding in plain sight seems to work best.

On the internal network to be compromised: Any PC with internet access, if a JRE is installed, even better.

Threat: Anyone with access to the internet can establish a secure private tunnel to a remote server via the internet. Examples -

1. Unfiltered net access
2. Access to file shares on remote network (read+write)
3. Access to remote applications, with no installation footprint (portable firefox, RDP, Citrix, putty)
4. Port forwarding. Any number of things - playing TF2 for example, AIM, Skype.
5. Secure node. Both networks could be connected, with routes between the two.​

Response: Secure data! Prevent simultaneous access to confidential information and the internet. Look for SSL on non-standard ports. Implement a whitelist for sites that require SSL - establish a baseline of expected SSL traffic, investigate such traffic (identifying business need), create a clear policy on how to amend sites to/from the whitelist, and lock it down. Baseline your network, and investigate threats. Most importantly, spread the word. Inform those in power of such threats and advise a solution.

I know many of you might think that this is a non issue, but I encourage you to test (with permission) on networks that are supposed to be secured if this works. I will not go into detail about networks I've found vulnerable, but I will say that very large companies with a lot to lose have underestimated this threat. I hope you all have found this information informative, and thanks to everyone that continues to provide insight on the situation.

 

[MorfiusX]

Please keep the ideas coming, but here is the conclusion I've come to so far.



I know many of you might think that this is a non issue, but I encourage you to test (with permission) on networks that are supposed to be secured if this works. I will not go into detail about networks I've found vulnerable, but I will say that very large companies with a lot to lose have underestimated this threat. I hope you all have found this information informative, and thanks to everyone that continues to provide insight on the situation.

Websense FTW! It really is a great product. The new Websense express costs under $30 per user per year which is very reasonable. When I implement it for customers, we usually try to classify users. Basic users only get to whitelisted sites, intermediate users only get access to approved categories, and exceptions don't get any blocking except for offensive material (aka executives).

The point is, a secure environment is easily achievable. The biggest roadblock I run into is not the technology, it's the politics of an organization.

 

[DragonNOA1]

and exceptions don't get any blocking except for offensive material (aka executives).

You know the latest round of viruses and malware target specifically executives. They get the most privileges but it doesn't mean they are the smartest users.

 

[MorfiusX]

You know the latest round of viruses and malware target specifically executives. They get the most privileges but it doesn't mean they are the smartest users.

Oh, it's not by my choice. We recommend everyone get the same privileges, but most executives have an "everyone but me" mentality. In my years of doing installs, only a few customers had the rules apply to the top brass. In the end, the customer purchased the products and we implement how they wish.

 

[SpaceHonkey]

The point is, a secure environment is easily achievable.

Oh please don't say that. Websense alone cannot detect SSH tunnels, hence the need for a very comprehensive multifactor solution. Did I mention that firewire by design gives you direct access to memory? Think that full drive encryption is safe? Not if it's turned on and authenticated. Heck, you can even unlock a secure windows screensaver via firewire. USB flash drives on windows by default autoplay. Who wouldn't check out that flash drive they found by the door walking into work? I recently read an article in 2600 about using the LD_PRELOAD environment variable to hijack dll function calls. The author was able to easily write an exploit, allowing quick access to the GPG passwords on the 'secure' GPG signatory box he was asked to infiltrate. WTF is ld_preload? I know now...but I didn't know before. And let's not forget the biggest threat to any organization - stupid users.

The reality is that complete security is a utopian idea, and we have to continue to be on our toes to try to get to that point knowing that we will always be behind. I'm trying to do my part by raising such issues on this forum, in the hopes that people make security a way of life instead of a reactive solution to threats.

 

[MorfiusX]

The reality is that complete security is a utopian idea, and we have to continue to be on our toes to try to get to that point knowing that we will always be behind. I'm trying to do my part by raising such issues on this forum, in the hopes that people make security a way of life instead of a reactive solution to threats.

You have really just proved my point. You, the engineer, know what needs to be done. That, in my experience, isn't the biggest hurdle. The biggest hurdle come from the top in deciding whether or not to implement those security measures.

The first thing you learn about security is that nothing is 100% secure. That's a fact of life. I probably should have qualified my statement a little more, so I will do that now. "A relatively secure environment can be achieved with a minimal amount of effort if those changes are permitted by the deciding parties."

I often tell people that there is a balance to everything. Security is balance by accessibility. The more secure something is, the less accessible it will be and vice versa. If you really want a 100% secure computer, use pen and paper....