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

** 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...)

Popular posts from this blog

The 5GHz “Problem” For Wi-Fi Networks: DFS

-
Image
Wi-Fi networking provides us with 2 bands for the operation of wireless LAN networks: the 2.4Ghz band and the 5GHz band. The 2.4GHz band has a reputation of being something of a “sewer” of a band, due to its limited number of usable channels, the number of Wi-Fi devices already using the band, and the high levels of non-Wi-Fi interference that it experiences. Many wireless LAN professionals will generally advise that you put your “important stuff” on the 5GHz band whenever possible. 5GHz has far more channels available, a corresponding lower number of devices per channel, and generally suffers much lower non-Wi-Fi interference. However, beneath the headline of “2.4Ghz = bad, 5Ghz = good”, there lurks a shadowy figure that can be troublesome if you’re not aware of its potential impact: DFS. Background Wi-Fi networks operate in areas of RF spectrum that require no licence to operate. This is in contrast to many other areas of the radio spectrum that generally require some form of (p
Read more

Microsoft NPS as a RADIUS Server for WiFi Networks: SSID Filtering

-
Image
The Microsoft Network Policy Server (NPS) is often used as a  RADIUS server for WiFi networks. It can provide authentication and authorization services for devices and users on a wireless network in a Windows Active Directory environment. In this article we look at how we can use NPS to provide authentication for WiFi users across a number of SSIDs. We have previously discussed how to authenticate groups of users using the same SSID and then assign them to a VLAN that is appropriate to their security authorization. However, there may still be instances where two or more SSIDs are in-use on a wireless network and we would like to base policy decisions on the SSID that the authentication request is being generated from. As an example, if we consider a school, perhaps we would like students to only be able to authenticate if they connected to the SSID: "Student_Net". Similarly,  staff should only be able to connect using the SSID: "Staff_Net". This would
Read more

What Are Sticky Clients?

-
Image
One term you'll often hear banded about when talking with Wi-Fi professionals is "sticky clients". I thought it might be worth spending a few moments exploring what is meant by "sticky clients", why they are generally considered to be a bad thing in Wi-Fi networks and some approaches to mitigate them. Background Many folks dealing with Wi-Fi networks often talk about the "sticky" characteristics of wireless clients when discussing client roaming within a W-iFi network. In an ideal world, we'd like to have access points providing ubiquitous coverage across our desired area providing high-quality, consistent client coverage where-ever we go. In this wonderful land of rainbows and unicorns, our clients would gracefully roam from AP to AP, detecting and associating with their closest AP throughout the coverage area to ensure their best connection speed at all times. Unfortunately, the real world doesn’t quite reflect this roaming-client
Read more