Chapter 20
Wireless Security in Linux

File: nsl/wireless.tex, r1668

This chapter demonstrates intercepting traffic on a wireless network. This task requires a computer with specific wireless hardware; VirtualBox or virtnet cannot be used to overcome any hardware limitations. Therefore you may not be able to perform the tasks yourself, however you can still learn the general concepts of capturing wireless packets.

20.1 Prerequisites

20.1.1 Assumed Knowledge

This chapter assumes you have knowledge of:

• Operation of wireless LANs, including Access Point (AP), MAC addresses, channels and frequencies.
• Packet capture and analysis using tcpdump and Wireshark.

Basic Linux command line skills, as covered in Chapter 4, are assumed. You will need to be able to:

• Perform operations on directories and files, including ls, cd, cp.

20.1.2 Linux and Network Setup

The tasks in this chapter require Linux installed directly on a real computer. Virtualisation techniques, including running Linux as a virtual machine on a Windows computer, will not work. Similar, virtnet will not work. You must have Linux installed on a computer and that computer having a suitable wireless card. Alternatively a macOS system may work. Further details of these requirements are given in Section 20.2.

20.2 Wireless LANs

This chapter focusses on capturing packets on a wireless network, specifically a wireless LAN. While we don’t attempt to explain wireless LAN’s here, a summary of important concepts is given in Section 20.2.1. Sections 20.2.2, 20.2.3 and 20.2.4 address packet capture in Linux, macOS and Windows host operating systems, respectively.

20.2.1 Wireless LAN Concepts

A wireless LAN is a type of wireless network. The common standard used in wireless LANs is Institute of Electrical and Electronic Engineers (IEEE) 802.11. The marketing name is Wireless Fidelity (WiFi). The terms wireless LAN, IEEE 802.11 and WiFi are sometimes used interchangeably.

A wireless LAN commonly consists of an Access Point (AP) that bridges the wired and wireless network segments, and multiple clients or stations that associate with that AP. Each AP has a Basic Service Set Identifier (BSSID) that identifies that AP—this is the AP MAC address. An AP also belongs to a network (which may include multiple APs). This network is referred to as an Extended Service Set Identifier (ESSID), or more commmonly simply, a Service Set Identifier (SSID). The SSID is a name given by the administrator.

Clients must discover APs, either by probing for them, or by an AP periodically broadcasting becaons advertising itself. Once discovered a client can attempt to associate with the AP and then authenticate with the AP.

Wireless LANs, and in particular the IEEE 802.11 standard, deal with the Physical Layer (PHY) and MAC layer. The PHY specifies the radio transmission techniques, while the MAC specifies the protocols for connecting clients to APs and data transmission in a fair and efficient manner.

Key characteristics of the PHY include:

Frequency Bands

2.4 GHz and 5 GHZ are common.

Channels

Within each frequency band a range of different channels are available. Each channel is centred on a specific frequency, e.g. channel 1 in the 2.4 GHz band is centred on frequency 2.412 GHz. A client and AP must use the same channel if wanting to communicate.

Transmit (Tx) Power

The power at the source transmits a signal. Generally it is fixed.

Signal Strength

Also, Received Signal Strength (RSS). The strength at which a signal is received. This depends on various factors, including distance, obstructions and frequencies.

Data Rate

The rate at which bits are sent across the wireless link. Generally the data rate is auto-negotiated by the end points depending on signal strength. Therefore it may change over time (as the signal strength changes).

The MAC layer specifies mechanisms for managing a network, data transfer and controlling that data transfer. MAC frames exist for each of these mechanisms including:

Data

A DATA frame.

Control

An ACK frame in response of DATA, as well as Request To Send (RTS) and Clear To Send (CTS) frames for special cases.

Management

Beacons, probe requests, probe responses for discovery; and authenticate and associate requests and responses.

Broadcast Nature of Wireless

The nature of radio transmission in wireless LAN is that while an AP may be sending data to a specific client, the signal is effecitvely broadcast to all other receivers within range. So while the intended client receives the signal (and can process the data), other nearby clients (or APs) also receive the signal. Normally a client (or AP) will only process that data if it was the intended destination. This is determined by the destination MAC address.

For example, assume an AP transmits a signal containing data intended for client with MAC address 11:22:33:44:55:66. Two clients are within range and receive the signal. While client with MAC ff:ee:dd:cc:bb:aa receives the signal, it does not process the data since it is not the intended recipient. Whereas client with MAC address 11:22:33:44:55:66 is the intended recipient so it process the data. The processing of data means that data is passed by the driver to the operating system.

