Thursday

Dangerous hotspots and the caveats of IPSEC VPN tunnels



In a previous post, I mentioned that it's best to always use a VPN tunnel with strong authentication when using hotspots or other open unencrypted wifi networks. Well, its not without possible caveats.

Imagine you make a VPN connection but it's blocked by the hotspot infrastructure but you don't notice it. Bad GUI design or human failure, it doesn't matter. Your email client normally communicates to the corporate (SMTP) mailserver which is only accessible internally. Normally without VPN, this would not work. But let's imagine that the hotspot DNS resolves any unknown hostnames to it's anonymous SMTP proxy. Sending emails works just fine and you think you are sending it over a secure line! Euh, no you are not.

Fiction? No, this is exactly what happened to someone from Securiteam while staying at a hotel in Bejing (check their blogpost).

What could have prevented this?

  1. User noticing or checking connection status of VPN (but let's not rely on enduser actions). See point 5.
  2. Updating the corporate mailserver that it uses SMTP authentication (SMTP AUTH), preferably in combination with SSL/TLS for confidentially. Even if it's just an internal server.
  3. Deploying SSL VPN. Some hotspots might block IPSEC. It's a separate IP protocol besides TCP or UDP. But the HTTPS port used by SSL VPNs is almost never blocked. But if users ignore certificate warnings, they still might fall victim to a Man in the Middle attack.
  4. Using an IP address instead of a hostname in your email client settings.
  5. Educating users on how to use the software and what to do or not do in case of warnings. Write a FAQ!
There may be more and other possibilities to improve the security but these are the most obvious ones. From the design point of view of the hotspot, it makes sense to redirect smtp traffic to it's transparent proxy so that users don't have to change their SMTP settings all the time. Even IPSEC might not have been allowed because of government policies and the great wall of China. But this combination of circumstances can have an impact on the security of corporate hotspot users. I'm not going to mention any conspiracy theories here but it did came to mind (tin foil hat mode).

Even if it's not because of the behavior of the hotspot, it could also easily be done by ways of a man in the middle attack. Beware of transparent proxies!

So IPSEC is still a fairly secure solution but you might want to think about these scenarios and mitigate them.

Related posts:
(Photo under creative commons from dorywithserifs' photostream)

2 comments:

Anonymous said...

Would not a working split-tunnel implementation (or, rather, a VPN policy forbidding split tunneling at the endpoint) address this issue more elegantly?

Security4all said...

Problem is that that policy most of the time only is applied when the VPN tunnel has been set up. Otherwise laptops being on the internal lan wouldn't be able to use the network without VPN. In this scenario, it doesn't solve the issue.

Unless you can apply it only on the wireless adapter. Some solutions might provide something similar to what you are suggesting
but not all of them will be able to do it (interface specific).