The topic today is hidden SSIDs and some misconceptions about the benefits.
Hiding of the SSID is a common feature available in most wireless systems. The basic idea is that if the SSID name is not advertised, no one will know about the wireless network, but this is not entirely true. Hiding the SSID is useful only as a mechanism for protecting against casual onlookers. It holds no significant value as a security mechanism, nor should it be considered a security mechanism, and actually has a couple of disadvantages which can outweigh the benefit of using it.
Hidden SSIDs are still a common occurrence in some commercial deployments today. When working on a network that is configured to not broadcast the SSID, it is important to understand the reasons behind the configuration. It could be a simple case of “we thought it would be secure” which can be remedied by implementing the necessary security mechanisms, such as WPA2/3. The reason could also be a little more convoluted, e.g. hidden SSIDs are sometimes used (incorrectly) as a workaround for having too many SSIDs. Recall that each wireless network uses precious airtime simply for advertising the network, typically through beacons. Having too many SSIDs increases the number of beacons and management overhead, and reduces available channel capacity. A common recommendation is to have no more than four SSIDs for a standard deployment, and less (just one) in the case of very high-density deployments. If the hiding of the SSID has been implemented as a measure to reduce the number of advertised SSIDs, then resolving this issue becomes a little more complicated. Not advertising the SSID in the beacon is not the correct mechanism for reducing the number of beacons, only reducing the number of SSIDs will do that.
Connecting a client to a hidden SSID requires prior knowledge of the SSID name as the client is unable to discover the network automatically, putting an additional burden of the network administrator to pre-configure all the devices. There are additional downsides to hidden SSIDs including possible issues with client roaming.
Having a look at the mechanism itself, we can see that while the SSID is indeed removed from the beacon, it still exists in other frame exchanges. The image below shows a (manually configured) client sending a probe request to an AP, with the name of the (hidden) SSID, and the AP responding with a probe response, also with the name of the SSID.
All this means is that if we need to learn the SSID we just have to look at the probes instead of the beacons.
Time for a practical example.
In the previous post titled Building a Wi-Fi scanner with Scapy we built a simple wireless discovery tool. Using this as a base, we only need to add a bit of new logic to show the hidden SSIDs. Please refer to the previous post for the rest of the code.
Additional Pseudocode
For each received frame
IF Probe Response
Save SSID and BSSID in new dictionary
Retrieve the SSID from the beacon as before
IF SSID in Beacon has null value
IF same BSSID exists in new dictionary (created from probe response)
Use SSID from Probe Response
That’s all there really is to it, the tool will maintain a mapping of all BSSIDs and SSIDs received from probe responses. One entry (the last received) will be kept for each BSSID. If the standard beacon does not contain an SSID value, we check for the SSID in the list of probe responses. If there is a match, we use the SSID from the probe response, instead of the null value from the beacon.
Now we wait for a probe response.
One caveat here, when scanning on all channels the process may take some time. First, we need to catch a beacon, then, we also need to catch a probe response on the same channel. As probe responses are dependent on clients sending probe requests, this means the stars need to align (not really) and the probe response to the client needs to be sent while listening on that specific channel. This is easier to achieve with a larger number of clients, but it may take longer with only one test client.
Of course, if we were doing this for a purpose other than learning, we would first find the channel on which the hidden SSID was being broadcast. Then focus our efforts on only that single channel, greatly decreasing the time required to capture a probe response. And failing that, force the issue by sending disassociation frames forcing the clients to re-probe, but there is ample material on this elsewhere on the internet.
In the test lab we have a hidden SSID called GhostNet. Running the tool (and filtering only the hidden SSIDs) we can immediately see the existence of the hidden networks, one on 2.4GHz and one on 5GHz. This is information from the beacons, including all the other parameters of the network that we would expect to get from a beacon. We add the GhostNet SSID to a test client (manually), the client now sends a probe request to the AP, and the returning probe response is captured. We now have the name of the hidden SSID on the channel where the client connected. The screenshot below shows the ‘revealed’ SSID on 5GHz, while on 2.4GHz the SSID is still null.
In summary, the reality of hiding the SSID is that it causes more hassles for the administrator and users of the network, than it does for someone trying to discover the SSID.
The updated Wi-Fi Scanner code can be downloaded here.