Scapy 802.11 Cheat Sheet

I've been taking a look at Scapy as I've been learning more about Python. It's a great Python-based tool for capturing, analyzing and creating network packets. There are some great resources to learn more bout Scapy, and even some cheat sheets out there.

But, as there were quite a few new concepts (for me) and my own interest is in Scapy for 802.11 related activities, I put together my own Scapy for 802.11 cheat sheet. You can grab a copy from here if it may be useful to you.

References:

• Scapy 802.11 cheat sheet 
• Scapy docs: https://scapy.readthedocs.io/en/latest/
• Building Network Tools With Scapy
• SANS Scapy Cheat Sheet

Randomized MAC addresses in 802.11 Probe Frames

To address perceived privacy issues, some wireless clients adopt a randomized MAC address in probe frames when probing  for wireless networks. In this post  I take a quick look at how you might see clients using randomized MAC addresses. 

Background

When a wireless LAN client needs to find a nearby access point to join a Wi-Fi network, it has two choices:

• Passive scanning: a client will listen to beacon frames, broadcast by nearby access points, that advertise networks that it makes available. This can be quite a slow process, as a client cycles though channels and waits to hear beacons.
• Active scanning: a client will cycle through channels and send out probe frames to proactively query nearby APs for a specific wireless network (SSID). This will generally be a faster method of finding networks that the client is configured to join, and may be used by all clients in conjunction with passive scanning.

One (unfortunate) side-effect of active scanning is that a client advertises its presence to anyone listening for probe requests in the vicinity. Even if the client is unsuccessful in finding and joining a network, it advertises its presence by continually probing for networks that it has been configured to join. The MAC address of the probing client’s wireless NIC is present, in the clear, in every probe request. 

The availability of the client MAC address, which is unique to that client, presents some potential privacy issues. Organisations that have wireless networks in multiple locations could, in theory, track the location of the client as it moves between sites. When coupled with other data sources (e.g. a login to a guest wireless portal for instance), it could allow tracking of an individual and gathering of behavioural data.

In order to combat these privacy concerns, some client vendors have taken the decision to randomise the MAC addresses that are used when probing for networks. This ensures that a client cannot easily be tracked as it moves between locations. Clients may use a randomised address to discover networks, but then revert to their “real” MAC address once they choose to join a network.

Testing

Although I’ve read about this behaviour, I’d never observed it first-hand. However, I recently spotted it, by accident, while testing some wireless tools. The tool that I was looking at was the ‘airodump-ng’ tool, which is part of the ‘Aircrack’ toolset. Aircrack is a suite of Linux-based pen-testing tools.

Airodump-ng is a wireless scanner that reports wireless networks, detected via beacons, from nearby access points. It also reports clients that can be heard probing in the vicinity. A screen-shot of the tool is shown below -  the top of the display shows the detected networks (discovered via beacons), the lower part of the display shows the clients (also know as stations) that can be heard probing.

Airodump-ng is generally used to scan across multiple channels to gather network and client data. However, it may also be configured to scan on a single channel of interest.

During my testing, I configured to my airodump-ng machine to scan on channel 52, as I knew there was an AP nearby using that channel. However, I noticed that in addition to the network I expected to see, I saw a client probing for a network called “Hidden _SSID”. This is a non-existent network that I had configured on my nearby MacBook Pro while doing some testing earlier in the day. I noticed, however, that the MAC address of the probing client was different to the actual MAC address of my MBP. 

I disabled and re-enabled my MBP wireless adapter several times. Each time I did this, a new MAC address appeared in the airodump-ng client list as the MBP probed with a new, randomised, MAC address. This is Apple MAC address randomization in action. You can see the effect in the screen-shot below:     

This is an interesting demonstration of the randomised client behaviour employed by Apple devices (among others). I thought this post might be useful for others who have not observed this feature, or perhaps aren’t aware that some clients exhibit this behaviour. 

I tried looking up some of the OUIs used in the randomized addresses using the online Wireshark OUI checker, but none of them corresponded with known manufacturer OUIs. The MAC addresses observed didn’t seem to be derived in any obvious way from the true MAC address of the MBP, they appear to be completely randomised.

References

• MAC address randomization joins Apple's heap of iOS 8 privacy improvements
• Aircrack-ng
• Wireshark OUI Lookup Tool

