MAC address randomization script

Hardware
21

Partly.

Maybe my misunderstanding is based on knowledge gap. I am trying to explain my current understanding:
I can trigger this scrip manually and then get a new MAC address (ideally before connecting to WIFI to avoid connection loss). But in the scenario of @ruff I am roaming around town and WIFIs scann my MAC adress which could result in a trace. So I would have to trigger the script each and every time before a new WIFI Spot scans my MAC address. So leaving home, changing MAC, roaming around town, coming back with same MAC address still leaves a trace.
Hope that was comprehensible.

22

Use the kill switch, @aircan?

Based on the above Wikipedia article and citation, the Linux kernel already has the capability to use a random MAC address when scanning - and MAC randomization is only a consideration when you intend to associate with an SSID, hopefully a rarer situation when roaming around town.

Looks like the setting for the scan is wifi.scan-rand-mac-address and for me this is set to no which would not be what you would want on a portable device.

The setting for the association is cloned-mac-address (with various prefixes) either the default for all WiFi, or for a specific connection, with values being

permanent - use the baked in MAC address (might make sense for a trusted WiFi at home or at work, particularly if you want to make it easy to set up a static MAC address to IP address mapping)

stable - use a different random MAC address for each SSID but ensure that a given SSID gets the same MAC address each time (presumably the MAC address is derived using a hash involving the SSID and other data that is independent of the SSID - and you control what data is used via yet another config item - still usable at home with static MAC address to IP address mappings but might be painful if you have lots of SSIDs, as I do)

random - use a different random MAC address every time (appropriate as the default and for all untrusted WiFi networks e.g. public ones - particularly where you don’t care what IP address you get)

(Another consideration across these settings is whether you are filtering by MAC address in the WAP. However I think most security experts recommend against even thinking about doing that.)

So as entertaining as this topic has been, I think maybe Linux already has it covered - no need for scripts - and it is just a question of configuration - and we can hope that Purism will ship L5s with good default settings !!

2 Likes
23

That is an alternative, of course. But again, then I do not understand @ruff when stating this script protects you from tracking. I am not talking about general possibilities to avoid this, but trying to understand the use case of this script. And honestly I still did not get it.

24

It does not protect you from tracking, it helps you to to protect yourself from one way of tracking :slight_smile:

1 Like
25

And exactly this “way” or use case I am trying to understand. What is this “way” and how does this script help me? If I understand correct, it does not help when e.g. public WIFI Spots scan the MAC addresses around, because I would have to randomize each and every time upfront, which is basically impossible. So what is the concrete scenario?

26

APs do not scan (well they can but client does not respond) it’s client which is scanning. And unless you have hidden SSIDs in your config you’ll be using passive scan (listen for beacons) instead of active (asking for beacons). So if you’re proper passive-scan client you are more or less invisible. If you are active scanner you are visible and then yes, you’d need to change your mac periodically regardless of the association.

27

P.S. The problem with WIFI and Android/iOS is that you don’t control which scan you use and what happens with scan results (visible beacons, their RSSI) which makes it possible for google or apple to determine your location even without GPS just by consuming this scan results. On linux you know that scan results live only on wpa_supplicant (well, and NM to be fair) but is not leaving your phone. So once you are sure you use passive-only you can be more or less confident you are not leaking your location.

28

Why is it impossible?

Suppose that Linux had no functionality for MAC address randomization, so I run this script at boot time and I run this script each time the WiFi disassociates from a WAP and I run this script periodically (frequently) while I am not associated with a WAP. This serves to break any obvious connection between my presence at one location at one time and my presence at the same or another location at another time.

Note that a nefarious government could deploy a network of passive WiFi receivers that are not capable of acting as WAPs i.e. purely sniffers - so as to record the MAC address in any active scans and so as to record the MAC address in any traffic relating to associating with a legitimate WAP / traffic once associated with a legitimate WAP.

29

You are right. I forgot to add “manually”.
What you described above:

  • run on boot time
  • run, when disassociate from WAP
  • run periodically

This is not part of the script yet? Or is t?

30

No, you would have to set the device up to run the script at those times/events.

1 Like
31

Correct. It is not part of the script. Nor should it be. It is much better to write a script to do X and let the user hook the script in to run at the appropriate times and events, since different users will have different ideas about what they want.

However no script should be necessary - as Linux appears to have all the required functionality already built-in.

1 Like
32

