An Ars story from earlier this month reported that iPhones expose the unique identifiers of recently accessed wireless routers,
which generated no shortage of reader outrage. What possible
justification does Apple have for building this leakage capability into
its entire line of wireless products when smartphones, laptops, and
tablets from competitors don't? And how is it that Google, Wigle.net,
and others get away with publishing the MAC addresses of millions of
wireless access devices and their precise geographic location?
Some readers wanted more technical detail about the exposure, which
applies to three access points the devices have most recently connected
to. Some went as far as to challenge the validity of security researcher
Mark Wuergler's findings. "Until I see the code running or at least a
youtube I don't believe this guy has the goods," one Ars commenter wrote.
According to penetration tester Robert Graham, the findings are legit.
In the service of our readers, and to demonstrate to skeptics that
the privacy leak is real, Ars approached Graham and asked him to review
the article for accuracy and independently confirm or debunk Wuergler's
findings.
"I can confirm all the technical details of this 'hack,'" Graham, who
is CEO of Errata Security, told Ars via e-mail. "Apple products do
indeed send out three packets that will reveal your home router MAC
address. I confirmed this with my latest iPad 3."
He provided the image at the top of this post as proof. It shows a
screen from Wireshark, a popular packet-sniffing program, as his iPad
connected to a public hotspot at a Starbucks in Atlanta. Milliseconds
after it connected to an SSID named "attwifi" (as shown in the section
labeled #1), the iPad broadcasted the MAC address of his Linksys home
router (shown in the section labeled #2). In section #3, the iPad sent
the MAC address of this router a second time, and curiously, the
identifier was routed to this access point even though it's not
available on the local network. As is clear in section #4, the iPad also
exposed the local IP address the iPad used when accessing Graham's home
router. All of this information is relatively simple to view by anyone
within radio range.
The image is consistent with one provided by Wuergler below. Just as
Wuergler first claimed, it shows an iPhone disclosing the last three
access points it has connected to.
Graham used Wireshark to monitor the same Starbucks hotspot when he
connected with his Windows 7 laptop and Android-based Kindle Fire.
Neither device exposed any previously connected MAC addresses. He also
reviewed hundreds of other non-Apple devices as they connected to the
network, and none of them exposed previously accessed addresses, either.
As the data makes clear, the MAC addresses were exposed in ARP (address resolution protocol)
packets immediately after Graham's iPad associated with the access
point but prior to it receiving an IP address from the router's DHCP
server. Both Graham and Wuergler speculate that Apple engineers
intentionally built this behavior into their products as a way of
speeding up the process of reconnecting to access points, particularly
those in corporate environments. Rather than waiting for a DHCP server
to issue an IP address, the exposure of the MAC addresses allows the
devices to use the same address it was assigned last time.
"This whole thing is related to DHCP and autoconfiguration (for speed
and less traffic on the wire)," Wuergler told Ars. "The Apple devices
want to determine if they are on a network that they have previously
connected to and they send unicast ARPs out on the network in order to
do this."
Indeed, strikingly similar behavior was described in RFC 4436,
a 2006 technical memo co-written by developers from Apple, Microsoft,
and Sun Microsystems. It discusses a method for detecting network
attachment in IPv4-based systems.
"In this case, the host may determine whether it has re-attached to
the logical link where this address is valid for use, by sending a
unicast ARP Request packet to a router previously known for that link
(or, in the case of a link with more than one router, by sending one or
more unicast ARP Request packets to one or more of those routers)," the
document states at one point. "The ARP Request MUST use the host MAC
address as the source, and the test node MAC address as the
destination," it says elsewhere.
Of course, only Apple engineers can say for sure if the MAC
disclosure is intentional, and representatives with the company have
declined to discuss the issue with Ars. What's more, if RFC 4436 is the
reason for the behavior, it's unclear why there's no evidence of Windows
and Android devices doing the same thing. If detecting previously
connected networks is such a good idea, wouldn't Microsoft and Google
want to design their devices to do it, too?
In contrast to the findings of Graham and Wuergler were those of Ars writer Peter Bright, who observed different behavior when his iPod touch connected to a wireless network.
While the Apple device did expose a MAC address, the unique identifier
belonged to the Ethernet interface of his router rather than the MAC
address of the router's WiFi interface, which is the identifier
cataloged by Google, Skyhook, and similar databases.
Bright speculated that many corporate networks likely behave the same
way. And for Apple devices that connect to access points with such
configurations, exposure of the MAC address may pose less of a threat.
Still, while it's unclear what percentage of wireless routers assign a
different MAC address to wired and wireless interfaces, Graham and
Wuergler's tests show that at least some wireless routers by default
make no such distinction.
Wuergler also debunked a few other misconceptions that some people
had about the wireless behavior of Apple devices. Specifically, he said
claims that iPhones don't broadcast the SSID they are looking for
from Errata Security's Graham are incorrect. Some Ars readers had
invoked the 2010 blog post from Graham to cast doubt on Wuergler's
findings
"The truth is Apple products do probe for known SSIDs (and no, there is no limit as to how many)," Wuergler wrote in a post published on Friday to the Daily Dave mailing list. He included the following screenshot to document his claim.
Connecting the dots
What all of this means is that there's good reason to believe that
iPhones and other Apple products—at least when compared to devices
running Windows or Android—are unique in leaking MAC addresses that can
uniquely identify the locations of networks you've connected to
recently. When combined with other data often exposed by virtually all
wireless devices—specifically the names of wireless networks you've
connected to in the past—an attacker in close proximity of you can
harvest this information and use it in targeted attacks.
Over the past year or so, Google and Skyhook have taken steps to make
it harder for snoops to abuse the GPS information stored in their
databases. Google Location Services, for instance, now requires the submission of two MAC addresses
in close proximity of each other before it will divulge where they are
located. In many cases, this requirement can be satisfied simply by
providing one of the other MAC addresses returned by the Apple device.
If it's within a few blocks of the first one, Google will readily
provide the data. It's also feasible for attackers to use war dialing
techniques to map the MAC addresses of wireless devices in a given
neighborhood or city.
Since Apple engineers are remaining mum, we can only guess why
iDevices behave the way they do. What isn't in dispute is that, unlike
hundreds of competing devices that Wuergler and Graham have examined,
the Apple products leak connection details many users would prefer to
keep private.
A video demonstrating the iPhone's vulnerability to fake access point attacks is here.
Updated to better describe video.
Image courtesy of Robert Graham, Errata Security