Efficient Wi-Fi Phishing Attacks | Hacker News Reader

Efficient Wi-Fi Phishing Attacks

tripwire.com

86 pointssophron21 comments

Bad title, but it makes an interesting point. I knew I can just make a WiFi network with the same settings as the original and have phones automatically connect to it (I use this as pre-doorbell warning sometimes, waiting for my parents or girlfriend to connect when nearby), and I also know that I can read and modify their traffic at that point.

What I somehow forgot to consider is that when my phone autoconnects to a network (or attempts to), the AP owner or anyone nearby might also be able to crack the WPA2 password. Good thing it uses PBKDF2 because I know some terrible ones.

I don't have time to read the full spec now unfortunately (I might later). Does anyone know what parameters are used for pbkdf2, specifically the number of iterations?

> (I use this as pre-doorbell warning sometimes, waiting for my parents or girlfriend to connect when nearby)

That's such a great idea! Could you give more details of how are you doing that? Which tools did you use?

I turn my phone's hotspot on with the desired settings and run the following in bash (it runs Debian stuff in userspace using ru.meefik.linuxdeploy)

    tcpdump -i wlan0 -c 1 arp; aplay isd/media/0/*.mp3

This waits on the wifi interface for one ARP packet, which will surely come when a new device connects, and then plays some mp3 that's on my internal sdcard (hence the mountpoint "isd").

Not OP, but I have a cron job on a Raspberry Pi running every minute checking for known MACs with `arp-scan`. I then get an audible warning.

Would you mind posting a link to this utility? Sounds like an awesome tool!

+1 ... can we get a github repository on this.

Does the fact that iOS randomly changes the MAC address while scanning for networks affects this in any way?

No - `arp-scan` only works if someone is associated with your AP. If I was using `airmon-ng` or similar, then yes, iOS MAC randomization would affect performance. Although, once the phone connects to the AP, `airmon-ng` may still work.

Thanks for clarifying!

Similar here (OP here), just without the dedicated hardware.

Even worse, an attacker can broadcast a spoofed deauth packet so that it looks like it's coming from your router. Most consumer wifi equipment will deauth and then immediately reconnect, allowing the attacker to capture the '4-way handshake' for offline cracking. For some reason I thought AES-256 was somehow part of WPA2, but not 100% sure.

It's also interesting how much information your personal wireless devices give out. If you use a program like airodump, you'll usually see at least one or two client devices with a long ESSID probe list from various restaurants, coffee shops etc.

Incidentally, this is how I came to realise how google use wifi to 'improve location accuracy' (although technically I think it's resolution time): their mapping vans would have catalogued router mac addresses/BSSIDs and bound them to locations. So google know that if someone's phone can 'see' a certain router, they must be within 100m or so of <location>. So a GPS fix can happen much quicker...

As for how practical it is to crack a WPA2 passphrase: by far the best protection is a totally random password (one that wasn't supplied by the manufacturer). Once you get up to a 10-12 character password (that's totally random), cracking it will take an infeasibly long time. If you're interested, you should check out some of the conversation of the hashcat forums. Some of the folks there use a number of very sophisticated ways of 'shrinking the search space', like statistical analysis of big password DB dumps. It turns out most people use passwords like 'Camero87' or 'Mystreetname1987'...

Oh, and disable WPS.

It's PBKDF2 with SHA1, 4096 iterations and 32 bytes of output. That's relatively weak, and thanks to the defective structure of PBKDF2, an attacker will parallelise each output block.

Relatively weak indeed, as expected from a standard that wasn't made recently. Still, about 4000 times slower than a single hash, which adds about as much as adding two characters to the password if I'm not mistaken (assuming a random password, which they usually aren't, which gives roughly 94*94=9k extra possibilities -- a bit more than 4k but the same order of magnitude).

The number of iterations, if I recall correctly, is implementation-specific.

Good thing I always disable the newest Windows default themes in favor of the old 98 grey style. Unlikely they'd default to emulate that. But there's a lot of details from pixel gaps between the wifi popup to the wifi popup appearing automatically, etc etc that makes this very unfeasible for me at least knock on wood

There are plenty of other hacks I'd be susceptible to before this one. (Please black hats don't target me)

Edit: Would it be feasible to instead just mimic the target AP with a WPA2 passphrase, listen to connection attempt by target user, and when the first attempt at login fails, set your AP to that passphrase and let him/her through? It's not completely transparent, but I feel typoing your password is more acceptable as "normal" than a lot of layers of emulated graphics that has to convince your target at every stage.

How do you redirect to the phishing site, if you are currently browsing an SSL encrypted website without making it to obvious? Since you get an error message in the browser...

That is correct. However it's trivial for a MiTM attacker to perform an SSL stripping attacks when the victim is communicating with sites that support plain HTTP.

even with HSTS?

If a website employs the use of HSTS all traffic will be redirected to HTTPS, rendering the support for HTTP redundant.

Hmm, if you can control the plaintext network isn't there an NTP attack to reverse time and use old compromisable certificates or move it forward past hsts max age?

Yea, it's very possible I'd fall for that.

Reply on news.ycombinator.com