12

I am traveling on a train in Switzerland, working on a macbook connected to a wifi hotspot that I've set up on my Phone [1] using WPA2.

At some point along the journey, the internet connection drops. While I am wondering why, the OS asks me to reenter the password for the wifi. I find it strange (has never happened before), but I check the password on the phone (which, by the way, indicates good cellular reception) and enter it again on the macbook. I'm unable to connect.

I now change the hotspot settings on the phone, modifying the password and changing the SSID from "NX5TAL" to something temporary. I can connect to the new SSID without problems. Now, both SSIDs show up as available networks on my macbook. Some minutes later, the "NX5TAL" SSID disappears.

While this is probably not enough information to determine with certainty what happened, I am wondering: is this how a (failed?) wifi spoofing attack would look like from the victim's point of view?

[1] Google Nexus 5x, Android 8.1.0, security patchlevel Dec 5, 2017

Improve this question
2
  • 2
    Looks like an 'evil twin' access point.
    – t.m.adam
    Dec 10, 2017 at 21:12
  • It's very hard to prove this... if your question is "Is it possible that someone tried to spoof my wifi network" the answer is yes. But did this really happen? Nobody can be 100% certain.
    – Bakuriu
    Dec 10, 2017 at 21:37

1 Answer 1

Reset to default
13

While this is probably not enough information to determine with certainty what happened, I am wondering: is this how a (failed?) wifi spoofing attack would look like from the victim's point of view?

Yes (which is not the same as saying that it happened).

Specifically, someone nearby could have used airdump-ng or equivalent to get your AP's SSID and MAC address.

Then it would have issued a forged deauth packet to log everybody off the AP. This closely matches your symptoms.

Finally it would have set up a fake access point with the same MAC and SSID, but transmitting at a markedly higher power (not really difficult this, as he's trying to overpower a smartphone). Your Mac then connects to the rogue AP.

Next thing you know, you're supplying your credentials (as Torin42 noticed, this requires some social engineering and works best with a little help from the OS) to the attacker. Who is apparently not interested in intercepting your traffic (otherwise he would have let you log, lying in wait for you to enter some other credentials such as email, home banking and such). But now that he has your credentials, he's free to hijack your access point and surf for free without any need to crack the WPA2 encryption.

The attempt failed because you changed your WiFi password, and because he did not allow you to connect to the rogue AP. The latter could have disclosed other credentials on the Mac, not doing the former would have left your AP exposed to a connection with stolen credentials.

There are diagnostic tools for PC and Android (don't know about the Mac) that would help recognize this situation - if you scan the neighbourhood with e.g. WiFi Analyzer (Play Store: com.farproc.wifi.analyzer), you would see your access point - which must be running on a different phone - with an expandable 'shadow' with the same MAC as the main one (WiFi range extenders would have the same, with two different MACs).

Or - even easier - if you turn off the AP on the phone and scan the neighbourhood, you would see your AP's name, which ordinarily could never be seen (as WiFi client and AP server functions are mutually exclusive).

Improve this answer
3
  • 1
    Assuming that it was not an open wifi with the same name using a captive portal which looks like the OS wifi password prompt, how could the attacker provide wifi access or get the correct wifi password? WPA2 has mutual authentication (see [this answer]( crypto.stackexchange.com/a/11980)), so without knowing the password of the wifi the attacker could not provide network access, and based on the transmitted info (4-way-handshake) their best bet is to brute force the wifi password offline (which could have been done without the rouge AP aswell).
    – Torin42
    Dec 13, 2017 at 8:06
  • @Torin42, this is indeed how this works (see null-byte.wonderhowto.com/how-to/… ). Shouldn't work except with very naive users, but several OSes have "shortcuts" that detect a captive portal and helpfully reroute the request to the system pw prompt (or even auto-fill the request). My own not-so-smart-phone has problems logging in to the "open" hospital WiFi, because every time it insists on auto-sending the previous, obsoleted access code. I need to make it forget the network and reenter today's code.
    – LSerni
    Dec 13, 2017 at 9:13
  • Couldn't this just be a regular deauth attack to cause the user to enter their WPA2 password again, so that the attacker can intercept the authentication sequence and then start the brute force password cracking process? The old SSID still showing up could just be cached. I have never heard of a WiFi attack that allows someone to use the access point without cracking the password.
    – Alex Cannon
    May 28, 2018 at 20:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .