July 2022 – Blog Wifi

The analysis of frames using Wireshark or another frame analyzer is essential in the resolution of network incidents. It allows us to obtain all the information exchanged and to understand precisely what is going on. But this quickly becomes a real headache if we are not well organized and not looking for the right elements. Through this white paper, we will try to show you some tips to facilitate the resolution of Wi-Fi incidents using Wireshark on Windows.

To do this we will start by looking at the different ways of capturing data, then we will study the interface of Wireshark and see how its customization allows us to visualize more clearly the information we want to see and in a third time we will see how the tools integrated in Wireshark allow us to analyze in more detail the captured frames and allow us to identify malfunctions.

1 Capture with a network card

Prerequisites :

Wi-Fi card in monitor mode (to see the list of compatible Wi-Fi cards: https://secwiki.org/w/Npcap/WiFi_adapters)
Npcap installed with “Support raw 802.11 traffic” feature
Wireshark version higher than 3.0

Capturing 802.11 frames with the built-in Wi-Fi card has always been a problem with a Windows computer. Indeed, it is only very rarely possible to activate the Monitor mode, which enables capturing the radio layer. By default, it is the Managed mode that is activated and allows capturing the packets from layer 3. The Npcap library permits to solve this problem, provided that the wifi card is compatible (see Prerequisites).

You can also know the modes supported by your network card with the following command (Wi-Fi is the name of the network card) :

C:\Windows\System32\Npcap>WlanHelper.exe "Wi-Fi" modes

Warning : Before starting the procedure, it is important to make sure that Winpcap is not installed on the computer.

The first step is to activate the Monitor mode on the network card:

C:\Windows\System32\Npcap>WlanHelper.exe "Wi-Fi" mode monitor

To know the mode currently used by the network card :

C:\Windows\System32\Npcap>WlanHelper.exe "Wi-Fi" mode

It is then necessary to select the channel which one wishes to listen (for example for the channel 1) :

C:\Windows\System32\Npcap>WlanHelper.exe "Wi-Fi" channel 1

2 Capture with an external module

We do not always have the possibility of travelling to make the captures we want, or we want to use an external equipment to make the capture. Here I present three possibilities that exist, there are others, for example the possibility of using an access point in “listening” mode (be careful, because activating the listening mode usually disables the AP).

Wlan pi

To capture packets from the Wlan Pi, we will use the WLANPiShark2 script (It is installed by default on the WlanPi) :

https://github.com/WLAN-Pi/WLANPiShark2 . It will allow us from a Windows computer to collect the captured packets.

Here is an explanatory diagram provided by the author:

The use is then very simple, because the WLANPiShark2 script is already integrated in the Wlan Pi distribution. You just have to modify the WLANPiShark.bat script on your computer with the information you want and then run it with the different parameters to make it work.

You can find all the details about the use of the script on the github of the project: https://github.com/wifinigel/WLANPiShark

Ekahau Sidekick

The Ekahau Sidekick module also allows you to capture packets. To do this, you just need to connect it to your computer, launch the Ekahau Capture software (you need an Ekahau Connect account) and then select the channels that interest you. In the options, we have the possibility to choose the location where the file will be saved, as well as the “dwell time” (listening time per channel). Once all this is selected, we can launch the capture.

IMAGE EKAHAU CAPTURE

With another computer

Windows allows with the feature “Remote Packet Capture Protocol” to receive in wireshark packets captured by another computer. To do this, you must go to the client machine in the service management and activate the service: Remote Packet Capture Protocol v.0 (experimental). You can also configure the service by changing the destination port or by adding an authentication.

Then, on the server machine, you go to the capture options, then to “Manage Interfaces” to add “remotes interfaces”. You can then enter the IP address of the client machine and the port (by default 2002).

Then you will see the interfaces appear in the list of available interfaces in the following format:

rpcap://<Adresse IP client>:2002/<ID de l’interface>

3 Initiating the capture

When analyzing Wi-Fi incidents, it is generally not recommended to use capture filters, as this may mask different exchanges that take place between different devices. It is recommended to capture all traffic and then apply visualization filters. If the traffic is too important, it is possible to split it into several pieces according to size, duration or number of packets.

However, if the volume of data is still too large or you know exactly what you are looking for, it may be interesting to set up capture filters to facilitate the analysis.

Here are some examples of filters that can be used:

wlan addr1 00:01:02:03:04:05 :Capture packets where MAC address 1 is 00:01:02:03:04:05 (addr2 for MAC address 2, …)

wlan type mgt : To capture only management type frames

no wlan type data : To not capture data frames

wlan type mgt subtype beacon : To capture only beacons frames

wlan type ctl and (subtype rts or subtype cts) : To capture only Clear-To-Send and Request-To-Send frames

To find all the filters :

https://www.wireshark.org/docs/man-pages/pcap-filter.html

Discovered and named by Mathy Vanhoef (New York University Abu Dhabi) on May 11, 2021, the FragAttacks (fragmentation and aggregation attacks) are a group of a dozen vulnerabilities that affect not only the WEP protocol but also other recent protocols such as WPA3. The vulnerabilities discovered are mainly located in the exchanges with the addition or modification of information, all the terminals connected to the network are therefore vulnerable.

According to Mathy Vanhoef’s research, three of the vulnerabilities are design flaws in the 802.11 standard. The researcher also said that these vulnerabilities are complex to exploit. However, he draws attention to weaknesses related to WiFi implementation flaws at the terminal level, as these can be directly exposed.

I will briefly present below the 3 design flaws of the 802.11 standard, to go into more detail I invite you to read the detailed information provided by Mathy Vanhoef.

1- Aggregation Attack (CVE-2020-24588)

The first design weakness is located in the 802.11 header and more specifically in the “is aggregated” flag, which is neither authenticated nor encrypted during the transmission of the frame. An attacker can therefore modify this field and thus allow a packet injection. An example of an attack would be to transmit a malicious DNS server to a client. After extensive testing by Mathy Vanhoef, it was found that all devices are vulnerable to this attack.

2- Mixed Key Attack (CVE-2020-24587)

The second design weakness in Wi-Fi is in the frame fragmentation function. This feature, in principle, allows the reliability of the connection through the division of large frames into small fragments. Thus, the same key is used to encrypt each fragment of the same frame. However, the receivers are not obliged to check the keys and could gather fragments decrypted with different keys. Even if the cases are rare, it is still possible to exploit this flaw to exfiltrate data. To do this, fragments encrypted with different keys must be mixed.

It must be said that this design flaw is correctable in a backwards compatible way through an exclusive gathering of fragments that have been decrypted with the same key. Since this attack is relatively rare, it is classified as a “theoretical attack”.

3- Fragment Cache Attack (CVE-2020-24586)

The third design weakness of Wi-Fi, like the second, is the frame fragmentation function. The problem lies in the fact that when a user disconnects from the network, the Wi-Fi device does not necessarily delete the fragments from the memory, which have remained uncollected. This can lead to abuse, especially in hotspot networks. This design flaw can lead to data exfiltration through the injection of a malicious fragment into the “fragment cache”. Thus, when the victim sends a fragmented frame after connecting to the access point, the selected fragments are combined with those injected by the adversary. This design flaw can be corrected in a backwards compatible way. This can be achieved by deleting the fragments when “reconnecting” or disconnecting to a network.

4- Some other cases

Another vulnerability that is important to note is the one noticed on some routers that transfer EAPOL frames to another client before the sender even authenticates. Through this vulnerability, attacks can be performed by aggregation by injecting arbitrary frames without any user interaction. The other implementation flaw that is very common concerns receivers that do not check that all fragments belong to the same frame. This flaw can allow other frames to be formed that come from mixing two different frames. Some devices do not support aggregation or fragmentation, but are still vulnerable to attack since they consider fragmented frames to be complete frames. It is possible that this flaw can be used to inject packets.

More details to follow

To go further :

https://www.fragattacks.com/

Month: July 2022

How Wireshark can facilitate Wi-Fi incident analysis (Part 1 : Packets capture with Windows)