EUI-64 Considered Harmful

02/24/2019
by   Erik C. Rye, et al.
0

This position paper considers the privacy and security implications of EUI-64-based IPv6 addresses. By encoding MAC addresses, EUI-64 addresses violate layers by exposing hardware identifiers in IPv6 addresses. The hypothetical threat of EUI-64 addresses is well-known, and the adoption of privacy extensions in operating systems (OSes) suggests this vulnerability has been mitigated. Instead, our work seeks to quantify the empirical existence of EUI-64 IPv6 addresses in today's Internet. By analyzing: i) traceroutes; ii) DNS records; and iii) mobile phone behaviors, we find surprisingly significant use of EUI-64. We characterize the origins and behaviors of these EUI-64 IPv6 addresses, and advocate for changes in provider IPv6 addressing policies.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

09/25/2020

Target Privacy Threat Modeling for COVID-19 Exposure Notification Systems

The adoption of digital contact tracing (DCT) technology during the COVI...
06/10/2020

Privacy by Design in Value-Exchange Systems

This article addresses some of the most contentious issues related to pr...
11/01/2019

Assessing the Privacy Benefits of Domain Name Encryption

As Internet users have become more savvy about the potential for their I...
02/13/2018

Economic Impact of Discoverability of Localities and Addresses in India

Most of the earth's population has a poorly defined addressing system, t...
01/31/2021

Follow the Scent: Defeating IPv6 Prefix Rotation Privacy

IPv6's large address space provides ample freedom for assigning addresse...
10/07/2021

Attacks on Onion Discovery and Remedies via Self-Authenticating Traditional Addresses

Onion addresses encode their own public key. They are thus self-authenti...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

The privacy and security implications of Layer-2 hardware network identifiers, e.g. 48-bit IEEE Media Access Control (MAC) addresses [2], have been well-studied. In particular, because these addresses are static, difficult for the average user to change, and persist across network attachment points, they can be exploited to both fingerprint devices (e.g. identify the manufacturer and model [8], thereby permitting targeted attacks) as well as compromise user privacy by providing a persistent tracking identifier.

This work focuses on MAC addresses in IPv6. Auto-configured IPv6 addresses were traditionally formed by encoding the interface’s 48-bit MAC address as an EUI-64 [4] into the lower order bits of the 128-bit IPv6 address as part of Stateless Address Autoconfiguration (SLAAC) [14]. Today, however, modern OSes randomize the host bits of their IPv6 addresses according to the privacy extensions standard [9]. These addresses are randomized and highly ephemeral [11].

Most recently, two works at the ACM IMC 2018 discover non-trivial numbers of EUI-64 addresses within large-scale IPv6 topology discovery campaigns [5, 7]. This unexpected result is due to the fact that while end-hosts have largely abandoned the use of EUI-64 addresses, Customer Premise Equipment (CPE) infrastructure (e.g. home routers and gateways) still make extensive use of such addresses. Critically, the MAC addresses of these devices is revealed remotely when they respond to traceroute probing.

While revealing these addresses is seemingly innocuous at first blush, they introduce two potential vulnerabilities: i) the ability to identify the manufacturer and model of a device, thereby permitting targeted attacks; and ii) the ability to track users despite efforts to prevent such tracking. More specifically, not only are the host bits of a client’s IPv6 address ephemeral, their allocated network prefix is similarly ephemeral [10]. Indeed, many providers induce their client’s IPv4 and IPv6 addresses to change regularly for privacy reasons [3]. However, while the client’s end-host IPv6 address is changing, the address of her home gateway is not – thus an attacker able to perform traceroutes to the client can determine that it is the same client, and track the client’s assigned addresses over time.

In this preliminary survey, we study the use, prevalence, and potential vulnerabilities of EUI-64 addresses among four separate sources of data:

  • CAIDA Archipelago traceroute data from December 2008 to July 2018

  • Traceroutes to RIPE nodes conducted in 2018

  • ANY and AAAA RR lookups from Rapid7’s fDNS data set between October 2016 and December 2018

  • Inspection of 27 mobile devices in a lab environment

