{{Header}} {{#seo: |description=MAC Address Spoofing and Tracking Threats |image=MACaddress2131.jpg }}
* [[MAC Address]] * [[Dev/MAC|MAC address (developers)]]
[[File:MACaddress2131.jpg|thumb]] {{intro| MAC Address Spoofing and Tracking Threats }} = Introduction = All network cards, both wired and wireless, have a unique identifier called a {{Code2|MAC address}}. https://en.wikipedia.org/wiki/MAC_address MAC addresses are stored in hardware and are used to assign an address to computers on the local network. The MAC address is normally not traceable because it is not passively sent to computers beyond the local router. Unless the computer is infected with [https://en.wikipedia.org/wiki/Malware malware] designed to disclose this identifier. However, other computers on the local network can potentially log it, which would then provide proof that the user's computer connected to that specific network. If users intend to use an untrusted, public network, then {{Code2|MAC spoofing}} should be considered. https://en.wikipedia.org/wiki/MAC_spoofing = MAC Spoofing Warning = {{mbox | image = [[File:Ambox_warning_pn.svg.png|40px]] | text = '''Warning:''' Reliable MAC hiding is difficult beyond practicality. MAC randomization might be unreliable. There are [[Dev/MAC#Leak-proof_MAC_Randomization_-_Technical_Implementation_Challenges|Leak-proof MAC Randomization - Technical Implementation Challenges]]. [[Whonix]] might have {{whonix_wiki |wikipage=Reliable_IP_Hiding |text=Reliable IP Hiding }} but there is no similarly dedicated, actively maintained, well tested project equivalent focusing on MAC randomization. This is a general issue with all operating systems and [[unspecific|unspecific to {{project_name_short}}]]. }} {{mbox | image = [[File:Ambox_warning_pn.svg.png|40px]] | text = '''Warning:''' According to recent research, MAC address spoofing is not effective against advanced tracking techniques that can still enumerate the address by inspecting the physical characteristics of the Wi-Fi card. [https://papers.mathyvanhoef.com/asiaccs2016.pdf Why MAC Address Randomization is not Enough: An Analysis of Wi-Fi Network Discovery Mechanisms] Unfortunately, a viable solution requires manufacturers to modify the drivers or firmware of their hardware products to implement privacy-preserving mitigations. }} = Auto-connect Risk = Beyond the challenge of generating an appropriate spoofed MAC address, there are technical hurdles related to preventing automatic network connections. A spoofed MAC address is ineffective if the computer automatically connects to a public network after booting, thereby exposing the real MAC address: * Host: {{project_name_gateway_long}} automatically connects to Tor upon startup. * USB Wi-Fi Device: Automatic connections may occur depending on the configuration. * VM Users: The host operating system is likely to automatically connect to the internet for updates, time synchronization, or other background services. = Burner Wi-Fi USB Sticks = One immediate workaround for the Wi-Fi card profiling threat is to buy new "burner" Wi-Fi USB sticks from different manufacturers. Take care to disable the computer's native Wi-Fi functionality in the BIOS settings if pursuing this option -- otherwise, the computer's characteristics may have already been logged if it was ever used on an untrusted hotspot. Burner devices should only be enabled for connectivity at the intended public destination. If this advice is ignored and burner devices are used for network connections at locations tied to or regularly visited by the user, it will defeat the original purpose. A different burner stick should be used for each new location to avoid geographical profiling and tracking. = Random MAC Addresses = {{mbox | image = [[File:Ambox_warning_pn.svg.png|40px]] | text = '''Warning:''' Using a completely random MAC address might introduce risks. While this technique might be sufficient to confuse lesser adversaries, it will not defeat skilled adversaries. }} The problem with using a random MAC address is that the chosen vendor ID may be non-existent. Even if it exists, it is possible to end up with a vendor ID that has either never been used or has not been used for decades. When spoofing MAC addresses, it is critical to use a popular vendor ID. The initial, second part of the MAC address can safely be random or unique. Also note that if MAC address changing is always enabled, it might cause connectivity problems on some networks. {{project_name_short}} cannot provide detailed instructions on how to create appropriate MAC addresses that fulfill the criteria above. = Other Location Tracking Risks = == Authentication Fingerprinting Techniques == An authentication technique can fingerprint devices by observing inter-packet timings on a LAN's wire segment; one side effect is that user devices can be tracked. The timing effects result from how various components in a machine create packets. [https://nweb.eng.fiu.edu/selcuk/papers/uluagac-gtid-cns-13.pdf A Passive Technique for Fingerprinting Wireless Devices with Wired-side Observations] Fortunately, this technique cannot be used to identify devices across the Internet. The primary weakness of this technique is that it relies on fine-grained packet timing, which is lost due to buffering in switches and routers. Therefore, this technique and similar methods are not suited for identification across the Internet. Instead, it is well-suited for the significant challenge of local network access control and other local network activities like counterfeit detection. This technique can be defeated by introducing random delays in a machine's packet stream. Since there is no issue with impersonating other devices on the LAN, it does not matter that such an authentication system will classify these machines as "unknown." Figure 7(a) shows attackers that can vary their packet sizes, change their data rate, and tunnel their packets through another protocol. Figure 7(b) presents attackers that can introduce constant or random delays to the packet stream and load the CPU with intensive applications to overshadow normal behavior. Figure 7(c) shows an attacker that can modify or change its operating system. GTID (the passive fingerprinting method) detects these attacks and classifies all of these devices that generated attack traffic from previously seen devices as unknown. Additionally, spectrum analyzers have been used to fingerprint the unique electromagnetic (EM) characteristics of a Wi-Fi card. The disposable USB Wi-Fi workaround described above would mitigate this attack. There have also been physical-layer approaches to fingerprinting wireless devices. Radio frequency (RF) emitter fingerprinting uses the distinct EM characteristics that arise from differences in circuit topology and manufacturing tolerances. This approach has a history of use in cellular systems and has more recently been applied to Wi-Fi and Bluetooth emitters. The EM properties fingerprint the unique transmitter of a signal, and these differ from emitter to emitter. This technique requires expensive signal analyzer hardware to be within RF range of the target. == Tor Entry Guard Fingerprinting == Addressing MAC address concerns is only one part of a broader location tracking problem. Users must also consider how Tor entry guards are used across different locations to avoid guard fingerprinting. To mitigate this risk, follow one of the [[Tor_Entry_Guards#Mitigate_the_Threat_of_Guard_Fingerprinting|recommended configurations]]: # [[Tor_Entry_Guards#Clone_Whonix-Gateway_(sys-whonix)_with_New_Entry_Guards|Clone {{project_name_gateway_short}} ({{project_name_gateway_vm}}) with New Entry Guards]]. # [[Tor_Entry_Guards#Regenerate_the_Tor_State_After_Saving_the_Tor_State_Folder|Regenerate the Tor State File after Saving the Current Tor State]]. # Configure Tor to use [[Tor_Entry_Guards#Alternating_Bridges|Alternating Bridges]]. # If relocating permanently, create [[Tor_Entry_Guards#Fresh_Tor_Entry_Guards_by_Regenerating_the_Tor_State_File|Fresh Tor Entry Guards by Regenerating the Tor State File]]. To fully mitigate this threat, entry guard changes must be applied to every Tor instance on both the host (e.g., apt-transport-tor) and guest systems. = MAC Spoofing on Different Networks = == Home Connections == {{mbox | type = notice | image = [[File:Ambox_notice.png|40px|alt=Info]] | text = '''Tip:''' MAC address changes for home connections are not required. }} {{mbox | image = [[File:Ambox_warning_pn.svg.png|40px]] | text = '''Warning:''' This recommendation comes with an important caveat. If a browser exploit is successfully used to reveal activities outside a VM, the physical MAC address might be discovered by the attacker. If a user is already under suspicion, this could eventually provide proof of identity. In this scenario, if the MAC address was changed beforehand, then root access would be required to discover the real physical address (this has not yet been tested). }} === Connectivity Risk === If the user's home network relies on a cable modem internet connection, the ISP either provides the cable modem device as part of the service or requires pre-registration of the MAC address of a self-provided cable modem for service activation. If a user manages to hack or change the MAC address of the modem, the service will immediately cease functioning because the IP address assignment is bound to that specific MAC address. Consequently, when connecting from behind a cable modem/NAT router, MAC address spoofing of the computer's Ethernet adapter may be ineffective. If a user is traced, the trackable endpoint will be the MAC address of the cable modem device. == Public Computers == {{mbox | type = notice | image = [[File:Ambox_notice.png|40px|alt=Info]] | text = This refers to the use of computers in public places such as libraries and Internet cafés. }} The MAC address should not be changed in this scenario, as it may attract unwanted administrator attention to the service/user or simply prevent access to the Internet. == Using Personal Computers in a Public Network == {{anchor|Public Connections such as WiFi Hotspots}} {{mbox | type = notice | image = [[File:Ambox_notice.png|40px|alt=Info]] | text = This applies to using a personal laptop, desktop, or any other internet-facing device in a public network. }} Is it a captive portal? Login required? Always new login with throw away accounts or bound to identity? For example, some WiFi hotspots require sign-up using passport number and/or, e-mail address, phone number, other identifiers. In that situation: * Using a different MAC address every time might be suspicious and/or break connectivity. * Using a dedicated spoofed MAC address might reduce tracking. Wired connection or WiFi? Administrator knows user or not? If administrator knows the user using a truly random MAC might be suspicious. A macciato MAC might reduce tracking. In this scenario, the MAC address changing might be useful. And a [[Tor_Entry_Guards#Mitigate_the_Threat_of_Guard_Fingerprinting|new set of Tor entry guards]] should be considered. This process involves removing the ''/var/lib/tor/state'' file. Additionally, efforts should be made to obscure Tor usage from the network administrator. Depending on the user's setup, this may involve using an obfsproxy bridge or tunneling traffic through [[Tunnels/Connecting_to_SSH_before_Tor|SSH]] or a [[Tunnels/Connecting_to_a_VPN_before_Tor|VPN]] before connecting to the Tor network. Depending on the threat model, changing the MAC address and using Tor may prevent revisiting the public network. If reuse is needed, the user must choose between keeping the same MAC address and Tor entry guards or generating new ones. If the network administrator is suspected of logging MAC addresses, changing the MAC may arouse suspicion. Conversely, if the network is sufficiently public and individual observation is unlikely, it may be safe to use a new MAC address each time -- one that features a popular vendor ID and a random second part. For further discussion on this complex topic, see [[Dev/MAC]]. = Changing MAC Addresses = == Kicksecure == TODO: Please help test and improve these instructions. {{Box|text= '''1.''' Edit the network interfaces file. * Users: Edit ''/etc/network/interfaces'' '''2.''' Install macchanger. In a terminal, run: {{CodeSelect|code= su }} {{CodeSelect|code= apt update && apt install macchanger }} '''3.''' Change the MAC address. {{mbox | type = notice | image = [[File:Ambox_notice.png|40px|alt=Info]] | text = The following steps will manually change the MAC address for the device. An example is provided for a wireless device (wlan0). Replace wlan0 with the appropriate device name, such as an Ethernet device (eth0). }} {{CodeSelect|code= su }} {{CodeSelect|code= ifconfig wlan0 down }} {{CodeSelect|code= macchanger -a wlan0 }} {{CodeSelect|code= ifconfig wlan0 up }} If the instructions in Step 1+ did not work, the following steps might work without macchanger. Replace wlan0 with the appropriate device. {{CodeSelect|code= su }} {{CodeSelect|code= ifconfig wlan0 down }} {{CodeSelect|code= ifconfig wlan0 hw ether 00:AA:BB:CC:DD:EE }} {{CodeSelect|code= ifconfig wlan0 up }} Alternatively, use iproute2 commands to change the MAC address. {{CodeSelect|code= ip link set down wlan0 }} {{CodeSelect|code= ip link set wlan0 address 00:AA:BB:CC:DD:EE }} {{CodeSelect|code= ip link set up wlan0 }} '''4.''' Complete the MAC address change. Below iface eth0 inet dhcp, add: {{CodeSelect|code= hwaddress ether 00:00.... }} '''5.''' ''Optional:'' Automatically randomize the MAC address on boot. If desired, add: {{CodeSelect|code= pre-up macchanger -e eth0 }} '''6.''' Modify network interface settings. To prevent new network interfaces from being brought up automatically, comment out the following line: {{CodeSelect|code= auto eth0 }} Then, manually bring up the interface with: {{CodeSelect|code= sudo ifup eth0 }} }} == Qubes Hosts == {{mbox | type = notice | image = [[File:Ambox_notice.png|40px|alt=Info]] | text = Qubes OS does not currently "anonymize" or spoof the MAC address automatically in all cases. }} Qubes users can manually change MAC addresses in the NetVM by following either the Network Manager or macchanger guides. [https://github.com/QubesOS/qubes-issues/issues/938 MAC Address Randomization capability for Wi-Fi] has been implemented. [https://github.com/QubesOS/qubes-core-agent-linux/pull/297 Network: Enable MAC randomization for Wi-Fi connections by default] was implemented. {{quotation |quote=This is currently applied by Debian and Fedora templates only. |context=https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-1221605861 }} {{quotation |quote=Ethernet MAC randomization by default was denied. |context=https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-1300587911 }} {{quotation |quote=Consequently, users wanting Ethernet MAC randomization will need to modify their templates manually, including in all newly downloaded templates after OEL deprecation. |context=https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-1300587911 }} Refer to the following Qubes documentation and related support items for further information and advice: * [https://github.com/Qubes-Community/Contents/blob/master/docs/privacy/anonymizing-your-mac-address.md Qubes Documentation: Anonymizing Your MAC Address] * [https://groups.google.com/g/qubes-users/c/gUPK-YqkC3E/m/WsarnjrddrsJ Qubes-Users Forum: Instructions for Installing Macchanger Needed] * [https://github.com/QubesOS/qubes-issues/issues/2361 Explore Local Network Privacy Solutions Beyond MAC Address Randomization] = MAC Address Leak Testing = [[Undocumented]]. = Sources = See footnotes. * https://tails.boum.org/contribute/design/MAC_address/ * https://gitlab.tails.boum.org/tails/tails/-/issues/5421 * https://gitlab.tails.boum.org/tails/blueprints/-/wikis/macchanger/ * Worth reading! Thanks to Tails! * [[Dev/MAC]] = References = {{reflist|close=1}} = License = {{License_Amnesia|{{FULLPAGENAME}}}} {{Footer}} [[Category:Documentation]]