Wireless LAN Hardware

In the past most Wireless LAN hardware was in the form of separate add-on cards in different form factors. Nowadays, almost all laptops and phones have wireless LAN chips built-in, or USB wireless LAN adapters are used.

The wireless LAN adapter implements the PHY and MAC of IEEE 802.11. Software drivers are used for the adapter to communicate with the operating system. Drivers are normally released by the adapter manufacturer, and capabilities of the adapter available to the operating system (and subsequently applications) are dependent on the driver.

Monitor Mode

As previously discussed, if a wireless LAN adapter receives a signal but is not the intended recipient, then the data does not get passed by the driver to the operating system. Essentially the operating system (and any applications running on it) does not know the data was received—it is ignored. The same applies for control frames, which are handled by the adapter and not passed to the operating system.

For a client, this mode of operation is called managed mode, where the AP is managing the communications.

Some wireless LAN adapters do support a different mode, called monitor mode. In monitor mode the driver will pass all frames on to the operating system, irrespective of the intended recipient. For example, if a frame is destined to 11:22:33:44:55:66 but received by ff:ee:dd:cc:bb:aa, then in monitor mode that frame is passed by the driver to the operating system. This allows applications to see all communications in a nearby area, no matter if they are the intended recipient or not.

There are limitations of monitor mode. Firstly, while a wireless LAN adapter is in monitor mode it cannot be associated with an AP. It generally has receive only capabilities, not allowing transmissions. Secondly, not all wireless LAN adatpter hardware support monitor mode. Finally, in the major limitation for our purposes, not all drivers support monitor mode (even if the hardware does). Therefore using monitor mode to capture packets requires the correct combination of wireless LAN hardware and drivers.

In the past there have been some wireless LAN adapter manufacturers that have good monitor mode support with Linux drivers, whereas Windows had no support (due to the driver architecture). Nowadays, there are many more adapters that support monitor mode, and it is even support on macOS and Windows (as well as Linux). Still, there is no guarantee that your computer will support monitor mode. The next sections give information for finding out about monitor mode in various operating systems.

20.2.2 Linux

If Linux is install on your computer (as a host, not as a guest in VirtualBox or virtnet) and you have an appropriate wireless LAN adapter, then you should be able to capture wireless packets in monitor mode. What is an appropriate wireless LAN adapter? There is no easy answer. Generally built-in Intel Centrino wireless chips support monitor mode, and many other widely used chip manufacturers do. However often it changes between models and even versions. The best way to know is to try the commands in Section 20.3 or search for your wireless LAN adapter details. The Linux kernel wireless page does list chips/drivers and their support for monitor mode, but it may be out of date and identifying your chipset/driver is not obvious.

20.2.3 macOS

While this chapter does not show how to capture wireless packets on Apple macOS, it is relatively simple. Apple provide a support article showing how to use tcpdump to capture wireless packets.

20.2.4 Windows

This chapter does not show how to capture wireless packets on Windows operating systems. It is however possible with Npcap. The Wireshark wiki explains the options and issues.

20.3 Capturing Wireless LAN Packets in Monitor Mode with iw

This section demonstrates capturing wireless packets in Linux. This involves putting the wireless LAN card into monitor mode, allowing you to view and record all packets sent by other WiFi devices nearby.

The instructions use the command iw for configuring wireless interfaces. Similar operations can be performed using iwconfig, and older instructions for iwconfig only are available online. The command iw is meant to replace iwconfig. We still use the older iwconfig occasionally, but iw is a much more powerful tool for viewing/configuring wireless information.

The demonstration was run on a laptop with Linux and an Intel wireless LAN adapter.

20.3.1 Getting Started with iw

First be aware that iw distinguishes between wireless LAN hardware devices (the PHY) and the network interface configured to use that hardware (e.g. wlan0, similar to an Ethernet eth0 interface). To see the list of devices, and interfaces for each device:

$ iw dev
phy#0
     Interface wlan0
         ifindex 3
         type managed

In my case (and most likely for most typical computers) the hardware is phy0 and my network interface is wlan0. You can see detailed information about the hardware using:

$ iw phy phy0 info
Wiphy phy0
     Band 1:
         Capabilities: 0x172
              HT20/HT40
...
     Supported interface modes:
           * IBSS
           * managed
           * AP
           * AP/VLAN
           * WDS
           * monitor
           * mesh point
     software interface modes (can always be added):
           * AP/VLAN
           * monitor
