Mobile Phone Tracking, an Experiment Validation

By Jesse Buonanno

Introduction

The purpose of using a vMAC (virtual media access control address) was to prevent tracking of mobile devices. However, due to poor implementation, or no implementation at all, many devices are still able to be tracked. Figure 1 shows how a vMAC is determined. If the universal/local bit is set, then a MAC is determined to be virtual.

1

The most common vector taken advantage of is the probe request. Probe requests are sent out periodically by the mobile device to look for access points in the area. This can be done through broadcast or targeted probe requests. To track a device, these requests will be passively monitored and fingerprinted to isolate a single device from other that may also be using vMACs. Techniques for tracking [1] and for fingerprinting [2] will be validated and combined to bypass protections provided in current implementations of using a vMAC. Testing was done on an iPod (MKH22LL/A) IOSv10.3.1, LG Nexus 5x Android 6.0 and a Google Nexus 6p Android 7.1.2.

Validation Results

IOS vs Android

Currently, vMACs are implemented differently between IOS and Android. IOS does a better job of using vMACs more frequently. For example, occasionally on both Android devices, while not connected to an access point, broadcast probe requests would alternate between using vMACs and media access control addresses (rMACs). In doing so, completely defeating the purpose of vMACs. Both IOS and Android do NOT use vMACs for directed probe requests, allowing an attacker to monitor them as well.

IOS is a little peculiar in its MAC prefix. Organizations should purchase MAC prefixes from IEEE to ensure global uniqueness. However, when using vMACs, IOS does not have a unique prefix or even adhere to the IEEE standard. Instead, IOS creates a uniformly distributed MAC address that will potentially not be unique. Despite the randomness, the universal/local bit is still always set, establishing the MAC as virtual. This odd technique was validated [1]. Android does adhere to the IEEE standard and has reserved the prefixes DA:A1:19 and 92:68:C3 for vMAC usage. Again, this was confirmed in my testing [1].

Sequence Numbers

A sequence number is information that can be tracked from one packet to another in the 802.11 frame. For each packet sent out by the device, the sequence number is increased by 1. This continues until it reaches 4096, for a total of 12 bits, where it then resets to 0. If packets are fragmented, the same sequence number will be used for all fragmented packets if the total number of fragmented packets doesn’t exceed 16, or 4 bits.

Where sequence numbers become interesting is that they change predictability, with or without using a vMAC. If a device sends out a directed probe request with its rMAC and then sends out a global probe request using its vMAC, the sequence number still increases by one. The pattern can then be followed for all subsequent packets that use a vMAC. This observation was confirmed [1].

Global vs Directed Probe Requests

Probe requests are 802.11 management frames that probe the area for possible SSIDs to connect to. In the global probe request, a broadcast is sent out to all SSIDs in the area for information about what they provide. If a specific SSID wants to be checked to see if it is in range, a directed probe request is used. The differences between how probe requests are handled was stated in the IOS vs Android section. Directed probe requests can also allow for a karma or evil twin attack. Although discussed in the paper, I deemed them too invasive for the type of tracking I was looking for.

Authentication and Association Frames

Authentication and association frames are like directed probe requests in that they are sent with the device’s rMAC. In combination with a deauthentication attack, the device would continue to try to reconnect to the access point. In the same manner as the evil twin and karma attack, deauthing the device to provoke authentication/association frames would be too invasive for the level of stealth I was looking to achieve. It is worth noting that claims made in [1] are valid and confirmed regarding both these frames.

RTS Frame Attack

The RTS frame attack was the one I was the most excited to test. Upon sending a RTS frame containing the targets rMAC and a random SSID, it should respond with a broadcast CTS for the specified random SSID. The existence of the CTS frame and the attacker specified SSID would allow the device to be tracked with little effort. If the device was in the area, a CTS frame would be seen, else it was not in the area. Although this attack is active, it’s not nearly as invasive as the other attacks. Unfortunately, I was not able to replicate the attack. Even after capturing legitimate RTS frames and replaying them to the device on different channels with correct checksums, the devices did not respond. Future work would be reaching out to the authors and seeing how this attack was carried out as it the most interesting of the describe attacks. As of now, it remains unverified.

vMAC Probe Request Fingerprinting