** Update 7th Apr 2018

I received a Tweet from Arsen Bandurian about the randomized MAC addresses used by the Apple devices:

As he correctly states, the randomized MAC addresses being used are locally administered MAC addresses.  You can recognize a locally administered address by inspecting the 2nd least significant bit of the 2nd byte of the MAC address. This explains why I would never have seen any hits in the OUI lookup tool.   Thanks Arsen!

(If you got to the end of this article without falling to sleep, you did jolly well...)

Wireshark Capture Filters for 802.11

Generally, when performing over the air captures of WLAN traffic with Wireshark, the workflow adopted is as follows:

• pick a specific channel where target traffic resides
• switch the capture adapter to that channel
• capture all 802.11 traffic over the air on that channel

Once a sample of traffic has been captured, the capture is stopped and analysis of the traffic using Wireshark's built-in display filters can begin.

In most situations, this is the best workflow to adopt. It ensures that all required frames are captured. Filtering wireless traffic while capturing frames is very problematic due to the complexity of 802.11 frame exchanges. It is very easy to miss parts of interactions between stations if you filter traffic as it is being captured.

However, there are a few edge cases where it may be useful to filter over-the-air frames at the point of capture. This will mean that only the filtered frames are available to display in Wireshark - all other frames are lost - but in some rare cases, this may be what you want.

Capture filters are added prior to commencing an over the air capture with Wireshark, as shown in the screen-shot below (see green highlighted text):

(Note that if the capture filter text is highlighted in red (rather than the green shown above), then there is an issue with your filter that needs fixing. You can access the screen display shown above via the Wireshark menu items: Capture > Options) 

The filter language used for capture filters is different from the built-in filter language with which most people are familiar. Capture filters in Wireshark use Berkeley Packet Filter (BPF) syntax. You can find out more about the syntax here: https://wiki.wireshark.org/CaptureFilters

I thought it might be useful to provide some examples of capture filters for 802.11 (Wi-Fi) traffic, as I didn't find many examples when Googling around.

Here are a few example filters:

• wlan type mgt - capture only management frames
• wlan type ctl - capture only control frames
• wlan type data  - capture only data frames
• wlan type mgt subtype beacon - capture only beacon frames
• wlan type mgt subtype deauth - capture only deauth frames
• wlan type mgt subtype prob-req - capture only probe requests
• not wlan mgt - do not capture management frame (i.e. capture data & control frames)
• not wlan mgt subtype beacon - capture all frames except beacon frames
• wlan type mgt and (subtype beacon or subtype prob-req) - capture only beacon  and probe request frames 
• wlan type mgt and (subtype deauth or subtype disassoc) - capture on deauthentication and disassocation frames
• (wlan type data) or (wlan type ctl and (subtype rts or subtype cts)) - capture only data frames and RTS/CTS control frames

By studying the examples above,you will likely be able to craft your own capture filters. However, you will need to understand the various types of 802.11 frame available and their roles to be able to construct valid filters (maybe take a look at the CWNA or CWAP certification programs if you are not familiar with these)

The following extract from the PCAP filter manpage provides all of the filter options available to you:

type wlan_type subtype wlan_subtype

True if the IEEE 802.11 frame type matches the specified wlan_type and frame subtype matches the specified wlan_subtype.

If the specified wlan_type is mgt, then valid wlan_subtypes are: assoc-req, assoc-resp, reassoc-req, reassoc-resp, probe-req, probe-resp, beacon, atim, disassoc, auth and deauth.

If the specified wlan_type is ctl, then valid wlan_subtypes are: ps-poll, rts, cts, ack, cf-end and cf-end-ack.

If the specified wlan_type is data, then valid wlan_subtypes are: data, data-cf-ack, data-cf-poll, data-cf-ack-poll, null, cf-ack, cf-poll, cf-ack-poll, qos-data, qos-data-cf-ack, qos-data-cf-poll, qos-data-cf-ack-poll, qos, qos-cf-poll and qos-cf-ack-poll.

Again, it is worth stressing that most of the time, capture filters are not what you want. It is very easy to miss some important interactions unless you capture all frames over the air (e.g. it is no good capturing just data frames and not seeing deauth frames that are kicking your client off the network).

References:

• https://wiki.wireshark.org/CaptureFilters
• https://www.tcpdump.org/manpages/pcap-filter.7.html