2 Infrastructure EUI-64 Prevalence

Plonka and Berger report that fewer than 1% of clients accessing a large CDN in 2015 via IPv6 use addresses containing EUI-64 MACs [11]. While the population of clients with EUI-64 addresses is small, recent work found non-trivial numbers within IPv6 infrastructure [5, 7]. We first analyze the macro composition of two large public datasets.

The CAIDA traceroute data [6] contains 3,650,488 unique MAC addresses appearing in 5,794,444 distinct EUI-64 IPv6 addresses between December 2008 and July 2018. Between the months of October 2016 and December 2018, Rapid7’s fDNS dataset [12] contains 50,060,121 AAAA records with an EUI-64 address, with 7,705,481 unique EUI-64 IPv6 addresses containing 2,177,516 distinct MAC addresses.

The distribution of EUI-64 IPv6 addresses is non-uniform; some autonomous systems (AS) are home to far greater numbers of active EUI-64 addresses than others. Over 2.8 million EUI-64 addresses appear in the CAIDA data from one provider’s prefixes, whereas only dozens appear in other networks. This appears to be indicative of the manufacturer of the prominent CPE devices issued by the respective service provider. The most common providers and manufacturers discovered in the CAIDA data are highlighted below:

Providers 111ASNs anonymized Manufacturers
AS A (50%) Actiontec (57%)
AS B (11%) AVM (FRITZ!) (14%)
AS C (9%) Arcadyan (8%)
AS D (6%) Huawei (6%)
AS E (5%) ZTE (3%)

3 Tracking users over CPE Address Changes

To highlight tracking and privacy implications of CPE-based EUI-64 usage we conduct a longitudinal IPv6 traceroutes to fixed nodes. We fetch the set of RIPE Atlas nodes [13] with working IPv6 daily, recording their address and Atlas node identifier. The node identifier allows us to continually probe the same end node over time, even if its address changes. We traceroute to each node and find the penultimate address when the traceroute reaches the destination. In this fashion, we can determine when service providers change the address of the link between the provider and the customer’s CPE. We are particularly interested in cases where the service provider changes the assigned CPE prefix, but the CPE’s address is EUI-64.

These prefix changes, assumedly meant to provide privacy protections, are trivially enumerated due to the CPE device responding to network probing using an EUI-64 derived address. Furthermore, and of particular concern, this behavior allows for the potential to track client devices, even those using ephemeral addresses, as an implicit association to the CPE’s EUI-64 address can be inferred via the derived network path. Depicted below, traces to the same unique host over the course of a month, illustrate a representative behavior in which the CPE device consistently flips between two /48 but distinct /64 IPv6 network prefixes on a daily basis.

Date CPE IPv6 /64 Prefix222IPv6 prefixes anonymized
20181024 xxxx:xxxx:xxx1:1676
20181025 xxxx:xxxx:xxx2:46e1
20181102 xxxx:xxxx:xxx1:a6d7
20181103 xxxx:xxxx:xxx2:c9b9

Other providers assign new /64s within the same /48 every day, while we even observe CPEs being assigned prefixes in different /16s owned by their provider.

Conversely, we detect single MAC addresses appearing in EUI-64 IPs spanning multiple ASNs and countries in traceroutes occurring within a short time interval. In this case, it is unlikely that there is a single device traveling to disparate locations. Rather, we posit that these devices auto configure to a default hardware address, or represent devices that have inappropriately reused a MAC address.

4 Mobile Phone Behaviors

Support for privacy extensions has been available since iOS 4.3 and Android 4.0 [1], suggesting that privacy concerns have long been addressed on mobile devices. While all 28 mobile device models, produced by 12 manufacturers, that we tested implemented privacy extensions for the primary IPv6 address, only the OnePlus 6 running Android 8.1 had only privacy extension addresses. All 27 other models, covering Android 4.3 to 9.0, had secondary, global EUI-64 addresses assigned to their interfaces. Interestingly, this EUI-64 address was not always visible from the system settings application; instead, we connected to each phone using the Android Debugger and used the IPv6 addresses discovered via the debugger as ground truth.

