How to look up the GPS location of your MAC address or car on the Internet

bruce replied:

Referring to a typical consumer-grade wireless router, I believe he meant that cloning a MAC address usually was to change the WAN MAC address, whereas he was discussing the WLAN MAC address, which (at the time he wrote that) he thought couldn't be changed without hardware mods. I think he has since learned that WLAN MAC addresses are, in general, set via software from saved configuration.

There are many consumer-class routers I've never dealt with, so I don't know if he's right in thinking that the manufacturer's firmware for some routers does not support changing the WLAN MAC address.

Elsewhere I said I don't see this as big issue. Even when the WLAN MAC address can be changed, in practice, for most routers out there, my impression is that once the router's been configured, the WLAN MAC address one sees at a particular location generally won't change unless the router gets replaced. -WBE

Reply to
Winston
Loading thread data ...

OK. You found a corner case, where not all cellphones do WiFi. Since I also have iOS equipoment, all my iOS equipment has WiFi also.

While I am sure they exist, I personally have never seen a cellphone that doesn't do WiFi; but I also have a limit on cellphones of 16GB minimum,

1GHz minimum, 1GB RAM minimum, etc., where the cost is never below $200 so, the cellphones "I" have bought *all* have WiFi.

I did goof with the wife's $200 Moto G, which only has 2.4GHz WiFi, since I simply *assumed* that all of the WiFi cellphones had *both* 2.4GHz and 5GHz WiFi ... so I agree with you on the wide range of what Android phones do.

I think here is where we get mired in conflicting details, which are better discussed in person, because the mere fact that the BSSID is encapsulated in the clear in the WiFi packet is *absolutely meaningless* for the purpose of this discussion *if* all those poorly configured Android devices don't

*upload* that BSSID to the Google Public Database.

The *only* BSSID that matters for this discussion is the BSSID which is

*uploaded* to the Google Public Database by all those poorly configured Android devices.

I'm completely and intimately familiar with the fact that the BSSID only has to be unique on the subnet, e.g., you can use DE:AD:BE:EF:CA:FE on your own network and it won't matter, as long as only a single device on your network has that BSSID.

Up until Jeff's later responses, I had thought that the BSSID that matters (which is the one *uploaded* to the Google database by poorly configured Android devices!) was hard to change, and it is, for a typical factory-software router.

But Jeff explained that certain firmware will enable that all-important BSSID (which is the one that is *uploaded* to the Google database by poorly configured Android devices) *can* be changed on a router.

In addition, Jeff noted that, for Android devices which are *rooted*, that all-important BSSID (which is the one *uploaded* to the Google publid database by poorly configured Android devices) *can* be changed.

Unfortunately, a quick search on Google shows a history of Apple *breaking* any jailbroken device's ability to change that specific BSSID with each new OS version - so we can effectively say it can't easily be done on iOS (which is another reason why iOS has less privacy than Android in certain situtations).

Are you saying that you have 32 different access points in "a single radio"?

It's possible - but remember, the *only BSSID that matters* for this conversation is the one that is *uploaded* to the Google Public Database by poorly configured Android devices.

All other BSSIDs are meaningless for the purpose of this discussion.

Given that, are you saying that you have *32* different SSIDs which are being uploaded, as we speak, to the Google Public Database by all poorly configured Android devices in your vicinity?

I see why you are frustrated in this conversation.

Jeff already noted that there are *plenty* of situations where a BSSID is found, in the clear, in the context of WiFi communications.

Since *this* discussion is *only* about exploring privacy flaws in the Google Public Database, the only BSSID that matters for this discussion is the BSSID that is *uploaded* to the Google Public Database by all poorly configured Android devices in your vicinity.

Reply to
Horace Algier

this one doesn't:

Reply to
nospam

This is an interesting paper...

formatting link

Why MAC Address Randomization is not Enough: An Analysis of Wi-Fi Network Discovery Mechanisms

"We present two attacks that reveal the real MAC address of a device, even if MAC address randomization is used.

In the first one, we create fake hot spots to induce clients to connect using their real MAC address. The second technique relies on the new

802.11u standard, commonly referred to as Hotspot 2.0, where we show that Linux and Windows send Access Network Query Protocol (ANQP) requests using their real MAC address. ...

We show that *all* implementations of MAC address randomization fail to provide adequate privacy."

Reply to
Horace Algier

This is correct.

Everyone knows how to clone the "WAN MAC Address", which is as simply as pressing a button and typing "DE:AD:BE:EF:CA:FE".

It's the WLAN MAC address which doesn't have a "clone" button in the manufacturers' software/firmware.

I think what Jeff Liebermann was saying was that, for *routers*, you can change the WLAN MAC Address if you use the right custom firmware.

