Apple iOS 4.3 adds additional IPv6 user security

A little bit of background on IPv6, NDP, Auto-config, Host Address Randomization, and EUI-64

In IPv4, there is a requirement to have an external entity handle IP address assignments. Typically this is done by a DHCP server where that server keeps track of host state, and assignment.  Although there is DHCPv6, IPv6 has introduced a new means of allowing hosts to auto-assign/negotiate their IPv6 addresses called ‘Stateless Address Autoconfiguration’, defined in RFC4862. Stateless auto-config introduces an entire new concept to the Internet Protocol, and address generation has been moved from a centralized server to each host.  Without taking into account all of the negotiations that need to happen in order to have a stateless, non-colliding, auto address assignment, the host is now the one that has to do the generation of an address.  Since the auto configuration is stateless, there is no starting point like there is in DHCPv4 – for example: there is no 192.168.1.100 that addressing can start from.

Since there is no state, and the address is generated by the host, we would need something that will reliably not collide with other hosts. A way to satisfy the address requirements is to have a unique number for each network device. MAC addresses are unique to each host, which is where EUI-64 was introduced (RFC4291).  EUI-64 is a way of generating an IPv6 host portion of an IPv6 address from a MAC address. This is a working concept, and is implemented in many devices. From a security standpoint you can use this to gain additional information about the specific host.  An attacker can go backwards from IPv6 EUI-encoded address, to get the associated MAC address. They can then go from MAC address to manufacture of the device using IEEE OUI lookup. Although this does not give you much information, it does introduce knowledge to an attacker they they previously had not known.

After EUI-64 was questioned by the security community, Host Address Randomization was introduced. Although I have not read through the entire RFC3014, the concept seems pretty straight forward. You do not want an attacker have any additional information about your host, so randomize each IPv6 address that the host auto-configures.  If the host has multiple IPv6 addresses, one would think the host portion would be re-generated for each one of those addresses. If they aren’t, an attacker would know additional information: given one IPv6 address, an attacker would know the host portion of the rest of the IPv6 addresses. I have seen that most implementations only generate the host portion once, and use that for every provisioned IPv6 address.

The actual post

This morning, with the release of the iphone dev team’s un-tethered  iOS 4.3.1 jailbreak, I decided to upgrade my iPhone 4 to the 4.3.1 firmware.

In the midst of creating an IPv6 host randomization testing script, I was happily surprised that the iOS update allows the device to perform full IPv6 host address randomization (as described in: RFC3014).

This is the first implementation I have seen that does host randomization as I would expect it to – a random host address is generated for just about every address that the device provisions. As described above, other implementations generate a single host portion of the address, and will use that host portion of its address for every IPv6 address it auto-configures for itself.  For example, Windows7 was one of the first operating systems that I heard of that supposedly implemented IPv6 host randomization, but when forcing the operating system to generate multiple IPv6 addresses, it doesn’t seem to have any randomization:



As you can see, every “Temporary IPv6 Address” has the same host portion for every address.

Many mobile devices do not have the same capabilities as Windows7 to obtain a full list of current IP addresses, including Apple iOS devices.  In fact,  I have not found any tools that provide any capability to do anything with IPv6 local on Apple’s iOS devices. Now the problem becomes how to test for host address randomization remotely.  The test that I have created to test for IPv6 host address randomisation is as follows:

1. Obtain the MAC address of the device to test
2. Start a thread to monitor for all Neighbor Advertisements.  This is sent during neighbor discovery after a host assigns itself with an IPv6 address
3. Generate an IPv6 Router Advertisement that tell every host on the link-local segment to generate a new public IP address of ’2001:[RANDOM PREFIX]::’ and assign themselves a /64
4. Send a new random IPv6 Router Advertisement 100 times
5. Look through the list of Neighbor Advertisements that were observed, and filter out only the ones seen coming from the MAC address of the device to be tested
6. See how many unique IPv6 host portions were observed during the Router Advertisement flood
7. If there is greater than one Neighbor Advertisements seen, and multiple unique IPv6 host portions, then their must be some sort of host address randomization
8. If there is greater than one Neighbor Advertisement seen, and only one unique IPv6 host portion, then host address randomization is not implemented
9. Otherwise we do not have enough data to make a conclusion

Prior to today, any time I performed this test, there was only observed to be one unique IPv6 host portion on iOS (iPhone 4) 4.2.1, but when doing a test today I noticed:

20 unique host addresses?!

I looked through the debug logs, and confirmed that this was in fact the case.  I have to give Apple props for being the first in my eyes to implement real IPv6 host address randomization.

Post a comment or leave a trackback: Trackback URL.