MAC address randomization

[haydenth]

Hey! Cool library. Out of curiosity, how does this handle MAC address randomization? Will it double count?

[schollz]

It does not handle MAC address randomization.

To be honest, I can't tell if this matters yet. I haven't seen any MAC randomization take place yet even though the people around me have iPhones and I have a Pixel which all supposedly do randomization. However, in my use-case the phones are affiliated, which, I suppose does not prompt the randomization. But I've run this in a place where people may be unaffiliated with the network, and even then I do not see tons of random MACs yet....

[ansell]

The OUI check may be removing some (at least iOS) devices where the randomized mac falls into unrecognised ranges. I opened #13 to track making it optional.

[schollz]

Here is an interesting paper: https://arxiv.org/pdf/1703.02874.pdf

It seems to suggest that certain phones use a very specific OUI for their randomization, which will allow detecting them as cellphones (though one would be unable to track them individually). It seems that only iPhone has a random MAC address

[DustinAlandzes]

the same paper schollz linked mentions sending a Request-to-Send (RTS) frame, if you already know the global MAC.

So if my phone's MAC is "00:01:02:03:04:05", i figure I could use scapy/libtins to send an RTS frame with "00:01:02:03:04:05" as the receiver address (RA). And my phone, having this mac address, would reply with a Clear-to-Send (CTS) frame, so I would know it was in proximity.

Maybe you could just send out RTS frames for every possible mac address for a manufacturer.

for example, I used https://www.wireshark.org/tools/oui-lookup.html to find one of apple's OUI's: 00:03:93 so just send out RTS frames for every MAC address from 00:03:93:00:00:00 to 00:03:93:FF:FF:FF

if a phone with that MAC address exists, then it would reply with a CTS frame and you would know it was near you.

This is a pretty active technique, though

[victorhooi]

Hmm - that's 24 bits worth of MAC addresses to try.

2^24 = 16,777,216

That is an awful lot of MAC addresses to brute force...lol.

I'd like to see if there's a solution the MAC randomisation problem as well though.

[allnash]

Yeah, I think they all randomize MACs.

I have found out that real Mac address will be included in the list of addresses captured. Unfortunately the wildcard filter does not help with uniques.

[Timru]

This discussion may be a year old but i'm currently working on my master thesis investigating randomization behaviour and how to circumvent it in order to track devices.