But we were talking about phones, so, Jeff also added that for Android phones, you can change the WLAN MAC address if you're root using the typical Linux commands we use all the time on Linux.

The situation would be likewise for jailbroken iOS phones, with the exception that, in practice, Apple seems to prevent that with each iOS upgrade, so, effecitvely, you can't change the WLAN MAC address easily on an iOS phone.

I got all my information from Jeff - who told me, a couple of years ago, that the "clone" in the consumer-class routers is for the wrong MAC address.

The only MAC address that matters, for this discussion, is the MAC address that the poorly configured Android devices in the vicinity are *uploading* to the Google PUblic database.

While what you're saying is true, that people don't change their WLAN Mac addresses even if they could, I have used only Netgear and Linksys and D-Link routers, and *none* of them have allowed me to change the one MAC address that matters for this discussion, which is the MAC address that is

*uploaded* to the Google Public Database by poorly configured Android devices in the vicinity.

The main question is:

  1. Under what circumstances is an iOS or Android *phone's* MAC address
*uploaded* to the Google PUblic Database by poorly configured Android devices in the vicinity?

  1. How can someone *exploit* that fact to locate the phone?

Reply to
Horace Algier

Since *this* discussion is *only* about exploring privacy flaws in the Google Public Database, the only BSSID that matters for this discussion is the BSSID that is *uploaded* to the Google Public Database by all poorly configured Android devices in your vicinity.

It's even worse than that.

  1. While we all know that *hiding* the SSID is futile, it's actually
*useful* to hide your SSID in that the poorly configured Android devices apparently do *not* upload "hidden" SSIDs to the Google Public Database.

  1. However, most of us don't "hide" our SSID from being broadcast (since there is almost zero security value in hiding the SSID broadcast).

  2. Hence, our SSIDs are being *uploaded* to the Google Public Database by poorly configured Android devices whether or not we have "_nomac" at the end of the SSID.

  1. What's worse, the *unique* BSSID of the radio is also uploaded at the same time (along with the signal strength of the SSID and the current GPS location of the poorly configured Android device).