After obtaining each device’s EUI-64 IPv6 address (except the OnePlus 6), we successfully elicited an ICMPv6 Echo Response from each of the devices in response to an Echo Request addressed to its EUI-64 IPv6 address while connected to an 802.11 wireless network. Early experiments involving Google Pixel phones connected to LTE networks suggest the ability to ping6 EUI-64 IP addresses on mobile devices on cellular networks, as well. This implies a potential to track individual devices, and hence users, as they move across networks. For example, an adversary who knows the MAC address of her target might deduce a range of network prefixes the target might be in; exhaustive probing of these prefixes with the lower bits set to the EUI-64 generated by the target’s MAC address quickly confirms or rules out that device’s presence.

5 Future Work

A more robust quantification of service provider-induced network prefix changes utilizing our EUI-64 CPE address tracking mechanism remains in progress. Lastly, we hope to investigate the plausibility of the EUI-64 targeted attack described above, in which a priori knowledge of mobile device’s MAC address is assumed.

6 Disclaimer

Views and conclusions are those of the authors and should not be interpreted as representing the official policies or position of the U.S. Government. The author’s affiliation with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE’s concurrence with, or support for, the positions, opinions or viewpoints expressed by the author.

References

  • [1] Privacy extensions for ipv6 slaac.
  • [2] IEEE Standard for Information Technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific Requirements Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications. IEEE Std 802.3-2005 (Revision of IEEE Std 802.3-2002 including all approved amendments) (Dec 2005), 1–2695.
  • [3] Zwangstrennung (forced ip address change), 2018. https://de.wikipedia.org/wiki/Zwangstrennung.
  • [4] 3rd, D. E., and Abley, J. IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters. RFC 7042 (Best Current Practice), Oct. 2013.
  • [5] Beverly, R., Durairajan, R., Plonka, D., and Rohrer, J. P. In the IP of the Beholder: Strategies for Active IPv6 Topology Discovery. In Proceedings of the ACM SIGCOMM Internet Measurement Conference(IMC) (Nov. 2018).
  • [6] CAIDA. The CAIDA UCSD IPv4 Routed /24 Topology Dataset, 2018. http://www.caida.org/data/active/ipv4_routed_24_topology_dataset.xml.
  • [7] Gasser, O., Scheitle, Q., Foremski, P., Lone, Q., Korczynski, M., Strowes, S. D., Hendriks, L., and Carle, G. Clusters in the expanse: Understanding and unbiasing ipv6 hitlists. In Proceedings of the 2018 Internet Measurement Conference (New York, NY, USA, Nov. 2018), ACM.
  • [8] Martin, J., Rye, E. C., and Beverly, R. Decomposition of MAC Address Structure for Granular Device Inference. In Proceedings of the 32nd Annual Computer Security Applications Conference (ACSAC) (Dec. 2016).
  • [9] Narten, T., Draves, R., and Krishnan, S. Privacy Extensions for Stateless Address Autoconfiguration in IPv6. RFC 4941 (Draft Standard), Sept. 2007.
  • [10] Padmanabhan, R., Dhamdhere, A., Aben, E., claffy, k., and Spring, N. Reasons dynamic addresses change. In Proceedings of the 2016 Internet Measurement Conference (2016), pp. 183–198.
  • [11] Plonka, D., and Berger, A. Temporal and spatial classification of active ipv6 addresses. In Proceedings of the 2015 Internet Measurement Conference (2015), pp. 509–522.
  • [12] Rapid7. Forward dns datasets, 2018. https://scans.io/study/sonar.fdns_v2.
  • [13] RIPE NCC. RIPE Atlas, 2018. https://atlas.ripe.net/.
  • [14] Thomson, S., Narten, T., and Jinmei, T. IPv6 Stateless Address Autoconfiguration. RFC 4862 (Draft Standard), Sept. 2007. Updated by RFC 7527.