I’m pleased to see such robust discussion on this topic, which deserves deep analysis. Having read all the replies, I have a few more items for consideration:

  • @nicole.faerber Please tell us how or whether the Librem 5 implements MAC randomization, and whether it does passive or active SSID scanning.

  • Randomization means nothing without a notion of when it occurs. I don’t think we ever want to run it on a schedule. Scheduled events amount to periodic behavior and therefore risk periodic failure or amount to signatures in their own right. Better to randomize before, or ASAP after, enabling wifi or connecting to a new SSID or reconnecting to the existing one. (It could be argued that it would be more mundane to reconnect to the same SSID with the same MAC every time until wifi is power cycled.)

  • @aircan First of all, tracking can be done by all kinds of things like your interpacket timing, even when you’re running an encrypted connection via VPN. (Tor is easy to fingerprint, but very hard to tie to an individual user. Therefore, make friends with Orbot and enable onion routing for all 500 dumpster apps that ship with your phone by default, at risk of some occasional loss of functionality.) Also, visit your app settings and sort by permission. Revoke all permissions, to the extent possible, without rendering your phone unusable. I would also recommend sitting down whenever you have location enabled, so you can’t move. Get in the habit of disabling location every time you stand up while in public. Some of this advice is still useful even if you’re a step ahead of me because you already own a Librem phone.

  • @aircan Anyway, MAC address randomization alone won’t stop state-level actors from identifying you, but it will prevent the local mafia from knowing that the guy who got into a fight at the bar is staying at the hotel down the street. (In Mexico, for instance, the drug cartels have largely built their own wifi and cellular networks, so they are surely leveraging MAC and IMEI for tracking.) One problem with any randomization script is that you need to bring up your wifi before you can change its MAC address. I suppose this is because, when the connection is disabled, the device automatically powers down to save battery. Unfortunately, this means that there’s at least a theoretical window between the time that it powers back up with its default MAC, and when its MAC gets rewritten. If you have existing wifi connections in your history, then most distros would attempt to reconnect automatically as soon as wifi is back up. So to be paranoid, you need to delete (“Forget Connection”) all those while wifi is still disabled. (Most Android phones are so stupid that they prevent you from deleting the SSID history while wifi is disabled! Only fix for that is a long walk away from any router.)

  • @fralb5 Great work! I don’t think we need to worry too much that your script’s list of manufacturer MAC ranges gets stale anytime soon.

  • @kieran Where do I set “wifi.scan-rand-mac-address” and “cloned-mac-address=random”?

  • @ruff Thanks for explaining passive vs active SSID scanning. Of course, who would know what closed-source device employs which method, hence my question to Nicole above.

  • Commercially deployed routers in restaurants, hotels, etc. are effectively Facebook for MACs. Their internal databases of MAC connection histories are, in general, accessible via firmware vulnerabilities or poorly protected admin panels. (And too bad Purism doesn’t make a router!)

2 Likes
33

/etc/NetworkManager/NetworkManager.conf

Set wifi.cloned-mac-address in the same file.

You may also want to set connection.stable-id in that file if you are using stable for MAC address randomization.

Technically you are supposed to create a new .conf file in /etc/NetworkManager/conf.d (with whatever name you choose) and put your changes in there instead of modifying the above file.

For changing a specific connection, I suggest using the nmcli command

e.g. nmcli conn to list the names of all your connections and hence be able to pick the right one and then
nmcli conn show <conn-name> | grep cloned-mac-address to see the current setting and
nmcli conn modify <conn-name> 802-11-wireless.cloned-mac-address <value>

Note the inconsistent prefix (wifi v. 802-11-wireless).

If you never care about getting a constant IP address or a predictable MAC address then you probably should set random as the value for wifi.cloned-mac-address in the overall config file and not set anything connection-specific (and you can ignore all the stuff about stable).

Of course I’m not in a position to test any of this on a Librem 5, or know what the defaults are on a Librem 5!

1 Like
34

It isn’t necessarily a function of the closed-source device. The closed-source device may carry out this function under the direction of the host.

It is of course true that a malicious closed-source device can undermine absolutely all of this. Right? At a certain point you can only do what you can do.

Hard to know whether this is or isn’t a problem in reality. For sure it could be a problem in theory.

35

This comment caught my attention as I had not thought about the issue of device fingerprints from this perspective. In the world of quant trading, doing anything in a regular fashion is problematic because it allows competitor to track you and, possibly, front run you. As a result, every interaction with the market is decomposed and randomized. If I understand correctly, the lack of randomization of TOR is what allows it to be fingerprinted.

Surveillance capitalism gone bad!

36

Works great! FYI it only seems to alter the MAC across a reboot (maybe not suspend and definitely not a kill switch toggle), so make sure to power down between logging off at the coffee shop and logging on at the hotel.

Let’s help the noobs:

sudo your_text_editor /etc/NetworkManager/NetworkManager.conf

Ensure that you have:

[device]
wifi.scan-rand-mac-address=yes
wifi.cloned-mac-address=random

Tor is easily identified because it forces everyone to use the same screen resolution, only hits the internet via certain IPs (“exit nodes”), and some other things. This is by design, so that everyone looks the same. Unfortunately, its DNS resolution is done at the exit node, so if I can convince you that I’m the authoritative nameserver for example.com, then I can induce you to establish an HTTPS connection with me instead of them. If you enter your example.com password and it fails, then you should immediately suspect such an attack (although it’s probably just due to your typo). Nevertheless, I don’t know that you are you unless I can map the username you submitted to your actual identity. More broadly, however, if I connect you to the real example.com, then I can monitor your browsing behavior from the exit node (to some extent, even if your traffic is encrypted), and potentially realize that you’re the same guy who visited the site from the coffee shop yesterday. Whether or not I can make that connection really just depends how much I know about you. Of course, the alternative is a regular browser, which is just so much worse unless you care about nothing but performance.

By the way, I read a rumor a while back that Satoshi Nakamoto has most likely been identified by stylometry, that is, the grammatical and vocabulary statistics of his writing. Sometimes, for all the heavy anonymity tools in the world, all it takes is an exploitation of human habits!

37

That’s not ideal.

In that respect, stable will work better because the stable MAC address can be derived by hashing the SSID and other info (as specified with the stable-id setting), so unless the ‘coffee shop’ and the ‘hotel’ use the same SSID, they will automatically be unable to be connected by the surveillance. However if you repeatedly visit the same ‘coffee shop’ then you will have the same MAC address every time you use that WAP, which is not ideal. The documentation gives you other options for the hashing, so maybe you can force it to behave better.

If setting stable-id to ${RANDOM} with cloned-mac-address set to stable gives better results than setting cloned-mac-address to random then that seems a bit unsatisfactory to me but hey this is Linux. It’s open source. If I don’t like it, I can change it. :wink:

Obviously I would love to be able to test this out myself before advising you but …

Really, I would like to see it be the case that if you use the kill switch and you aren’t associated with a WAP then it should re-randomize the MAC address. In the mean time, you can probably manually run the MAC address randomization script when using the kill switch, or maybe you can hook the script into an interface up or down event.

Nah. If you control the DNS then you can induce me to establish a TCP connection to the wrong host but the (secure, SSL/TLS) connection will fail long before I get to enter a password because the wrong host is unable to use a valid certificate for example.com

OK, if you ignore the browser warnings about certificate failure then what you say applies.

BUT then the password won’t fail because any attacker worth his salt (security pun?) will do a correct Man In The Middle (MITM) attack and relay the session back to the real host - so the password will fail if and only if you did actually enter the wrong password.

If you entered the correct password then thereafter the attacker has your password and can monitor a lot of stuff just by logging in as you.

(Some sites tell you the last IP address used to login, which you could in some cases use to detect someone logging in as you, but that is highly likely not to be useful if you are using TOR, since the IP address will be all over the world.)

38

When I wrote that “random” only changes the MAC across a reboot, I only tested with a constant SSID, so in theory it might differ when connecting to a different one. However, I’ve tested your other recommendations and found that none of this works!

The problem is that, while a random MAC is indeed reported by ifconfig, it reverts to the native default immediately after connecting. Only running the randomization script at that point will restore the randomness as long as the device is up (but won’t alter it when changing from one SSID peer to another). But by then, it’s too late because the hotel router has already cached your native MAC.

It seems like the only way to really solve this is to prevent automatic reconnection. That way, we can have the wifi up and running without broadcasting the MAC, giving the user time to manually (yuck!) run the ranomization script and manually (double yuck!) reconnect to their favorite SSID.

crontab @reboot seems futile, BTW.

A little OSINT research uncovered this Wired article from 2015. I guess the crude attack I mentioned above was possible back then because browsers weren’t terribly finicky about certificate authentication. Since then, there’s been lots of discussion in security forums about how much it might cost to set up a puppet certificate authority. If I recall, a Chinese group did so quite successfully for a while, until Chrome decided to disregard their certificates.

39

OK. I will probably have to wait until I have my phone to make progress on that.

Yes, if you can combine a malicious TOR exit node with a malicious CA issuing ‘fake’ certificates (and the web site does not use any of the more advanced mechanisms to counter fake certificates and the domain is not using DNSSec) then this is a workable attack.

Thanks for the reminder to delete those CAs.

40

Just to be clear, I tested all this on my Librem laptop. It’s something in my particular OS network stack that’s derandomizing the MAC.

Oh, I just found it!

big-brother.mac-traceable=yes