...

Of importance for the next step is the supported/software interface modes should include entry for “monitor”, meaning your hardware supports monitor mode. If there is no “monitor” entry, then you will not be able to capture other peoples data using the next steps.

20.3.2 Capturing in Monitor Mode

If your hardware device supports monitor mode then you must add a monitor interface called mon0.

$ sudo iw phy phy0 interface add mon0 type monitor

You can check that it is added:

$ iw dev
phy#0
     Interface mon0
         ifindex 4
         type monitor
     Interface wlan0
         ifindex 3
         type managed

We will capture with the mon0 interface, so you can delete the normal wlan0 interface:

$ sudo iw dev wlan0 del

Now enable the mon0 interface using ifconfig:

$ sudo ifconfig mon0 up

Before capturing, specify the wireless LAN frequency you want to capture on. You should choose the frequency based on the channels used by neighbouring access points. The frequency is given in MHz, e.g. channel 6 is 2437. Figure 20.1 illustrates the channels in the 2.4 GHz frequency band.

---

---

$ sudo iw dev mon0 set freq 2437

To check that your interface is in monitor mode and using the correct frequency you can use iwconfig:

$ iwconfig mon0
mon0      IEEE 802.11bgn  Mode:Monitor  Frequency:2.437 GHz  Tx-Power=20 dBm
            Retry  long limit:7   RTS thr:off   Fragment thr:off
            Power Management:on

Now you can capture, e.g. using tcpdump:

$ sudo tcpdump -i mon0 -n -w wireless.cap

Ctrl-C to stop the capture, then view with Wireshark. To display select wireless LAN frames in Wireshark use the wlan and wlan_mgt filters. Section 11.4.3 summarises some key filters.

Returning to Managed Mode

If after monitoring you want to revert the changes and continue using the wlan0 interface in managed mode (e.g. connect to an AP), then delete the mon0 interface and add the wlan0 interface:

$ sudo iw dev mon0 del
$ sudo iw phy phy0 interface add wlan0 type managed
$ iw dev
phy#0
     Interface wlan0
         ifindex 5
         type managed
$ iwconfig wlan0
wlan0     IEEE 802.11bgn  ESSID:off/any
            Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm
            Retry  long limit:7   RTS thr:off   Fragment thr:off
            Power Management:on

20.3.3 What Can Go Wrong?

If you get errors with some of the above iw commands, then there are several ways to troubleshoot.

First, check that the wireless device is not soft/hard blocked by rfkill and unblock it if it is:

$ rfkill list
0: phy0: Wireless LAN
     Soft blocked: yes
     Hard blocked: no
$ rfkill unblock 0

Also , make sure you are using the correct interface/device. In my examples I use phy0, wlan0 and mon0. Yours may be different.

If the commands work, but in Wireshark you can only see packets either to your computer or broadcast/multicast (i.e. you cannot see any packets from one computer to another computer, such as HTTP or SSH), then make sure the frequency you selected is being used by others.

Finally, check that your device supports monitor mode (look in the output of iw phy phy0 info). Some wireless cards do not support monitor mode, and even if they do, some drivers do not support it.

20.4 Decrypting Captured Wireless LAN Packets

You may capture wireless LAN packets and then realise you cannot see the data because encryption was used, specifically wireless LAN encryption using WiFi Protected Access (WPA). If the capture was performed on your own network and you know the WiFi password used by the AP, then it is possible to have the WPA packets decrypted in Wirehshark. There are several steps to perform.

First, you must know the WiFi password used. If you don’t know it, the only practical possibility is to guess it. You also must know the SSID. This is included in the frame headers, so can be obtained from the capture file.

WPA uses a Pre-Shared Key (PSK) between the AP and client. This PSK is generated based on the configured password and SSID. We need to generate that PSK. Luckily Wireshark provides a website that will quickly generate the PSK for us. Go to the Wireshark PSK Generator website and enter the WiFi password and WiFi SSID. The output will be a WPA PSK. Copy the value of the PSK.

Now in Wireshark go to the Edit menu and select Preferences. Expand the Protocols and scroll down to IEEE 802.11. The preferences for IEEE 802.11 wireless LAN allows you to Edit the Decryption keys. Add a new key of type wpa-psk and paste in the PSK value. Click Ok, make sure Enable Decryption is selected and the WLAN Data packets should now be decrypted in Wireshark. Figure 20.2 shows an example of the Wireshark interface to set the PSK.

---

---

Now you can analyse the capture of the decrypted WiFi packets.