WI-FI PT / 2 - ATTACKS AGAINST INFRASTRUCTURE / 2.1 - Uncovering hidden SSIDs

2.1 - UNCOVERING HIDDEN SSIDs

- Every Access Point offers the option, known as "Closed Network", of hidding the SSID when broadcasting beacon frames to announce itself. This option is usually considered a security measure, but as it will be explained here, it is actually easy to uncover the hidden SSID.

- At the AP used in this practice, "Closed Network" can be enabled in this way:

- Then, capturing beacon frames from the AP, Wireshark is not able to detect the SSID, actually showing the field in blank:

- The attacker "kali" uses airodump-ng to detect that the victim "roch" is connected to the AP, but it is not able to learn the ESSID, just showing that it has got a length of 8 characters: <length: 8>:

- The trick consists on forcing the client "roch" to deauthenticate, knowing that later it will try to reconnect to the AP. Using aireplay-ng 5 packets are sent to the Access Point whose MAC address is 00:25:F2:9B:91:23, through "kali"s interface (00:C0:CA:72:1A:36), forcing the "roch" client (28:C6:8E:63:15:6B) to be disconnected:

- Using this filter at Wireshark (wlan.bssid == 00:25:F2:9B:91:23) && !(wlan.fc.type_subtype == 0x08), meaning packets different than subtype beacon frame (0x08), the deauthentication packets can be observed:

- Next, waiting just some instants, when client "roch" tries to reconnect by means of a Probe Request packet, the AP answers with a Probe Response message, showing the expected SSID in clear text ("spaniard"):

- This attack is based on the fact that Probe Request/Response exchanged packets need to use the SSID. This packets are not encrypted and are very easy to be sniffed from the air. So, forcing to deauthenticate a client, and waiting for the reconnection process, the SSID is sooner or later achieved. Of course, waiting for a client to connect by itself would be also a valid way of achieving the same goal, although in that case it would be taking a passive attitude during the attack.