By Tony Lee
In our previous articles we used TP-Link’s TL-WN722N and a Kali Virtual Machine (VM) to perform wireless discovery and attack against a Wired Equivalent Privacy (WEP) network and WPA (Pre-Shared Key) PSK network to showcase the abilities of this inexpensive and flexible setup.
In this article we will continue to test this setup by attacking our home router that is hiding its SSID--walking you through the attack from start to finish.
Figure 1: Our setup
Consult our previous article WEP for the following topics as they are omitted from this article due to similarity:
- Tips and tricks
- Version of Workstation
- Screen Resolution
- Simple Text Editor
- Connecting the USB Device
- Start the capture
NetworkManager (included in the default Kali Linux) can cause problems when trying to complete simple tasks such as connecting to wireless networks. To prevent any interference, we will disable it ahead of time.
root@kali:~# service network-manager stop
[ ok ] Stopping network connection manager: NetworkManager.
In the previous article, we mentioned that the simplest way to ensure that the wireless card is working is to do some light discovery. After all, the first step in a wireless engagement is to identify targets of interest. This article throws a little twist into it by hiding the SSID.
Typically, wireless access points will continuously broadcast their SSID at regular intervals. However, some administrators choose to disable this SSID broadcast in an attempt to keep the network hidden from curious observers and would-be hackers.
We can discover the BSSID (or MAC address) of the access point that we want to connect to, but we do not know the name. This is a problem, because you cannot connect to a network without knowing the (case-sensitive) ESSID. Let’s check out the network using the iwlist command as we can stay in “Managed” mode.
root@kali:~# iwlist wlan0 scanning | grep -A 30 30:46:9A:16:ED:CE
Cell 10 - Address: 30:46:9A:16:ED:CE
Frequency:2.437 GHz (Channel 6)
Quality=26/70 Signal level=-84 dBm
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s
Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
Extra: Last beacon: 1928ms ago
IE: Unknown: 0000
IE: Unknown: 010882848B960C121824
IE: Unknown: 030106
IE: Unknown: 050400020000
IE: Unknown: 0706555320010B1B
IE: Unknown: 2A0100
IE: Unknown: 32043048606C
IE: Unknown: DD180050F2020101830003A4000027A4000042435E0062322F00
IE: Unknown: DD0900037F01010000FF7F
IE: Unknown: DD0A00037F04010002004000
IE: Unknown: DD270050F204104A0001101044000102104700100000000000001000000030469A16EDCE103C000103
Notice how the ESSID is hidden and is displayed as: ESSID:"". Our goal is to discover this hidden name.
In the previous article, we mentioned using Kismet and airodump-ng as discovery tools. In this article, they are both discovery and attack tools (if we are patient enough).
“A Service Set Identifier (SSID) is a 32-character (maximum) alphanumeric key identifying the name of the wireless local area network. Some vendors refer to the SSID as the network name.”
This SSID is case-sensitive and required for clients to connect to the wireless network. It is trivial to prevent the network name from being broadcasted in most router or wireless controller settings and can provide some (albeit minimal) level of difficulty in discovering the name. Keep in mind that when used as a sole source of security for your wireless network--it is merely security through obscurity. In addition, it can make your wireless stations (clients) more vulnerable to attack as they will go around asking for that network by name. This provides an attacker the opportunity to provide a fake AP broadcasting the network name that the client is requesting--certainly a topic for another article.
Our test router has this setting in the following location:
Figure 2: The screenshot above shows the checkbox to enable broadcasting the SSID. Uncheck the box to hide it.
Now, when Windows users try to find the wireless network it will show up as “Other”:
Figure 3: The wireless network with a hidden SSID is shown as “Other Network”
When we click on “Connect”, Windows will ask us for the case-sensitive network name:
Figure 4: A user needs to supply the network name.
After the correct network name has been supplied, the user will still need to know the key:
Figure 5: Knowledge of the correct key is still required
So, how do we discover the name of the network?
We can discover the name of the network without sending even one packet--we just have to be very patient. When a client associates with a wireless network, they pass the SSID in the management frame. This management frame is sent in the clear and thus attackers can passively discover hidden SSIDs just by patiently listening. Observe the screenshot below where we used a Wireshark display filter to hone in on an Association Request packet to show you the SSID field.
Figure 6: The captured packet is an Association Request from the wireless client to the AP with a hidden SSID
The following is a cheat sheet of common wireless frame filters that can be used in Wireshark.
Figure 7: Handy Wireshark cheat sheet for wireless frame filters
By chance, upon firing up Kismet, we did happen to capture the management frame.
Figure 8: Kismet detects hidden SSID
For the more impatient people out there (raises hand), we can speed it up a little and turn it into a more active attack. The best approach here is to start our listener (either Kismet or airodump-ng) and then perform a deauthentication against a connected client. When the client reassociates, we will have the SSID.
Using airodump-ng, we will need to note most of the same information to what we had in the previous article:
- MAC address of the AP (BSSID)
- Channel that the AP is sitting on
- MAC address of a wireless client
First we will start airmon-ng on our wireless adapter so that it can create the monitoring interface mon0.
root@kali:~# airmon-ng start wlan0
Found 2 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!
Interface Chipset Driver
wlan0 Atheros AR9271 ath9k - [phy0]
(monitor mode enabled on mon0)
The information we need is summarized below:
Variable name = Description: Value
$ESSID = ESSID: ?????
$CH = Channel: 6
$AP = AP MAC: 30:46:9A:16:ED:CE
$VM = Victim user MAC: 24:77:03:8C:D3:44
For this exercise, it is good practice to open 2 windows and copy the following into each window to set the variables:
If you want to change your MAC address for extra stealth, now is the time to do so.
Start the Capture
We begin by capturing the traffic in an attempt to get the reassociation. This is a convenient way to start because it also locks us on to the channel of the AP of interest (in this example, channel 6).
airodump-ng -c <CHANNEL> --bssid <APMAC> -w <FILE PREFIX> <INT>
-c = Channel that the AP is on
--bssid = MAC address of the AP
-w = Prefix of the file name that you want to write data to
<INT> = Interface we will be capturing on
airodump-ng -c $CH --bssid $AP -w WPAcapture mon0
As shown below, the ESSID name is not showing up in our top terminal window running airodump-ng.
Figure 9: Airodump-ng prior to the deauthentication attack does not know the network name
Deauthenticate the Client
The goal here is to deauthenticate (aka kick a client off the network) so they have to reconnect to the network. Upon client reauthentication, we can capture their management frames.
aireplay-ng -0 25 -a <AP> -c < VICTIM_MAC> <INT>
-0 = (same as --deauth) deauthentication attack
-a = MAC address of the AP
-c = Victim MAC address
<INT> = Interface we will be attacking from
aireplay-ng -0 25 -a $AP -c $VM mon0
Shortly after running the deauthentication, we get some activity in our airodump-ng window as shown below.
Figure 10: After the deauthentication packets are sent Airodump is able to discover and tell us the ESSID
When you are watching your attack take place, keep an eye on the top right-hand corner of the capture window. You should see the ESSID field populated if your deauthentication was successful.
Now that we have recovered the ESSID, we will connect to the AP using the command line steps outlined below:
Check the status of the card:
root@kali:~# iwconfig wlan0
Enter the network information:
root@kali:~# iwconfig wlan0 essid "QX3A7" key 55:70:9E:69:0D:A0:9B:E1:18:DB:3A:7E:D9
Bring the Interface up:
root@kali:~# ifconfig wlan0 up
Check the Association:
root@kali:~# iwconfig wlan0
Obtain an IP:
root@kali:~# dhclient wlan0
Reloading /etc/samba/smb.conf: smbd only.
Here is what it should look like:
Figure 11: Connecting to the WEP protected network with a hidden SSID
Now that we know the ESSID, we can use the attacks outlined in the previous articles to attack WEP and WPA/PSK secured networks.
Even though the intention of this article is not to warn about the dangers of relying on hidden SSIDs as a sole means of security, we feel that doing so is worth noting. Also worth noting is the increased chance of client compromise when hiding SSIDs. When configured to do so, clients will beacon for hidden access points which leave them susceptible to attackers claiming to be the access point they are seeking. This this results in an increased risk to clients, we generally discourage hiding SSIDs unless the wireless supplicant has additional intelligence that prevents connecting to rogue APs.
In this article, we proved the capabilities of an inexpensive wireless adapter and a flexible virtualized wireless attack image by uncovering a wireless network’s hidden SSID. For just $16 and no reboot required you can place a wireless adapter into monitor mode and start assessing wireless networks. More testing needs to be done with this setup to determine other capabilities; however as of right now, it appears that it can provide quick, portable, flexible, and inexpensive wireless testing. Feedback below is always appreciated.
If you try this with different cards and run into issues, check the following excellent resource: http://docs.kali.org/troubleshooting/troubleshooting-wireless-driver-issues