WI-FI PT / 2 - ATTACKS AGAINST INFRASTRUCTURE / 2.2 - Attack against MAC filters

2.2 - Attack against MAC filters

- One of the most used security measure consists on protecting the access to a network with a MAC filter implemented on the Access Point. However, during this practice it will be shown that filtering MACs is actually useless, because that filter can be defeated. MAC filtering is based on the usual wired firewalls, where there is a list of allowed and denied devices. Actually, MAC filtering is added by the AP software and is not really present in the 802.11's security standard.

- For instance, let's filter the access of the attacker "kali" (00:C0:CA:72:1A:36) with the AP's option MAC Restrict Mode equal to Deny:

- As we can see, now there is just one legitimate client connected, "roch". 

- About "kali"s wlan0 interface, it is verified that its MAC address is 00:C0:CA:72:1A:36:

- If "kali" tries to connect to the network "spaniard" it will be rejected due to the filter:

- This screenshot shows that the status is of failured connection: Access Point = Not-Associated:

- Wireshark detects Authentication failure packets between the AP (Motorola) and the attacker "kali" (Alfa card):

- To start the attack from "kali", the first step would be to write down the legitimate connected client "roch"s MAC, it is 28:C6:8E:63:15:6B, which is shown by airodump-ng in clear text. In shortly that number will be of great value:

- The interface wlan0 is turned off:

- With the command macchanger the wlan0's MAC address is replaced by legitimate client "roch"s MAC, which has been shown by airodump-ng in clear text:

- The interface wlan0 is turned on:

- It is checked that now wlan0 has got a different MAC address than the original one:

- Then, the connection to "spaniard" is tried again:

- The connection is successful, because the status has changed to Access Point = 00:25:F2:9B:91:23

- The conclusion of this practice is that an attacker whose access to a network is prohibited due to a MAC filter implemented at the AP is able to beat the filter just spoofing its own MAC address, replacing it with the MAC of a legitimate client. How to know the good client's MAC? as usual, airodump-ng helps to solve that step.

- What is really shocking is to verify that even the AP gets confused, because it reads the spoofed MAC address of the attacker "kali" as if it was the good one:

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. 

WI-FI PT / 1 - SNIFFING, CAPTURING, ANALYZING AND INJECTING PACKETS ON WI-FI NETWORKS

The following techniques are essential in the process of penetration testing for a wireless network.

1.1 - Connecting the wireless interface card

- We start plugging-in the Alpha USB device to the computer "kali" and then booting it. From the console, we can use iwconfig to confirm that the wireless card has been detected and the drivers properly loaded. The virtual interface used for wireless connections will be wlan0:

- Next, bringing the interface wlan0 up:

- Checking that wlan0 is actually up:

1.2 – Sniffing packets

- The first step in the sniffing process would be to use the command airmon-ng in order to put the card into monitor mode, also known as promiscuous mode in the wired networks. It means that the wireless interface will accept all the packets off the air in the working channel, regardless its destination.

- The command airmon-ng, without options, detects the available card wlan0:

- Because It is not possible to use directly wlan0 in monitor mode, a monitor mode interface is created, called mon0, virtually attached to wlan0, that will be able to read wireless frames off the air:

- Checking that mon0 has been properly created: 

- Verifying that mon0 is working in monitor mode:

- Its MAC address is 00-c0-a0-71-1a-36, same as wlan0:

1.3 - Capturing packets

- For the purpose of capturing and analyzing the sniffed packets, the tool Wireshark can be launched:

Under Capture -> Interfaces:

- The interface mon0 is picked up, and then Start:

1.4 – Analyzing packets

- At next image, captured broadcast packets from Alfa Network interface card can be seen. The Protocol field is 802.11, as expected for wireless packets:

- Expanding the third row, the additional information is telling that the frame includes a "Probe Request" broadcast , because the client's Alfa wireless card is requesting information from any available access point:

- Next, with the purpose of expanding a little bit this practice, the client is connected to the network created by the Access Point, whose SSID is "spaniard":

- The Acces Point asks for authentication to allow the client to join the network "spaniard":

- Again, from Wireshark, captured packets sniffed by the interface mon0:

- Now, there are a lot of different frames in the air:

- In order to filter packets created by the Access Point, the filter wlan.bssid == 00:25:f2:9b:91:23 is used, being the hexadecimal number the Motorola AP's MAC address:

- These packets are coming from source Motorola_9b:91:23 and destination broadcast, being its type Beacon frame. With these packets, the AP is announcing itself to any client that could be listening. As expected, the BSSID is the AP's MAC address, 00:25:f2:9b:91:23. A lot more information of the AP is available from capturing packets with Wireshark, as it will be seen alongside later chapters.

1.5 – Working with channels

- A very interesting command is airodump-ng, which helps to determine in which channel the interface is running on. It is very important to remember that a wireless interface can work only in one channel at a given instant. This means that it is not posible for a wireless card to sniff on all channels and bands at the same time.

- With the purpose of sniffing packets from and to an specific AP, it is necessary to lock up the wireless card on the same channel that the AP, the 6 in this case:

- Setting mon0 on channel 6:

- After the airodump-ng command, it is necessary to add the MAC address of the AP and the monitoring interface mon0:

- Then, all the information about the AP and the clients connected to it is seen. Also, the encryption methods used, and son on. Anyway, these concepts will be studied in more details at next chapter:

- As said before, the working channel for the wireless interface is the 6:

- It can be verified that now the working frequency is 2.437 GHz, corresponding to channel 6 center:

- Another useful utility of airodump-ng is the ability to make the interface hopping from different bands and channels:

- As the time goes by 4, 12, 24, 32, 40 seconds …, the interface hops between channels 6, 5, 3, 13, 2 …

- As previously said, the interface is working in a single channel for a given second, regardless it can hop to another channel some seconds later.

- This option is essential so that the wireless interface card can detect different Access Points in the sorrounding area, each of them working in a different band or channel. Again:

1.6 - Injecting packets

- This practice consists of the Alfa card being able to inject arbitrary packets into the air without actually being connected to the AP. So, first of all we need to disconnect the attacker "kali" from the "spaniard" network.

- Injecting packets from the client “kali” means that it will be acting as a new AP, in other words a “spoofed AP”. For that, “kali” will be creating arbitrarily beacon frames as if it would be an AP broadcasting its SSID “example”.

- One of the commands to achieve this goal is mkd3, adding the mon0 interface, option b for “beacon flood mode”, option -n for name SSID “example”:

- These packets are captured by Wireshark:

- Also, from the client “roch” the spoofed AP's SSID “example” can be detected:

- Another option could be to use the aireplay-ng command, to inject packets into a network, for instance “spaniard” In this case, the wireless interface detects the AP and then injects “probe request” packets, even without actually being connected to the AP. The used options are -9 (tests injection and quality), -e (setting the target AP's SSID), -a (setting the target AP's BSSID or MAC address), and finally the used interface mon0.

- From this practice it can be deduced that anyone can create and broadcast beacon frames (imitating a real or legitimate AP, being SSIDs in clear text or unencrypted), or inject probe request packets. These security tricks will be very valuable for attacks seen at next chapter.