Regarding apple devices (the ones i've tested): I didn't see any randomized adresses so far. Yet i was unable to perform the RTS/CTS attack targeting the global MAC of the device. The attack was succesfull on all other testing devices.

More importantly: Apple devices seem to use the RTS/CTS mechanism on their own and reveal constantly their global MAC. So besides probe requests there is a second source for device tracking. Here is an article from 2014 regarding this behaviour https://www.sniffwifi.com/2014/05/why-are-you-slowing-down-my-wifi-apple.html

[schollz]

@Timru Thats cool, thanks! Do you know if tshark can extract that information?

[Timru]

I'm using scapy to capture packets but i'm sure tshark should be able too. You have to filter for packets with type = 1 and subtype = 12 (CTS).... type = 1 & subtype 11 is RTS. I've also looked into your code regarding device counting and you should include 'unkown' types in your filter because many chinese manufacturers dont have a officially registered oui but a private one.

I'm working on an approach to deliver precise information about present devices because in my opinion probe requests are not sufficient enough due to differences in probing rates.

[schollz]

@Timru Do the RTS/CTS messages also have RSSI information?

[Timru]

I will look later into it... Personally i'm not a huge fan of RSSI information because of the variance after certain distance. Interestingly you can also use RTS/CTS for indoor localization which can be achieved by comparing timestamp information in the packets in contrast to RSSI strength. See http://www.ece.umd.edu/~zcui/Publications/Mobiquitous2015.pdf

[stipe42]

We did wifi tracking at a major fair with 60k people a day with 4 raspis monitoring probe requests, last month. We captured more than 4.5 million packets and found that 80% of all MAC addresses were randomized.

[brasdata]

stipe42 could you give us details on your rpi setup, we would like to run some tests at an upcoming event.

[feochoa]

@timru it appears you couldn't perform RTS/CTS attack targeting Global MAC as per your paper https://ieeexplore.ieee.org/abstract/document/8730828 It is odd that Martin et al claim to have a 100% success even in randomized devices.

[Timru]

@feochoa It depends how you define 100% success... I tried the attack and the devices only respond upon sending a probe request containing the real device MAC. In this case, we would see the device anyway over the probe request and wouldn't need the RTS/CTS packets in the first place. To me it looks like Martin el al spammed RTS messages to global MAC of devices and received CTS responses without taking into account when or why these responses happen. So yes, the attack works against 100% of devices but only when the device is sending out a probe request with its real MAC. I was quite disappointed by this as the application of this attack should have been the foundation of my master thesis and turned out to be rather useless. I just hope that i didn't make any mistakes reproducing the attack but i did not find any code/papers that actually support the initial purpose of this attack: Pinging a device by its global MAC and receiving an answer any time.

From Matte: "Unlike previous work and our own tests, they claim to reach a success rate of 100% with the RTS attack." - sounds to me like they were not successful either at performing the attack.

[ahmedcharef]

@feochoa It depends how you define 100% success... I tried the attack and the devices only respond upon sending a probe request containing the real device MAC. In this case, we would see the device anyway over the probe request and wouldn't need the RTS/CTS packets in the first place. To me it looks like Martin el al spammed RTS messages to global MAC of devices and received CTS responses without taking into account when or why these responses happen. So yes, the attack works against 100% of devices but only when the device is sending out a probe request with its real MAC. I was quite disappointed by this as the application of this attack should have been the foundation of my master thesis and turned out to be rather useless. I just hope that i didn't make any mistakes reproducing the attack but i did not find any code/papers that actually support the initial purpose of this attack: Pinging a device by its global MAC and receiving an answer any time.

From Matte: "Unlike previous work and our own tests, they claim to reach a success rate of 100% with the RTS attack." - sounds to me like they were not successful either at performing the attack.

Do you have any code for RTS/CTS attack, any py package different from scapy to perform this attack ? We can collaborate and work together to make it, i'm working in this attack since January ..

[feochoa]

@feochoa It depends how you define 100% success... I tried the attack and the devices only respond upon sending a probe request containing the real device MAC. In this case, we would see the device anyway over the probe request and wouldn't need the RTS/CTS packets in the first place. To me it looks like Martin el al spammed RTS messages to global MAC of devices and received CTS responses without taking into account when or why these responses happen. So yes, the attack works against 100% of devices but only when the device is sending out a probe request with its real MAC. I was quite disappointed by this as the application of this attack should have been the foundation of my master thesis and turned out to be rather useless. I just hope that i didn't make any mistakes reproducing the attack but i did not find any code/papers that actually support the initial purpose of this attack: Pinging a device by its global MAC and receiving an answer any time. From Matte: "Unlike previous work and our own tests, they claim to reach a success rate of 100% with the RTS attack." - sounds to me like they were not successful either at performing the attack.

Do you have any code for RTS/CTS attack, any py package different from scapy to perform this attack ? We can collaborate and work together to make it, i'm working in this attack since January ..

I think the best way to address this issue is to fake hundreds of common APs SSID to force the phone to drop the real MAC like https://null-byte.wonderhowto.com/how-to/use-esp8266-beacon-spammer-track-smartphone-users-0187599/

[Timru]

@feochoa It depends how you define 100% success... I tried the attack and the devices only respond upon sending a probe request containing the real device MAC. In this case, we would see the device anyway over the probe request and wouldn't need the RTS/CTS packets in the first place. To me it looks like Martin el al spammed RTS messages to global MAC of devices and received CTS responses without taking into account when or why these responses happen. So yes, the attack works against 100% of devices but only when the device is sending out a probe request with its real MAC. I was quite disappointed by this as the application of this attack should have been the foundation of my master thesis and turned out to be rather useless. I just hope that i didn't make any mistakes reproducing the attack but i did not find any code/papers that actually support the initial purpose of this attack: Pinging a device by its global MAC and receiving an answer any time. From Matte: "Unlike previous work and our own tests, they claim to reach a success rate of 100% with the RTS attack." - sounds to me like they were not successful either at performing the attack.

Do you have any code for RTS/CTS attack, any py package different from scapy to perform this attack ? We can collaborate and work together to make it, i'm working in this attack since January ..

I think the best way to address this issue is to fake hundreds of common APs SSID to force the phone to drop the real MAC like https://null-byte.wonderhowto.com/how-to/use-esp8266-beacon-spammer-track-smartphone-users-0187599/

Like the article states this is a Karma attack which is likely unlawful in business oriented use cases like crowd counting.

Do you have any code for RTS/CTS attack, any py package different from scapy to perform this attack ? We can collaborate and work together to make it, i'm working in this attack since January ..

I tried the attack both with SCAPY and its C++ equivalent libtins with no real success besides getting responses upon sending out a probe request by the device. For the code i would have to check some old repos.

[ahmedcharef]

@Timru I have tried the RTS/CTS attack but different phones not detected, do you know how to calculate the duration of RTS send ?

[feochoa]

I think the best way to address this issue is to fake hundreds of common APs SSID to force the phone to drop the real MAC like https://null-byte.wonderhowto.com/how-to/use-esp8266-beacon-spammer-track-smartphone-users-0187599/

Like the article states this is a Karma attack which is likely unlawful in business oriented use cases like crowd counting.

@Timru I agree that this is the first step of Karma attack, but you can also perform a DoS attack with RTS packets which is unlawful too. In my opinion, the key here is the ethics of the implementation. Cheers.

[ahmedcharef]

I think the best way to address this issue is to fake hundreds of common APs SSID to force the phone to drop the real MAC like https://null-byte.wonderhowto.com/how-to/use-esp8266-beacon-spammer-track-smartphone-users-0187599/

Like the article states this is a Karma attack which is likely unlawful in business oriented use cases like crowd counting.

@Timru I agree that this is the first step of Karma attack, but you can also perform a DoS attack with RTS packets which is unlawful too. In my opinion, the key here is the ethics of the implementation. Cheers.

Do you have any useful scripts to do that ?

[matteopeluso]

Hello, did we had some improvements on the management of the random MAC addresses?

[feochoa]

@matteopeluso maybe it can help https://arxiv.org/abs/1906.02686

[DP-M]

In the naval academy paper, I believe they said there is a vendor specific Information Element in the management frame of the probe request which sends a unique value tied to that phone, but I haven't been able to find any other reference to that anywhere else on the interwebz... Am I interpreting that correctly?

Specifically, they said:

... the addition of an Apple vendor specific IE was added to all transmitted probe requests. This made identification of iOS 10 Apple devices trivial regardless of the use of MAC address randomization ...... the data field associated with this IE never changes across devices.

For my use case that would be plenty sufficient, even if it doesn't necessarily match the MAC address.

My use case, would actually even be satisfied by being able to identify a small number of known IOS mac addresses in a non-associated environment. Specifically I'm looking to do access control/tracking for known IOS users, without access points nearby.

@Timru - Do you have any sample python code available that you used when you were probing known IOS MAC addresses?

[arihantdaga]

Hello Guys, I wanted to use this for tracking mass gathering in an area during Covid 19 periods and i too faced this issue, almost all my android/ios mobiles are using randomized Mac Ids now. So even if I have only one phone, it'll be counted as 4-5 or 10. The mac address keeps changing randomly when it is not connected to any network. Is there any solution to this problem?

[Timru]

Hey, back when i did my thesis on this i talked to two companies specialized in WiFi tracking/counting and they told me that its not possible to overcome randomization. They get very accurate results using statistical analysis and prediction methods mostly using the vendor identification. Or you simply estimate crowd size based on devices that are not using randomization. So if 10% of your devices are not using randomization then you can predict total amount of phones by multiplying with 10. (very simple example) Or you get some groundtruth data by counting people in your venue manually and then try to predict that data with the number of probe requests you observed..

Also not every persons carries a wifi enabled device while some carry multiple devices so its never possible to directly map number of devices to number of people. With MAC randomization you just get more noise and have to model more statistically.

[arihantdaga]

@Timru thanks very much

[gvivekchary]

Can anyone help in sample code for RTS/CTS attack or i want to send RTS frame with one ESP32 and i want a nearest mobile or another ESP32 have to respond with CTS Frame. Can i get any basic code to start with. I got all the theory but not able to figure out the code

[gururise]

With mac address randomization on a significant number of devices now, since the code is only scanning for particular oui's, we are probably grossly underestimating the number of people around.