So many people here will go though great lengths to protect themselves from fingerprinting and snooping. However, one thing tends to get overlooked is DHCP and other layer 3 holes. When your device requests an IP it sends over a significant amount of data. DHCP fingerprinting is very similar to browser fingerprinting but unlike the browser there does not seem to be a lot of resources to defend against it. You would need to make changes to the underlying OS components to spoof it.
What are everyone’s thoughts on this? Did we miss the obvious?
If you use systemd’s DHCP client, since version 235 you can set Anonymize=true in your network config to stop sending unique identifiers as per RFC 7844 Anonymity Profiles for DHCP Clients. (Don’t forget to also set MACAddressPolicy=random.)
I mean, yeah. Lots of shopping centers have devices specialized on fingerprinting mac adress. It was already 10 years ago a thema that you should disable wlan and bluetooth if you go out of the house.
Using randomized MAC on my phone’s, and observing the behavior on my network. It works fine, the router can’t assign a ip to the device because the physical address changes. The os fingerprinting still works, the gateway knows what kind of device it’s talking to.
Android? How do I force it to use a random Mac every time? It pins a random Mac to a given network, which greatly reduces privacy between sessions.
Developer settings for newer androids.
GOS has it on by default https://grapheneos.org/features#wifi-privacy
DHCP only acts in local networks which is in 90%:
- home network where you trust every device to not spy on you
- office network where in most cases your emloyer provided you with the hardware. And in 10%:
- Public WiFi
The only thing leaked in DHCP is your MAC. Attacker can use this info to identify brand of our network adapter. Or if they have really huge database of laptop manufacturers attacker can identify your device. If you use VPN or TOR the only thing they know from now on is that you use VPN or TOR. And if they really have everything in that database they will be able to tell who bought that computer. So now attacker can only knows who is in their netwotk.
Which is useless in scenario 1. and 2. Where you already know who is in your network and owner of that network has no database to identify you based on your MAC.
In scenario 3. If we are talking about huge public networks like WiFi provided from your town. If infiltrated by 3 letter agencies which may have such database they could theoretically track your location based on which town network you connected to.
But you can protect yourself from this:
- Do not connect to public networks
- Your OS/Network card driver allow you to use random MAC address. Just enable random MAC in your network settings. In Android: WiFi > Select specific network > Privacy > Use randomized MAC.
Also take note some general location tracking can already be done through mobile networks.
The only thing leaked in DHCP is your MAC
This is not true. It also leaks your hostname by default and often your previously associated IP. There’s also vendor-specific “DHCP option” sets that can hold extra data too, which some OSes might use to leak additional info.
Does randomizing your MAC create any usability issues? Needing to log in repeatedly, getting bumped off network due to looking like a different device, anything else hindering usability?
I mean the only interesting data sent is the mac address, android phones spoofs that by default, using a separate mac adress for every network and on a debian based distro you can use https://packages.debian.org/stable/net/macchanger if you wanna spoof it when using your computer in the networks owned by others.
Hostname, platform, OS version, software versions and other data are all sent.
Most commercial wireless networking software can fingerprint a device with a decent certainly
See the link
I used to provide commercial end-user support for a network intelligence product that used as much metadata as possible to help classify endpoints, shuffling them off to the right captive portals for the right segment based on that data.
I can tell you that the things you’re saying are transmitted in a DHCP request/offer are just not. If they were, my job would’ve been a LOT easier. The only information you can count on are a MAC address.
I can’t view that link you shared, but I’ve viewed my share of packet captures diagnosing misidentified endpoints. Not only does a DHCP request/offer not include other metadata, it can’t. There’s no place for OS metrics. Clients just ask for any address, or ask to renew one they think they can use. That only requires a MAC and an IP address.
I suppose DHCP option flags could maybe lead to some kind of data gathering, but that’s usually sent by the server,not the client.
I think, at the end of the day, fighting so that random actors can’t find out who manufactured my WiFi radio just isn’t up there on my list of “worth its” to worry about.
They are watching DHCP Discover option 55. The device tells the server what options it expects to receive, and different vendors and device ask for different options or ask for them in a different order, and they are fingerprinting that.
Cisco also describes the tactic: https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/116235-configure-ise-00.html
The fingerprints are viewable at https://github.com/karottc/fingerbank/blob/master/dhcp_fingerprints.conf - it is more specific than a mac vendor but not extremely anti-privacy, anybody watching firewall logs will know an iPhone connected pretty easily too.
