08. Evil Twin Attacks
- This attack consists of creating a rogue AP with same ESSID as target network.
- Same BSSID and same Channel can also be used in order to be stealthier.
- Attack will work if we manage to change the AP a legitimate user is connected/ing to.
It can be done by:
- Offering a better signal than the original AP (might be hard !).
-
Blocking access to the original AP via DoS attack (jamming, deauth/disassociation packets...). But in real-world enterprise deployment, there are usually several APs on the same ESSID, so deauthenticating from one AP will usually result in the target roaming towards another valid AP rather than the rogue AP. Therefore, it might be required to:
- perform DoS on various APs,
- and/or to carefully place the rogue AP.
When attacking clients from an Open Network (i.e. Hotspot), attacker will spawn a rogue AP as an open network (no passphrase) too, with same ESSID as target.
Once client connected, it is possible to perform:
- Basic Man-in-the-Middle (traffic sniffing, DNS Spoofing, JS injection...).
- Captive Portal Attack: Redirect all clients to a captive portal when trying to access any web page. Can be used for:
- Phishing / Social Engineering (fake form): Ask for any credentials
- Payload delivery
2 Cases:
-
Passphrase (PSK) is known (e.g. conference, already cracked passphrase...):
- Attacker can spawn a rogue AP using WPA with same passphrase. When client connects, same attacks as with target=Open Network are possible.
-
Passphrase is unknown:
- Attacker can spawn a rogue AP without passphrase (open network) and perform captive portal attack with phishing using fake form to ask for WPA passphrase to clients.
- Attacker can also spawn a rogue AP to capture an half WPA handshake (first 2 messages) when a client tries to connect. It is enough to try to find passphrase by launching cracking on the half handshake. Interest of this attack is limited because handhshake can be retrieved in a stealthier and easier way.
Evil Twin Attack is only possible if:
- EAP method in use does not use client-certificate for client authentication (like EAP-TLS, PEAPv0(EAP-TLS)) because there is no credentials to steal in this case.
- EAP method in use does not enforce server-side certificate (i.e. EAP-MD5, LEAP) or the EAP deployment does not enforce server certificates validation on workstations (or client manually accept the invalid certificate, when possible).
Typically:
- Efficient against Android phones.
- Efficient against iOS but it prompt for certificate.
- Only a challenge-response against Windows can be captured.
Most of EAP implementations require mutual authentication between client and authentication server. For example, when using MSCHAPv2, server must know the client's password to send valid response and complete the handshake, otherwise the client will detect the server is not the legitimate one and close the connection. Therefore, for most of EAP networks, it will not be possible to get clients fully associate with the Evil Twin attack without knowing valid RADIUS credentials of the vitims.
2 Cases:
-
RADIUS credentials unknown: Credentials or Challenge/Response (depending on the authentication method in use) can be stolen when a client tries to connect to the rogue AP. Tools like eaphammer / berate_ap support RADIUS authentication stealing for (at least):
- EAP-MD5
- LEAP
- EAP-TTLS
- PEAP
-
RADIUS credentials known: Clients whose credentials are known can fully connect to rogue AP. Then, the attacker can perform any traditional attack as a Man-in-the-Middle:
- Basic MitM
- Captive Portal attack
- Hostile Portal attack: force client to perform SMB connection to attacker (Redirect to SMB):
- NetNTLM hash stealing
- NTLM Relay
- NBT-NS/LLMNR Poisoning / NTLM Relay
To reduce the potential for device incompatibility issues resulting from failed negotiation attempts, both supplicants and authentication servers are typically configured to support a variety of EAP Methods. However, not all EAP methods are created equal (e.g. PAP will transmit password in cleartext, MSCHAPv2 will use challenge/response...).
Since the EAP method negotiation is initiated by the evil-twin AP, it is possible to trick the clients to use a weak authentication protocol (e.g. GTC). In fact,while legitimate APs propose EAP methods from the strongest to the weakest, the evil-twin AP can propose EAP methods from the weakest to the strongest.
EAP authentication process will take longer. Since most client devices will not accept the weaker EAP methods, a more balanced approach is usually more effective.
Ref: https://solstice.sh/2019/09/10/eap-downgrade-attacks/
EAP methods using MSCHAPv2 as client authentication method (e.g. PEAPv0(MSCHAPv2)) can be targeted by MSCHAPv2 relay attack as follows:
This attack allow an attacker to get a position of Man-in-the-Middle in the target network, without knowing valid credentials (no need to crack MSCHAPv2 credentials).
Ref: