Cisco’s 'intuitive security' tool can’t handle MAC address randomization out-of-the-box Cisco promotes its Identity Services Engine (ISE) as “intuitive network security for the digital age.” But Switchzilla has just explained that it’s not very good at handling the growing practice of MAC address randomization by mobile devices. A refresher: MAC addresses are unique identifiers assigned to network interface …
Not just a Cisco issue, this is going to cause havoc for any vendor of Network Access Control that's keying the device off the MAC address
At least Apple backed away from their original proposal to periodically change the MAC address within an SSID. That would make managing wireless utterly horrific.
True I suspect this will cause a problem with forescout and pulse NAC. Also maybe other network discovery tools which base the results on MAC addresses, as upto now its been about the only static fingerprint for networked devices. Oh and thinking of it, it will potentially cause problems with DHCP if for some reason you are assigning static IP addresses to iOS and Android devices, not commonly done but maybe for VIPs in large organisations. Assigning static IP addresses and allowing URL filtering rules and firewall rules based on an IP is easier than going down the whole rule of user authentication on devices or full blown NAC functionality.
Using MAC's for Network Access Control on non-wired networks is not really useful IMHO.
On WiFi, MAC addresses travel through the air unencrypted. All you need to do is probe all wireless traffic, see which MAC addresses regularly chat with the SSID (to know which MACs are accepted) and clone one of the MAC addresses that is least used.
If you want to have a rough (but not 100% reliable) idea who is/was on the network I suppose they could help but I'd never use them for intrusion detection for instance.
My phone is currently on Android 8 (Oreo) but so far as I can tell, the MAC address is static. Anyone know if this is just an optional feature which vendors might not use? (In my case, the dreaded Huawei. A P10 lite if you must know - by far the best Android I've ever owned, but I digress...).
A while back at a premier Inn I needed their premium WiFi but the portal webpage was completely unusable in the phone browser.
So I spoofed my phone's MAC address on my Ubuntu laptop and registered using a real browser.
Sure enough, once I disconnected the laptop and connected the phone, I was on the premium service. I dare say someone nefarious could even steal someone else's premium WiFi by cloning their MAC...
I'm pretty certain that any randomisation would cause havoc, so I hope it's true that they really do stick to the same MAC Forever on any given SSID.
What happens if it randomly selects the same MAC as another device? Is an ARP test sufficient to be sure that it's free before using it?
Are you sure Apple has backed away from periodically changing MACs within an SSID? (every 24 hours, according to this June WWDC video https://developer.apple.com/videos/play/wwdc2020/10676/)
I'd like to find documentation confirming that.
Empirically, I haven't seen MACs change yet, but it's only been a few days. My fear is that they might still do it, but maybe weekly or monthly, or maybe only when a device reconnects to the same SSID.
The whole purpose of MAC addresses (and indeed IP addresses) is reliable identification of devices - primarily for directing traffic of course, but with the beneficial spin-offs of providing a measure of confidence in the remote end of the connection being what you think it is and of a certain level of access control. This inevitably implies traceability, which is s good thing, unless abused. So it's the abuse, not the mechanism we should be trying to eliminate.
Randomising MAC addresses is a clumsy kludge solution to the abuse that has detrimental side effects. The fact that this kit is not good at handling the kludge is not ideal, but the abuse is the primary problem.
The whole purpose of MAC addresses (and indeed IP addresses) is reliable identification of devices
but as we all know, the side effect is that the likes of Google, Amazon, Facebook, NSA etc etc
can track you everywhere you go with that simple old MAC Address. With IPV6, it will be even easier as NAT'ing will be a thing of the past (or so I've been told)
The randomisation is an attempt to give those data slurpers one less tracking vector to use as the suck the life, sorry data out of your IT kit but yes it presents a who different set of problems when trying to secure a network.
"Certainly a WiFi point knows, but not sites you connect to."
Hmmm. Final answer?
If someone's mobile device has a MAC address, and someone's mobile device has an app (or even a library/framework) from one of The Usual Suspects which has internet connectivity, are you really saying there's no way for the app/library to find out what the MAC address is and report it to its masters in The Cloud? In line with the company's policy of continuous product and service improvement, telemetry, etc?
You've installed an app and given it access to your local device and permission to detect it. These apps will require you to login to use them?
You are now concerned that they might be able to track you unless you have MAC randomisation? They don't need to, you are running their app!
So you're worried enough about tracking to want randomised MAC addresses but you are not worried enough that you leave your WiFi AP in fully open mode including allowing access to other clients on the network?
Also - you are saying that Google, Facebook and Amazon are regularly camped outside these insecure locations as that is the best way for them to track users?
Google Street view cars were capturing SSIDs and WiFi BSSIDs (basically MAC addresses assigned to the WiFi name) which allowed them to learn about WiFi networks rather than WiFi clients.
Client WiFi MAC capture is about monitoring movement of devices for behaviour analysis (think shopping malls as an example) or targeted advertising (you spent 15 minutes in and around shop X, ad network Y will now bombard you with ads for their products and "special offers").
This post has been deleted by its author
"By having sites that run a script that puts your MAC address into a cookie, perhaps?"
The MAC address is only really as useful as your RFC1918 IP address if you sit behind NAT (i.e. locally relevant) but it's harder to get from a web browser.
To get it from a web browser, you either need a browser helper object to make it available (think inventory or support tools) or by having access to the local subnet ARP table to convert your IP back into a MAC address (i.e. your wifi router for managing MAC based access lists).
Google/Apple/Microsoft likely have access to the MAC address details via device registration information, companies providing wifi would have the MAC address related to your customer account via signup forms or account information but a generic website would have no way of directly acquiring your MAC address in order to associate it with their customer records/cookies. Getting that information from a wifi provider or hardware vendor maybe an option, but the MAC address is likely incidental as they would be purchasing location/tracking information rather than the MAC address.
There are several ways to use static MAC addresses to track.
One is that it allows the WiFi provider (hotel, store, shopping mall, local authority) to track your movement and usage and correlate it with what you did yesterday, and last week. If last week you accessed an Extinction Rebellion web page (or a protest app since made illegal in Hong Kong), they can make sure that this week you are not allowed into the mall (or arrested).
A second reason is that it provides a long term identifier available to applications, which they can use for gathering and correlating personally identifiable data. Apple have made it possible for users to change their marketing ID (and Android claim to have recently done the same, although I trust Google less than Apple), but the MAC address provides apps with an alternative long term identifier, particularly if they can get assistance from a device on the same LAN (for example an advertising hoarding, or an access point provided by the mall owner) which sees the MAC address used in traffic.
Sorry, but fixed MAC address are a personal tracking device.
Yes, I'm sure everyone knows how a wifi provider could potentially track MAC addresses and why they have been randomised.
You are replying to a question which asked "Okay, can you explain how Google, Facebook and Amazon can track via a MAC address?"
That doesn't answer that question. Presuming it is most likely the OP what discussing websites tracking your MAC via the Intertubes then the point of the question was to determine whether they thought Layer Two tracking was available via the Internet? It obviously isn't so MAC randomising doesn't help or affect web server tracking, which almost always use IP addresses, cookies and logins.
Sorry, I thought I was dealing with people who understood how Internet marketing works. Google, Amazon and Facebook partner with (in particular, give freebies and other incentives) to the people I mentioned such as mall owners, stores, and app developers.
In the case of apps those advertising networks are built in. In the case of physical stores they use Google, Amazon and Facebook tools in their marketing tools. And Google, Facebook and Amazon also provide things like physical marketing panels which try to steal bluetooth and MAC addresses.
Once you have the co-operation of an app on the user's device, or software or hardware being used by a partner, you have full remote access to LAN-based tracking. That is why you need to protect against local tracking if you want to prevent remote tracking. I thought that part was obvious.
"Okay, can you explain how Google, Facebook and Amazon can track via a MAC address?"
Several tiers of detection are possible, including these:
Very invasive: Google: WiFi data collection from StreetView or other hardware, access to phones via Play Services. Amazon: Access to their own tablets via their proprietary components which frequently contact Amazon servers.
Somewhat invasive: All: Collection of IPV6 addresses to collect those which have a MAC embedded in them (default for SLAAC deployments). Facebook and Amazon: Collection of MACs from device from installed applications.
Not proven to happen but possible: Google and Amazon: IoT equipment placed on users' home networks which could collect all MACs in WiFi handshakes. All: Potential to have apps on phones with sufficient permissions to cause them to listen for such handshakes also.
That was what I came up with in the first thirty seconds. Let's see if others can find more. I bet they can.
Whether to assign a temporary address is broadly up to the network; a device can request one and be assigned the traditional type with the exact MAC address included. Some networking equipment may not respect user preferences in this way and there's little that can be done. It's easy to identify if this has happened and get the data only under that condition. There isn't any easy way to prevent this from occurring without manually checking the address and leaving the network if it hasn't assigned a temporary address. There are also devices that don't have that privacy setting enabled or don't even allow that privacy setting to be enabled, and those can also be tracked. I am uncertain how much choice phone manufacturers have here, but still it could be an important factor.
Even if we eliminate this particular option by deprecating the original suggestion to embed, we still have the other methods for companies to collect addresses as listed in my original post. Not to mention that the easiest way to get that data en masse is to have ISPs collect it from anyone using their equipment without another device in front of it and sell the database, which could be legal depending on which country you're in and could happen anyway even if it isn't legal.
If a device's MAC address is available to software (such as a Facebook app on your device), then yes, a fixed MAC address can be combined with other data sets to start tracking you through indirect means.
Add to this Google's proposed Orion WiFi system (on the network side), which will inevitably include MAC addresses (Calling-Station-Id in RADIUS) in the data they'll capture and the same will be the case. Public WiFi networks (like the ubiquitous BT OpenZone, Fon, Gogo Wireless, TheCloud, etc etc etc) rely on MAC addresses as well, and they can, if they choose to monetise that information, combine your device with other data to again create a profile of where you've been at what time.
This information is pervasive and constant, and it is used surprisingly often. So yes, randomised MAC addresses will break that link, at least to a degree that makes aggregation of data more difficult.
"If a device's MAC address is available to software (such as a Facebook app on your device), then yes, a fixed MAC address can be combined with other data sets to start tracking you through indirect means."
If the MAC address is available in an app, then the devices location details are likely to also be available.
For Orion, if the user is authenticating via RADIUS, you would only need the MAC address if it was the authentication ID - if you have an alternative method for authentication (i.e. a Google ID) then the MAC address is of little value unless you use the same ID on multiple devices AND its important to track each device individually.
Where the MAC address (wifi and BLE) are being used is in either sniffing passing devices and you don't have an app/account/etc to track you in a more "legitimate" manor...
The MAC address is only seen in the layer 2 broadcast domain the host connects to.
As soon as the host requests a resource that is not available on the broadcast domain it resides on it sues IP addressing, and with each hop across the various networks the traffic goes, the source and destination MAC addresses will change (to be the ingress and egress interfaces MAC addresses of that layer 2 broadcast domain).
TL:DR
Which basically means:
Unless 'the likes of Google, Amazon, Facebook, NSA etc etc' own (of have access to) the AP you are connecting to, they're unlikely to see you MAC address.
The big issue here is connecting to your office environment and the supporting of that.
If you believe that someone with the resources of 'the likes of Google, Amazon, Facebook, NSA etc etc' would be using the MAC address to track you is ludicrous, I can see the argument about companies tracking you, but for a lot of public WiFi you need to register anyway!!!
In short, from a security perspective, yes it is better then nothing, but they should have an option to be able to set a MAC address for a SSID so that when you go to your trusted networks, such as work and home or VPN, it will cause less issues (and allow of the use of Dynamic ARP Inspection and other LAN security measures) and randomly set it for any network that you select to be 'public'.
The latter where being the default maybe?
"... but for a lot of public WiFi you need to register anyway ..."
Exactly. Hence the reason it is desirable to use something else to track you - if you always had to register you could be tracked by the registrations. If you can identify that the same phone has been used in 50 different locations, then even if its owner only registered in one of those locations it is identifyable everywhere - and in retrospect. A bit like leaving fingerprints or DNA all over the place - completely anonymous until they are matched to you just single time in your life.
Unless 'the likes of Google, Amazon, Facebook, NSA etc etc' own (of have access to) the AP you are connecting to, they're unlikely to see you MAC address
Not sure what the situation is in other countries, but in the US the default for the average consumer is to use a wifi router supplied to them by their ISP. So they can certainly link your MAC addresses to various web activity - and they could share/shell that information with Google or Facebook since the "privacy policies" US companies have are pretty much "we can share anything with our 'partners'" where 'partners' means "anyone who pays us money or gives us something of value in trade".
With IPV6, it will be even easier as NAT'ing will be a thing of the past (or so I've been told)
It's not as easy as you think. Most operating systems use IPv6 Privacy Extensions by default which means that the public IPv6 address of the same machine changes frequently, usually every 24 hours.
After the daily switchover any new TCP/IP connection will be made with the new IPv6 address while the old slowly falls into disuse. The result is that at the very least using IPv6 is just as 'anonymous' as IPv4 (you can pinpoint an IP to a physical address but not a specific machine), in many cases it's more anonymous as it would require a database of every ISP in the world and the length of the prefix they dish out to figure out if those two different IPs are from the same connection or just the same ISP.
Indeed. It's the OS vendors that need to address this. Fine, allocate different MAC addresses to different SSIDs, or allocate randomised SSIDs to certain stored network connection profiles, but they have to allow a fixed MAC for especially trusted networks.
But they do allow. At least in Android, you can still switch to the real device MAC address in the wireless network profile. Furthermore, if the device is company-issued, there are policies you can pre-apply to it (and I know this works in iOS as well) in order to not randomize the MAC address when connecting to company WiFi. For the public WiFis, I actually see it as a good thing, no reason to not randomize it. Same thing BTW goes with Windows 10, as it does the exact same thing now by default with every wireless connection.
OK, here's how I think having a fixed MAC can be used by a state actor to track huge numbers of people. State agencies (NSA, GCHQ, FBI etc.) place thousands of small cheap listen-only WiFi monitors near well-travelled WiFi hotspots. They monitor and log every MAC address they see (WiFi encryption does not prevent the harvesting of MAC addresses). This allows the authorities to run correllation algorithms to see whether the same MAC address(es) appear at the time & place as other events, which MAC addresses have been in proximity many times over a time period (implying the people are travelling together) etc. It also allows them to track the past location history of any suspects more accurately than cell tower logs can provide.
Many devices will automatically connect to (or at least handshake with) open WiFi routers even if the owner of the phone has not explicitly commanded it to connect.
What you describe is already defeated by the MAC randomization that has been in use for years. Not sure how Android did it, but on iOS it would use a random MAC address when searching for wifi access points (i.e. to generate a list of SSIDs) When you actually connected to a wireless network, then it would use your real MAC - so stuff like static DHCP would work.
What has changed in iOS 14 is that they will be randomizing MAC addresses when first connecting to a wifi network. So if I wanted to set up static DHCP on two networks I'd have a different MAC for the same phone listed on each. For consumer use this isn't a problem, but it sounds like in certain corporate environments it is a problem (I'll leave it to those more familiar with how this Cisco device does things to explain that)
The problem with pre-IOS-14 behavior is that it's easy to convince a device to get handshakes if a phone's ever connected to a network by listening for pings and pretending to be every network. This approach has been verified to work on lots of devices, so if you place a device which will respond to any SSID request, you'll get authentication requests from most passing devices. These don't always work; if it's a secure network, some of the authentication might fail because you don't know the correct key. If it's an open network that you're responding to, those devices just handed you their MACs. If it wasn't, you add that SSID to a list you won't respond to and try again; the phone will send you another ping in a second and you can hope that that one was open.
The software to do this is easy to obtain and configure, mostly used for MITM attacks. Those are tricky because you need to hold your victim near your attack point. If all you want to do is track people, you don't need to worry about the time element (or even the connectivity element) so it's even easier.
iOS also does this in the way Android does. You have the choice of switching randomisation off for a specific network (so the randomisation is tied to the SSID information). It's not like the OS vendors haven't thought it through... ;-)
the abuse is the primary problem
Agreed, but it's also the hardest to address. As a user, you have no way to know if your devices are being tracked in this way; and if so, for what purpose. So from a user perspective, the only way to mitigate the threat is to make the MAC an unreliable identifier.
If you need to set a security profile for a device or reserved DHCP then there are a few ways to do it.
You could use different SSIDs for different security profiles but you'll rapidly run out of these when you have multiple security profiles, you need to use client certificates to identify devices (not so easy if you aren't in direct control of the device) or you need to perform a user login for each network connection (but then how do you ensure that connection is valid as they move from AP to AP without excessive logins?).
So you need some kind of device identifier, and although MACs were never that secure they provided a "good enough" approach for that in certain circumstances as long as you understood the security risks.
If, to avoid tracking, you can't identify a device is the same device that you saw a minute ago, an hour ago, a week ago, etc then it does create a bit more of an issue for secure traversal of systems unless you have control of the device and can use client certificates. It's a tough nut to crack, but I'm not an expert in this area so I might be missing something.
If you need to set a security profile for a device or reserved DHCP then there are a few ways to do it.
DHCP uses the Client ID (option 61) to allocate IP addresses, profiles etc. The MAC address is the default value for Option 61, but not the only one.
Perhaps the solution would be to use the randomized MAC address for the unprotected over-the-air link, but the real MAC address in the DHCP request? That would prevent sniffer-type devices from tracking you, although the AP could still do so if compromised.
You don't need the 'real' MAC address in the DHCP request, you just need it to be the SAME address each time it does a DHCP request for that network.
So if you wanted to set up static DHCP or whitelist what MAC addresses can access your network you'd have to first attempt to join that network so it will assign a new random MAC. Then you can use that new MAC to set up DHCP or the whitelist, try to join again, and it will work. It is a little bit more work, but IMHO the security benefit is worth it (especially since consumers aren't going to be exposed to this side of things anyway)
Assuming one MAC per SSID "forever" on a device, then that's less of an issue?
Problems arise in corporate BOYD setups - so full enrollment needs to be completed on main network, not a separate setup network as the MAC address changes between the two. MAC address needed to associate user to device so can track problems/faults/access. Some of these systems will need wholesale changes to be able to do this?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
