calebmadrigal
Randomized MAC address
Hi, is there any solutions to use with trackerjacker to de-rendomize mac address for Apple, Android devices,...
(im not the author, i'm just chiming in) As far as I understand it, the MAC is only random when it is probing for APs stored in the known networks list. Once found, it connects to the AP with it's true MAC. So you can still track people, you just have to wait for them to connect to their AP and reveal their MAC.
An interesting thing about these MACs is that the randomized MAC tends to NOT resolve to a known manufacturer in oui.txt. It could be an interesting addition to label those devices as such for filtering, the way a FingBox does.
Depending on how dense the area is where you are, you might be able to just ignore the randomization issue. Consider this scenario: You live in a house with a long driveway and want to know when someone is driving up it. You place a raspberry pi sensor near your mailbox and have it triggered on any probe request at all. This would notify you much earlier than waiting for the device to connect to an AP.
I kinda remember reading something about a flaw in the MAC generation algo in early on when they started doing it, but it's probably patched.
(im not the author, i'm just chiming in) As far as I understand it, the MAC is only random when it is probing for APs stored in the known networks list. Once found, it connects to the AP with it's true MAC. So you can still track people, you just have to wait for them to connect to their AP and reveal their MAC.
An interesting thing about these MACs is that the randomized MAC tends to NOT resolve to a known manufacturer in oui.txt. It could be an interesting addition to label those devices as such for filtering, the way a FingBox does.
Depending on how dense the area is where you are, you might be able to just ignore the randomization issue. Consider this scenario: You live in a house with a long driveway and want to know when someone is driving up it. You place a raspberry pi sensor near your mailbox and have it triggered on any probe request at all. This would notify you much earlier than waiting for the device to connect to an AP.
I kinda remember reading something about a flaw in the MAC generation algo in early on when they started doing it, but it's probably patched.
Do you have any scripts to implement in RPi ?
Can you share more information about the paper you read, also my objective is to get the real mac address of device when they are not connected to an AP.
Do you have any scripts to implement in RPi ? No, I need to brush up on my python first.
Can you share more information about the paper you read, also my objective is to get the real mac address of device when they are not connected to an AP.
https://www.theregister.co.uk/2017/03/10/mac_address_randomization/
they link to the technical paper, which is here: A Study of MAC Address Randomization in Mobile Devices and When it Fails
From page 16:
The result of sending a RTS frame to the global MAC address of a device performing randomization was that the target device responded with a CTS frame. A CTS frame, having no source MAC address, is confirmed as a response to our attack based on the fact that it was sent to the original, crafted source MAC address. A full device listing utilized for the control frame attack is available in Appendix D.
Once the global MAC address is known, that device can be easily tracked just as if randomization were never enabled. This might cause one to wonder why vendors would go to such lengths to include MAC address randomization in a device only to allow that same device to divulge the protected information through an administrative protocol. We assert that this phenomenon is beyond the control of individual vendors. The fact is that this behavior occurs across the board on every device we have physically tested as shown in Appendix D. This leads us to believe that RTS/CTS responses are not a function of the OS, but of the underlying IEEE 802.11 chipset. Manufacturers have configured their chipset hardware with default RTS/CTS operation which may not even be accessible to configure at the OS level. If we are correct, this derandomization issue can not be fixed with a simple patch or OS update. Susceptible mobile devices will be unmasked by this method for the lifetime of the device. Additionally, due to the hardware level nature of this phenomenon, there will be a significant delay in the market until mobile devices resistant to this attack are produced, assuming manufacturers recognize this as a flaw and subsequently design a process ..snip..
Additional tests, while the target device had WiFi or Airplane-modes, enabled or disabled respectively, revealed further concerns. Namely, Android devices performing location-service enabled functions wake the 802.11 radio. Our RTS attack was thusly able to trigger a CTS response from the target, circumventing even extreme privacy countermeasures.
So that looks like a way to have trackerjacker de-anonymize devices.
- On startup, generate a attacker MAC to use to send RTS frames
- read a list of targeted known MACs from config or cmd line
- each second, send out a single RTS frame to a targeted MAC and listen for any CTS frame that contains your attacker MAC (within 1 second?)
- After getting response, send another identical one just to be sure that it's the right MAC and not a lagged response.
- if no reply, try the next target.
This would be pretty killer functionality for trackerjacker as I don't think any other tool is doing this currently. It's of limited use of course, since you need to know the desired MAC, and if you do, that's probably because it's associating to an AP near you. If your listening post is a static location, you probably wouldn't typically see this known MAC sending randomized probes anyway since it would just always be associated to a nearby AP.
There's other good tips in the paper though, like using the WPS UUID-E guid to determine the global MAC. Do you have room for a 2.5TB rainbow table on your laptop? :D