Sunday, 20 May 2018

Updated White Paper on Licence-Exempt Spectrum in the 5GHz band for Wireless LANs in the UK

For the past few years, I've maintained a white paper on the use of the 5GHz spectrum for Wi-Fi networks here in the UK. As Wi-Fi text books tend to focus on the spectrum available in the USA, I put this document together to clarify how 5GHz spectrum may be used in the UK.

Following the release of a Voluntary National Specification document by Ofcom in August 2017 (VNS 2030/8/3), additional channels became available for use in the UK on 5GHz.

As we now have additional spectrum, it's time for an update to my white paper to detail the new spectrum that is available.

Prior to updating the white paper, I published a summary sheet that shows the new spectrum allocation. This can be obtained obtain from my previous blog article: UK 5GHz WLAN Spectrum Allocation (August 2017) (this is definitely one to print off and laminate).

I have now completed my updates to the white paper, which I am pleased to share with you now. Note that in addition to adding the new spectrum details, I have added a few other topics around the use of 5GHz and the unique challenges that it presents. I'd recommend taking a look at my description of how DFS operates in Appendix 2, and have a play with the Opera weather radar location tool shown in Appendix 3.

I hope you find the update useful and informative.

Links:





Saturday, 21 April 2018

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:



Friday, 6 April 2018

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