Capturing Roaming Events

Finally! I scored a newer laptop to put Kali Linux on along with Windows to do some more wifi shenanigans. Before I was using a WLANPi on my desktop, which limited my mobility of course. Now I can follow devices and get closer to some of my other APs.

Yes I know you can also use Pi as a remote capture device but that still didnt help with looking into roaming events.

Now its been a few years since Ive used Kali and I was amazed at how polished its become. I think I used Backtrack about a decade ago to try and 'hack' my wifi with a WPA cracking tool. Needless to say that didnt launch my security career but it was quite interesting.

There are plenty of tutorials on how to set you capture device in monitor mode so I wont go into that here. If you are curious here is the Airmon-ng website. Please note only certain chipsets are supported in Kali for this.

Atheros cards seem to be the defacto standard for monitor mode support but I had a Comfast CF912 and TPLink Archer T9UH adapter on hand. They use the Realtek 8812 and 8814 chipset respectively. To my surprise the 8814 was supported and did not appear to give me any issues.

With both adapters setup on the necessary channels I was able to try and capture a roaming event. My network uses Unifi APs so we'll be viewing FT over the Air events.

There are a few things to look for when capturing roaming events:

  • When the roam initiates
    • This is usually seen when the client starts probing for other APs nearby
    • Neighbor report frames should also be in the mix but I did not see any action frames containing these
      • The correct bits are enabled in the probe response but I couldnt see anything
      • wlan.fixed.action_code == 0x05 should filter out these
  • Knowing what AP (and channel) the device is likely to roam too
    • If you have a high density deployment with gracious overlap you might need 3 or 4 adapters
    • Im sure the CWDP might have something to say about this but I believe Cisco recommends at least 3 APs within the area of a device of similar RSSI at the device
  • Knowing the MAC of the APs and the device in question
    • This will just make life easier when sorting everything out
  • Another thing to have setup would be some Coloring Rules to easily identify specific frames in your protocol analyzer.


Once I had the event captured I merged the files to make things a bit easier to sort through.


Going over the files I noticed that my device (Pixel 6a) started looking for other stations when it was nearing a RSSI of -70. This tracks since it sometimes sticks to my living room AP instead of roaming over to my bedroom one.

(Probe Response from current AP with RSSI at device)

Since Roaming is a client decision I wonder if this is set to promote better wifi calling which usually recommends -67 or better.

Moving through the capture the Authentication frames are first up. There is only one frame type but both contain additional information over the standard OSA frame exchange.

 
 (Supplicant Authentication Frame)
 
(Authenticator Authentication Frame)

Each contain similar IE's like RSN Info, Group Cipher Suite, Mobility Domain and Fast BSS Transition. The main difference in both is the information held in the RSN and Fast BSS IEs. These also contain additional key information used to re-associate the client.

If youre wondering about the security concerns of sending key data over an open medium you are not alone. Around 2017 the KRACK exploit found it was possible a bad actor to reuse message 3 during BSS FT to find out the security keys and potentially decrypt packets from a particular client. Protected Management frames should have essentially made this attack vector very small at this point but we know not every network is configured with this. If you would like to read more visit this website.

Now for the Reassociation Request and Response or Message 3 and 4. Frame 3 contains information similar to the originals with some additional information, mainly the full SNonce and ANonce. I did post a while back about the 4 way handshake which is essentially what these frames are. 

 
(Request)
 

(Response)

If everything is successful then the client is able to roam to another AP. I did notice a data frame preceding the Disassociate frames from the AP. I dont know if this behavior varies depending on each vendor or if it is normal. Most of my literature does not explicitly state this. More research might be required.

Lastly Ill leave you with a screenshot of exchanges went.






Comments

Post a Comment

Leave a comment...

Popular posts from this blog

IoT and Smart Home Devices: Part 1

Image
  Source: https://www.sparkfun.com/products/17146                 This is going to be a multi part post going over a little IoT smart plug I picked up on clearance at Walmart. I'll make it clear I'm generally very skeptical about these types of devices so much that I don’t even want my roommates Alexa on the same network as mine. However with these things being so prolific it is best to understand them so we can better protect our networks. Ill start with a little background of the device, how I acquired it, and my research on the brand. I will then do my best to uncover any (hopefully) FCC filings and their documentation. From there we will explore a bit of the theory on how the majority of these cheaper devices connect to our networks. Lastly Ill do my best to capture packets during the join process but we will see how that goes with my limited setup.  I was looking to purchase a new Roku and since Walmart was the closest st...
Read more

Frame Exploration: Authentication Frames

Image
Authentication Frames in 802.11 are not about verifying the identity of clients or forming a secure connection. These frames are used to ensure each radio is actually a valid .11 device that can communicate on the network. It has been described similarly to plugging a network cable into the wall or switch.  Please note this is only valid for networks using WPA or WPA2. WPA3 introduces SAE (Simultaneous Authentication of Equals) and uses a 4 message exchange for authentication. We will be looking at Open System Authentication frames here.  In the above we have the two frame exchange between the client device and the AP. Each message is the essentially the same and contains a Sequence Number and Status Code to tell whether or not authentication was successful.  As with all other frames we can look at the FCF to verify what type of message it is too. And that's all there really is to it. If each radio can authenticate with one another they can proceed to the Association stag...
Read more