
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?
- User noticing or checking connection status of VPN (but let's not rely on enduser actions). See point 5.
- 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.
- 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.
- Using an IP address instead of a hostname in your email client settings.
- Educating users on how to use the software and what to do or not do in case of warnings. Write a FAQ!
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:
- Is it dangerous to know the most popular hotspots?
- Use NoScript to force websites to SSL
- Looking for Hotspots in Antwerp
- First court case for wifi stealing in Belgium
- Belgian Wireless drifter arrested
- Karmetasploit 3 documentation available. Karmetasploit = KARMA + Metasploit 3
- Forget wardriving, now you have warcarting and warballooning
- Netgear provides alternative opensource router
- Wireless Auditing Toolkits
- Rogue access point at Dutch Airport
- 50% of Belgian Wifi networks are unprotected
- Public Wifi at Blackhat and how to defend yourself

Security4all Blog
Twitter
Slideshare
Facebook
Digg
Flickr



2 comments:
Would not a working split-tunnel implementation (or, rather, a VPN policy forbidding split tunneling at the endpoint) address this issue more elegantly?
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).
Post a Comment