New Hot Spot 2.0 Wifi Evil Twin Attack
In this new wireless attack, I’ll walk you through the process of creating a Hot Spot 2.0 Evil Twin. This is potentially another attack vector, one that can be used with or without social engineering, that a penetration tester or nefarious actor can use when performing a wireless pen test or trying to social engineer a user.
Abusing Hot Spot 2.0 can help to gain a user to trust a certificate. Hot Spot 2.0 misuse can guise a user to think a network is more secure when indeed it is a rogue access point. After the user enter their credentials (You can also redirect users to a captive portal) and accepts the real certificate, we then perform an EAP-GTC attack to obtain a clear text user/password.
############################################################## Enable Hotspot 2.0 support
#############################################################hs20=1
# Operator Friendly NameThis parameter can be used to configure one or more Operator Friendly Name Duples. Each entry has a two or three character language code (ISO-639) separated by colon from the operator friendly name string.-- snip --hs20_oper_friendly_name=eng:Secure Wireless
The HotSpot 2.0 operator friendly name can be change to the company name, a frequency, or location. Go wild, this can be anything. A nefarious actor, or wireless penetration tester can create an HS Evil Twin by using the same SSID and operator friendly name as a real HS 2.0 Network.
The very nature of wireless is insecure. We take a leap of faith when we click on wireless network name. If one says “Secure” and the other doesn’t — what would you choose?
It should be noted that “iPhone” network above, is for example — any network name can be used here. A legitimate Hot Spot 2.0 name, or WPA2 Enterprise Network name used by an organization.
We put a lot of blind trust into SSID names alone, now we have another field; we can enter any string we think will entice the user to connect to the network.
Another area of concern is on some devices, on the latest iOS’s you can not remove the rogue certificate. This makes the attack more stealthy, and difficult to mitigate once the certificate is trusted on the device. If you change your SSID name, you will be prompted again for the certificate to trust. You can use this for a control when testing.
For comparison, when using Mac OS, you can access the keychain, and delete the certificate; on the iOS devices tested, this doesn’t seem possible.
It should be noted — On Android, using Lootbooty, certain versions of the operating system does not prompt the user for a certificate.
I used my own controls, which include hostapd-wpe with hostapd-2.6 for proof of concept to test if the EAP-GTC downgrades still work on the latest iOS and MaC OS devices. These two devices I always target — because you can usually get clear text credentials using a form of EAP-GTC dumb down, and whose supplicant’s has native support for EAP-GTC. Windows has never had native support for EAP-GTC authentication. You can use a third party supplicant, but Windows itself does not natively support EAP-GTC.
By using your Let’s Encrypt certificate you can effectively avoid this issue, by not relying on self-signed certificates. Many companies sign their certificates internally. This isn’t a solution to the SSL issues on server and client, but another technique, when performing an Evil Twin attack against Enterprise Networks with iOS devices as wireless endpoints.
# apt-get install certbot# certbot — apache -d starbucks.”yourdomain” — register-unsafely-without-email# scp server:/etc/letsencrypt/live/starbucks.”yourdomain”./*.pem# apt-get install certbot# certbot — apache -d starbucks.”yourdomain” — register-unsafely-without-email# scp server:/etc/letsencrypt/live/starbucks.”yourdomain”./*.pem# ls cert.pem chain.pem fullchain.pem privkey.pem (Copy these to the machine you’re using for hostapd)— SNIP —hostapd.confca_cert=/root/files/cert.pem
server_cert=/root/files/fullchain.pem
private_key=/root/files/privkey.pem* Don’t have to use the file — “chain.pem”, for Radius *
Gabriel mention below in detail, the reasoning behind this change in certificate behavior for Windows (in detail) and explains the Legacy Crypto Support. I also recommend using eaphammer, which lets you use self signed certificates, and has native support for the EAP-GTC attacks.
by Gabriel Ryan ( s0lst1c3)(gabriel[at]specterops.io) Current release: v1.12.0
References:
Let’s Encrypt — Free SSL/TLS Certificates
EAPHammer Version 0.5.0 — Legacy Crypto Support
Advanced Wireless Attacks Against Enterprise Networks (AWAE) (v3.0.1)