Therefore, the SSID is the *least* of our privacy worries (unless we're dumb enough to name our SSID after our first and last name or something similarly identifiable).

The privacy concern is the association of the *hard-to-change* unique MAC address with its GPS location.

These two critical pieces of metadata are *uploaded* to the Google Public Database by poorly configured Android devices, whether or not you put "_nomac" on the SSID.

Bruce .... you're trying to argue that the world contains a lot of parameters, and nobody (not even me!) is disagreeing with you.

You may as well tell me that every radio has a MAC address or that every radio has an antenna or that every computer on the net has an IP address or that the BSSID is in every packet, etc.

Nobody is disputing what you're saying - but what you're saying has

*nothing* whatsoever to do with the topic at hand!

The topic at hand is *only* about the BSSIDs that are *uploaded* to the Google Public Database by poorly configured Android devices.

The two related questions are: a. Under what circumstances is your phone's BSSID uploaded to the Google Public Database? b. How would an attacker *exploit* that public database to track the

*location* of the phone?

If you want a *different* topic, then just say so - but *that* is the topic here that "I" am trying to find out more about.

The two related questions are: a. Under what circumstances is your phone's BSSID uploaded to the Google Public Database? b. How would an attacker *exploit* that public database to track the

*location* of the phone?

If you want a *different* topic, then just say so - but *that* is the topic here that "I" am trying to find out more about.

The two related questions are: a. Under what circumstances is your phone's BSSID uploaded to the Google Public Database? b. How would an attacker *exploit* that public database to track the

*location* of the phone?

If you want a *different* topic, then just say so - but *that* is the topic here that "I" am trying to find out more about.

Reply to
Horace Algier

It's interesting that all the operating systems implement the MAC address reandomization differently ... as outlined in that paper ...

2.1.1 iOS Apple added MAC address randomization to its devices starting from iOS 8 [42]. In iOS 8, randomized addresses are only used while unassociated and in sleep mode [18]. iOS 9 was extended to also use randomization in what Apples calls location and auto-join scans [42]. Based on our own experiments, this means that randomization is now also used when the device is active, i.e., when the screen is turned on. 2.1.2 Android Android 6.0 uses randomization for background scans if the driver and hardware support it [2]. Unfortunately, we did not have a device to test and verify this in practice. Although Android versions before 6.0 do not support randomization, several applications supporting this feature have been released [9, 3]. Common features of those applications are a periodical update of the MAC address to a random value, but also the manual modi cation of this address by the user. Note that those applications require root privilege to operate, which reduce their impact for the average user. 2.1.4 Linux Linux added support forMAC address randomization during network scans in kernel version 3.18. The address should be randomized for each scan iteration [24]. Drivers must be updated to support this feature. The mvm module of the iwlwifi driver supports randomization since kernel 3.18. The brcmfmac driver added support for this in kernel 4.5. The privacy-oriented Linux distribution Tails [1] does not support MAC address randomization during network scans. Instead, it generates a (new) random MAC address at boot. This random address keeps the rst 3 bytes of the original address, the Organization Unique Identi er (OUI), and only randomizes the last three bytes. While not as optimal as periodical address changes, it does prevent tracking over extended periods of time. 2.1.3 Windows Microsoft supports randomization since Windows 10 [45]. Enabling randomization is possible if the hardware and driver support it. Interestingly, not only does Windows use random addresses for probe requests, it also uses a random address when connecting to a network. To assure the client always uses the same address when connecting to a particular network, a per-network address is calculated as follows [27, 28]: addr = SHA-256(SSID; macaddr; connId; secret)[:6] (1) Here SSID is the name of the network, macaddr the original MAC address, and connId a parameter that changes if the user removes (and re-adds) the network to its preferred network list. The secret parameter is a 256-bits cryptographic random number generated during system initialization, unique per interface, and kept the same across reboots [28]. Bits in the most signi cant byte of addr are set so it becomes a locally administered, unicast address. This hash construction is similar to the generation of IPv6 interface identi ers as proposed in RFC 7217 [21]. It assures that systems relying on xed MAC addresses continue to work as expected, e.g., when authentication is performed based on the MAC address. Users can also manually instruct the OS to daily update the per-network address randomly.
Reply to
Horace Algier

The cut and paste from PDF to newsagent went awry, so I'll use VIM instead for the cut and paste from PDF ...

formatting link

2.1.4 Linux Linux added support forMAC address randomization during network scans in kernel version 3.18. The address should be randomized for each scan iteration [24]. Drivers must be updated to support this feature. The mvm module of the iwlwifi driver supports randomization since kernel 3.18. The brcmfmac driver added support for this in kernel 4.5. The privacy-oriented Linux distribution Tails [1] does not support MAC address randomization during network scans. Instead, it generates a (new) random MAC address at boot. This random address keeps the first 3 bytes of the original address, the Organization Unique Identier (OUI), and only randomizes the last three bytes. While not as optimal as periodical address changes, it does prevent tracking over extended periods of time 2.1.2 Android Android 6.0 uses randomization for background scans if the driver and hardware support it [2]. Unfortunately, we did not have a device to test and verify this in practice. Although Android versions before 6.0 do not support randomization, several applications supporting this feature have been released [9, 3]. Common features of those applications are a periodical update of the MAC address to a random value, but also the manual modification of this address by the user. Note that those applications require root privilege to operate, which reduce their impact for the average user. 2.1.1 iOS Apple added MAC address randomization to its devices starting from iOS 8 [42]. In iOS 8, randomized addresses are only used while unassociated and in sleep mode [18]. iOS 9 was extended to also use randomization in what Apples calls location and auto-join scans [42]. Based on our own experiments, this means that randomization is now also used when the device is active, i.e., when the screen is turned on. 2.1.3 Windows Microsoft supports randomization since Windows 10 [45]. Enabling randomization is possible if the hardware and driver support it. Interestingly, not only does Windows use random addresses for probe requests, it also uses a random address when connecting to a network. To assure the client always uses the same address when connecting to a particular network, a per-network address is calculated as follows [27, 28]: addr = SHA-256(SSID; macaddr; connId; secret)[:6] (1) Here SSID is the name of the network, macaddr the original MAC address, and connId a parameter that changes if the user removes (and re-adds) the network to its preferred network list. The secret parameter is a 256-bits cryptographic random number generated during system initialization, unique per interface, and kept the same across reboots [28]. Bits in the most significant byte of addr are set so it becomes a locally administered, unicast address. This hash construction is similar to the generation of IPv6 interface identifiers as proposed in RFC 7217 [21]. It assures that systems relying on fixed MAC addresses continue to work as expected, e.g., when authentication is performed based on the MAC address. Users can also manually instruct the OS to daily update the per-network address randomly
Reply to
Horace Algier

wait.

Notice this bit in the article:

Ie, the sensors only track those smartphones that are searching for networks. A phone that doesn't search will not be logged, can't be. And I guess that phones using wifi, ie, clients, can't either.

I don't think that those "poorly configured smartphones" track the clients of an AP. Too much traffic to be sending possibly over the poor user dataplan.

On the other hand, google already knows the location of all android phones, the instant they register. It doesn't need to ask "poorly configured smartphones" for that data.

Reply to
Carlos E.R.

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.