In addition to tracking sequence numbers, fingerprinting techniques can be used to further determine if a packet belongs to a desired device. A strong fingerprinting technique is to look at the order of 802.11 frame parameters. Often, they will vary greatly between device models. This method claims ~80% accuracy when looking at broadcast probe requests [2]. The content of some parameters can be considered. For instance, the content of the channel and SSID parameters will vary, and thus would not allow useful fingerprinting of the device. Figure 2 shows the 802.11 parameters of a broadcast probe request from the testing iPod.

2

Figure 2: Packet capture of 802.11 broadcast probe request using vMAC

Attack Implementation

Attack Flow

To track a device, the attack uses a couple different techniques. The first is sequence number tracking stated previously. A baseline sequence number is created when a packet is seen containing the target’s rMAC. On every successful identification of the target, the baseline sequence number is increased. In testing, it was found to be more effective to specify a range of sequence numbers to allow. This allows us to account for packets that were not sniffed, for a wide range of reasons, and if the device temporarily moved out of attack range while still not being associated to an access point. Implementing sequence number tracking this way did not come without tradeoffs, which will be discussed in the considerations section.

The second attack implemented was the fingerprinting technique. Once a baseline is established with sequence numbers, it can be followed to the next packet with a vMAC and fingerprinted. Doing so enables further accuracy going forward. However, again there is a tradeoff to using this technique as there is a guess made between the baseline sequence number and fingerprinting a packet. This will be discussed further in the considerations section.

Assuming currently updating sequence number baselines and a correct initial fingerprint the device will continually be tracked. This implementation is passive only [3]. There is no active interaction between the attacker and the tracked device.

Assumptions

This attack assumes the following:

  • You know the MAC of the device you are looking for
  • You are in range of your target
  • You know if the device is IOS or Android
    • Not required but will help accuracy due to reasons specified in IOS vs Android section

Considerations

Paper [2] roughly claims ~80% accuracy on fingerprint techniques. However, it does not consider combining sequence number and 802.11 parameters together OR how good 802.11 parameters are for distinguishing separate devices of the same model. It’s still not clear how much same device types differ from one another in their probe requests. A larger sample size of devices would need to be tested specifically for this.

Adjustments for sequence numbers needed to be made to account for packet loss and devices not being in range. To determine how likely it would be to pick the incorrect device after gaining an initial sequence number baseline, the following formula was used: (1- (1-25/4096)^M )∗100. This calculates the likelihood that the wrong device will be picked after an initial baseline for a sequence number range of 25 and for M MACs in the receiving area. For a better understanding, Figure 3 extrapolates out the number of device in the area and the likelihood that the attack will not pick the desired target. Less than 113 devices need to be within range of one’s receiver to achieve 50% accuracy on the first tracking attempt.

3

Figure 3: Likelihood of Missing target on first try with M, MACs in area and sequence number range of 25.

Conclusion

Current implementations of vMACs are broken. It was shown that 100% passive attacks allow for device tracking even with best case uses of vMACs. Even still, there is room for improvements in the script. Such improvements could be combining more fingerprinting techniques to increase accuracy and adding RTS attack functionality. I still feel it is possible to validate the RTS attack despite current failed attempts. How the script operates allows for tracking in seemingly large areas where less than 100 devices are present. If the RTS attack were functional, an incredibly large number of devices could be in the area and it would still give 100% accuracy. However, the attack would then become active. All other aspects of paper [1] were verified except UUID fingerprinting as it only affected a small range of devices and required a large amount of precomputation, like rainbow tables.

 

References:

[1] Martin, Jeremy, et al. “A Study of MAC Address Randomization in Mobile Devices and When it Fails.” arXiv preprint arXiv:1703.02874 (2017). [https://arxiv.org/pdf/1703.02874v1.pdf]

[2] Vanhoef, Mathy, et al. “Why MAC Address Randomization is not Enough: An Analysis of Wi-Fi Network Discovery Mechanisms.” Proceedings of the 11th ACM on Asia Conference on Computer and Communications Security. ACM, 2016.

[http://papers.mathyvanhoef.com/asiaccs2016.pdf]

[3] https://github.com/Bojak4616/Mobile_Phone_Tracking

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s