2

We are thinking about giving an awareness live demonstration in the company I work for. The general idea is to show the users how can they be hacked while connected to a public wifi spot such as a coffee shop, conference, etc. We have thought about:

  • Using a rogue AP
  • ARP spoofing
  • DNS cache poisoning

Can anyone suggest other attacks/ways of better tacking this demonstration? We want the users to better understand the impact of connecting both personal and corporate devices to public/unknown networks.

  • One very simple example would be to call your Windows machine "wpad", setup a web server on it, e.g. IIS and host wpad.dat at the root, so you have an accessible file, e.g. wdpad/wpad.dat. In the wpad.dat you have function FindProxyForURL(url, host){return "PROXY 192.168.0.41:8080";} Where the IP is that of your computer on the network. Then run a proxy on your computer on port 8080. BurpSuite is a simple example. Clients which default to autodetect proxy, will pull the wpad.dat from your computer and you'll be their proxy so you can see all the requests. It's basic but one example. – HelpingHand Apr 25 at 21:47
4

In practical terms there are three threats I'd be worried about:

  1. Passive monitoring by network owner/other users on the network
  2. Direct exploitation by network owner/other users on the network
  3. Active man-in-the-middle attacks such as Karma and sslstrip

If you haven't already, I'd recommend simply adding Wireshark to your demonstration, and showing a capture of someone logging into a website over HTTP (if you can find one, or create one). This will show how trivial it is to sniff sensitive information from a shared network if the connection isn't encrypted.

For threats #1 and #3 above, a good trusted VPN service (e.g.Encrypt.me or NordVPN) will mitigate these risks. For #2, keep your devices and applications up-to-date.

However... I'd argue that there is a bit too much hysteria about the risk of using public WiFi.

Most of the legitimate concern about public WiFi began because of #3, particularly before HSTS became a thing. Back then it was possible to use sslstrip against major banking sites and other valuable services (Google, Facebook), and the only real mitigation was "don't join non-password-protected WiFi networks", or to use a trusted VPN at all times. Now that HSTS is available this is much less of a problem (for those sites which support it), although it's still a good idea to use a trusted VPN if you're worried about local MITM attacks of this sort.

For most users, #1 is a non-issue as the services they're worried about would be using HTTPS. The major exception is that DNS requests are still in-the-clear in most cases (users might not want someone on their network knowing that they're making DNS requests for pornhub.com). A trusted VPN will solve this problem.

Direct explotiation (#2) is also a non-issue for most users unless they're using very outdated software (i.e. running unpatched Windows 7 or an obsolete Android device), or unless their threat model includes attackers with 0-day remote code exec exploits (if this is the case, they likely have bigger problems than connecting to public WiFi).

  • The password protection on a wifi network is not a guarantee that there's no MITM. Also, anyone knowing the PSK can decrypt the communication. – Esa Jokinen Apr 23 at 4:54
  • Unencrypted DNS is a problem because the replies are not signed: it's easy to replace them with anything. It's not that interesting for surveillance purposes, because you can get the same information from TLS SNI headers, and it's even more accurate, because there's no caching as in DNS. – Esa Jokinen Apr 23 at 4:58
  • 1
    It's not only nation states which will throw a 0day at you... – forest Apr 23 at 6:40
  • 1
    and the only real mitigation was "don't join non-password-protected WiFi networks" This was never a real mitigation. If you are using a shared network, even if it is encrypted using WPA2, does not protect others on that network from performing MITM attacks. This is because WPA2 does not use asymmetric key exchange. – forest Apr 23 at 6:44
  • 1
    @forest I've reworded the last point. I was being flippant, but as you say it reads as if I'm claiming only nation states have access to 0day. Thanks for the correction. – markeldo Apr 23 at 7:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.