Hacking

SLAAC Attack – 0day Windows Network Interception Configuration Vulnerability

Tweet

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Windows machines compromised by default configuration flaw in IPv6

As anyone who has watched the reimagined Battlestar Galactica will tell you, Sixes are trouble. They are undoubtedly alluring, but all the while they are working covertly, following The Plan, right under the noses of their targets. Nobody realizes the true nature of the threat until it's too late.

The Internet also has its own Six, IPv6 (formerly IPng – IP Next Generation). Modern operating systems ship with it by default, but adoption has been slow for many reasons. Despite the passing of the IPocalypse, it lies largely dormant within today's networks, waiting for the chance to rise up and usurp its IPv4 predecessor.

This article describes a proof of concept of an interesting application of IPv6. I'm going to show you how to impose a parasitic IPv6 overlay network on top of an IPv4-only network so that an attacker can carry out man-in-the-middle (MITM) attacks on IPv4 traffic.

This new SLAAC Attack, if you will, is named for the process it is exploiting.

IPv6 Background

Aside from the increased address space, IPv6 is fundamentally different to IPv4 in several key areas. This article isn't intended to be an IPv6 primer, but I'll highlight the main features that are relevant to the attack.

Firstly, IPv6 does not use ARP – instead, there are a set of neighbor discovery protocols implemented over ICMPv6 that allow hosts to discover the physical addresses of others on the local link. Also, routers routinely advertise their presence on the local link by multicasting Router Advertisement (RA) messages.

When an IPv6-aware host receives an RA, it can derive itself a valid routable IPv6 address by means of a process called Stateless Address Auto Configuration (SLAAC). The host will use the source address of the RA as its default gateway.

In as much as it facilitates automatic host addressing, SLAAC sounds a lot like DHCP in the IPv4 world. However, SLAAC alone can't supply all of the configuration parameters that a host might need (DNS servers, for example), so DHCPv6 is still needed to fill the gaps. It turns out that you need RA, SLAAC and DHCPv6 to accomplish for IPv6 what DHCP alone can do for IPv4, but that's another story. Much more is covered in our Ethical Hacking training course.

Theory of Operation

This proof of concept targets Windows 7 hosts, but the theory ought to apply to any operating system that ships with IPv6 installed and operational by default. Let's start with a diagram of the target network:

Pretty straightforward stuff; everything's IPv4, and the border router is performing the usual NAT and firewall tasks. Let's also assume that various countermeasures are in place to thwart conventional IPv4 MITM techniques such as ARP spoofing.

What we're going to do is physically introduce a router, evil-rtr, to the target network. evil-rtr has two network interfaces – the victim facing interface is IPv6 only, and the Internet connected interface is IPv4 only. Our aim is to use evil-rtr to create a parasitic IPv6 overlay network that's totally under our control, as shown by the tinted area in the diagram below:

evil-rtr will send RAs to the local network which will cause the hosts to derive routable IPv6 addresses for themselves. It is also equipped with a DHCPv6 server to supply the address of a recursive DNS server that's under our control (evil-DNS in the diagram above). What we have not done is connect our IPv6 overlay network to the IPv6 Internet – evil-rtr only has a connection to the IPv4 Internet.

The Special Sauce

The changes made by introducing evil-rtr are pretty benign so far. Thanks to evil-rtr's RAs, all the target hosts have routable IPv6 addresses in addition to their IPv4 ones, plus the address of a DNS server. This isn't enough to do anything useful – we need another ingredient to progress the attack.

The "special sauce" is NAT-PT, an idea that's so riddled with issues and caveats that it's been consigned to the trashcan of history by the IETF. However, just because it's an obsolete mess doesn't mean it can't be useful.

NAT-PT is one of the many IPv4-to-IPv6 transition mechanisms that have been devised to ease migration from the old to the new. Its job is to allow islands of IPv6 hosts to communicate with IPv4 hosts by translating IPv6 addresses into IPv4 addresses and vice versa. There's a writeup here that shows its intended operation. It's NAT-PT that allows our IPv6-addressed victims to access the Internet through evil-rtr's IPv4 interface.

To use NAT-PT you need to define an off-link /96 prefix; it can be pretty much any routable prefix you like. Any destination addresses seen by NAT-PT which match this prefix are interpreted as IPv6 addresses with a destination IPv4 address embedded in the last 32 bits.

For example, I might tell my NAT-PT box that the prefix I'm using is 2001:6f8:608:ace::/96. The IPv6 address of the DNS server that we're going to give out via DHCPv6 is 2001:6f8:608:ace::c0a8:5802 – this address matches the specified prefix, so if NAT-PT sees traffic destined for it the last 32 bits (c0a8:5802) will be extracted and translated into the DNS server's true IPv4 address of 192.168.88.2.

The Garnish on the Special Sauce

We're nearly there. With NAT-PT in place, evil-rtr is now providing a working path from the IPv6 victims to the IPv4 Internet. If we can cause the victims to pump IPv6 traffic through evil-rtr (instead of sending IPv4 through the legitimate border router) we can have our SLAAC Attack fun. It turns out that this is quite straightforward.

Thanks to evil-rtr, our victims have both IPv4 and IPv6 addresses; they are "dual stacked". Dual stacked hosts will prefer to use native IPv6 where available, so we're half way there already. The final garnish that will take us the rest of the way is DNS.

The dual stacked victims have an IPv4 DNS server (courtesy of the legitimate DHCP server) and an IPv6 DNS server (courtesy of evil-rtr's DHCPv6 server). When one of the victims tries to look up www.google.com, it will send a DNS query to its IPv6 DNS server for both A (IPv4) and AAAA (IPv6) records. If the IPv6 DNS server can return results in a timely enough fashion, the victim will pick the IPv6 address over the IPv4 one if the former is present. It is this behaviour we will rely on to lure traffic through evil-rtr. Our IPv6 DNS server has to be quick, though – if it takes too long to reply, the victim will fall back to using the legitimate IPv4 DNS server instead, and no traffic will pass through evil-rtr.

But how can we make sure that any given DNS query always returns an IPv6 address?

NAT-PT implementations usually include a set of Application Layer Gateways (ALGs) which inspect traffic that has IP addresses carried within the application layer protocol. DNS is an example of a protocol that requires an ALG, as is FTP. Here's what the IPv6 DNS transaction looks like with NAT-PT and the DNS ALG working their magic:

Things to note:

• The address of the victim's DNS server matches the NAT-PT prefix on evil-rtr, denoting that the last 32 bits contain the DNS server's IPv4 address.
• NAT-PT translates the source and destination IPv6/IPv4 addresses in both directions.
• The DNS ALG translates the victim's AAAA query for an IPv6 address into an A query for an IPv4 address and vice versa on the way back.
• The DNS ALG also translates the IPv4 address in the reply to an IPv6 address that matches the NAT-PT prefix.

As far as the victim is concerned, www.google.com is reachable via IPv6 at 2001:6f8:608:ace::d155:8f63. It has absolutely no idea that IPv4 is involved in any way. The victim will therefore contact Google like this:

evil-rtr is therefore now a man-in-the-middle between the victim and Google.

To summarize the story so far:

• We have not compromised or altered the operation of the victim's IPv4 network, as we would have needed to do in order to MITM IPv4 traffic. We've not even needed to get an IPv4 address from their DHCP server.
• We have not compromised an existing IPv6 network, because there wasn't one before we arrived.
• We have not compromised any given victim host (yet!). Each machine is behaving as designed and is choosing IPv6 over IPv4 of its own volition.
• We have managed to totally alter the flow of traffic on the victim's network by awakening the hosts' latent desire to use IPv6 over IPv4.

The attack is also reasonably stealthy, since:

• We're introducing a new path to the Internet. Any defences or monitoring employed at the network's IPv4 boundary are therefore ineffective and will raise no indicators of compromise.
• There's a chance that the victim's security systems (e.g., host firewalls, HIPS, SIEM boxes, etc.) won't be able to handle IPv6 traffic. IPv6 support on such systems is rarely as mature as its IPv4 equivalent.
• Since the victims "aren't using IPv6" they won't be expecting an attack that makes use of it.
• If the above is true, there's a chance their Incident Response teams won't have the necessary training and experience with IPv6 to deal with an incident that uses it.

Building evil-rtr

It doesn't take much to implement evil-rtr. Only three packages are needed, namely radvd, dhcp6s, and naptd. Before we get these up and running, we need to set up our interfaces. In this example, eth0 is the Internet-facing IPv4 interface, and I'm going to assume that it can use a DHCP server somewhere to get an address. eth1 is the IPv6 interface, which we'll configure like this:

root@evil-rtr:~# ifconfig eth1 inet6 add 2001:6f8:608:fab::1/64

root@evil-rtr:~# ifup eth1

root@evil-rtr:~# ifconfig eth1

eth1      Link encap:Ethernet  HWaddr 00:25:4b:fd:91:73

inet6 addr: 2001:6f8:608:fab::1/64 Scope:Global

UP BROADCAST MULTICAST  MTU:1500  Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

We also need to make sure that IPv6 forwarding is turned on:

root@evil-rtr:~# sysctl -w net.ipv6.conf.all.forwarding=1

net.ipv6.conf.all.forwarding = 1

Now we can install our IPv6 toys.

radvd

This package is responsible for sending RAs to our victim hosts, and can be obtained here. The configuration file is quite straightforward:

interface eth1 {

AdvSendAdvert on;

AdvOtherConfigFlag on;

MinRtrAdvInterval 3;

MaxRtrAdvInterval 10;

prefix 2001:06f8:0608:fab::/64 {

AdvOnLink on;

AdvAutonomous on;

AdvRouterAddr on;

};

};

The important parts are the link prefix and the setting for AdvOtherConfigFlag. Setting this to "on" will set the O flag in the RAs. The O flag tells a client that it should also try to contact DHCPv6 for further configuration. Fire up radvd according to the documentation, and move on to…

dhcp6s

I downloaded the WIDE DHCPv6 server from here. We have very little to hand out via DHCPv6, so the configuration file has just two lines:

option domain-name-servers 2001:6f8:608:ace::c0a8:5802;

option domain-name "pwned.by.v6";

Start it up, and move on to…

naptd

Get it here. Following the excellent documentation, we need to configure iptables and ip6tables like this:

root@evil-rtr:~# ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 1 -j DROP

root@evil-rtr:~# ip6tables -A FORWARD -d 2001:6f8:608:ace:: -j DROP

root@evil-rtr:~# iptables -A INPUT -i lo -j ACCEPT

root@evil-rtr:~# iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

root@evil-rtr:~# iptables -A INPUT -m state --state NEW -p tcp -m tcp --dport 22 -j ACCEPT

root@evil-rtr:~# iptables -A INPUT -j DROP

Then we can run napt-confmaker. I answered pretty much every question with the default answer, apart from the interface selections and the NAT-PT prefix.

Once we start naptd running, the trap is set.

The Attack

This is what the output of ipconfig looks like on the victim host before evil-rtr's IPv6 interface is connected to the network:

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix  . :

Description . . . . . . . . . . . : Atheros AR8131 PCI-E Gigabit Ethernet Controller (NDIS 6.20)

Physical Address. . . . . . . . . : 00-26-9E-47-4E-0F

DHCP Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

Link-local IPv6 Address . . . . . : fe80::119c:ea76:23d4:290d%10(Preferred)

IPv4 Address. . . . . . . . . . . : 192.168.0.2(Preferred)

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Lease Obtained. . . . . . . . . . : 30 March 2011 23:23:08

Lease Expires . . . . . . . . . . : 31 March 2011 13:55:33

Default Gateway . . . . . . . . . : 192.168.0.251

DHCP Server . . . . . . . . . . . : 192.168.0.251

DHCPv6 IAID . . . . . . . . . . . : 285221771

DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-52-C9-D5-00-26-9E-47-4E-0F

DNS Servers . . . . . . . . . . . : 192.168.0.251

NetBIOS over Tcpip. . . . . . . . : Enabled

The presence of a link-local IPv6 address confirms that the host is IPv6-capable. Once we connect evil-rtr's eth1 interface, the victim host sees the RAs, derives a routable IPv6 address for itself, then queries DHCPv6 for further configuration. Almost immediately, the output of ipconfig will change to look like this:

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix  . : pwned.by.v6

Description . . . . . . . . . . . : Atheros AR8131 PCI-E Gigabit Ethernet Controller (NDIS 6.20)

Physical Address. . . . . . . . . : 00-26-9E-47-4E-0F

DHCP Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

IPv6 Address. . . . . . . . . . . : 2001:6f8:608:fab:119c:ea76:23d4:290d(Preferred)

Temporary IPv6 Address. . . . . . : 2001:6f8:608:fab:687a:83f:caa7:8f9c(Preferred)

Link-local IPv6 Address . . . . . : fe80::119c:ea76:23d4:290d%10(Preferred)

IPv4 Address. . . . . . . . . . . : 192.168.0.2(Preferred)

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Lease Obtained. . . . . . . . . . : 30 March 2011 23:23:08

Lease Expires . . . . . . . . . . : 31 March 2011 13:55:33

Default Gateway . . . . . . . . . : fe80::225:4bff:fefd:9173%10

192.168.0.251

DHCP Server . . . . . . . . . . . : 192.168.0.251

DHCPv6 IAID . . . . . . . . . . . : 285221771

DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-52-C9-D5-00-26-9E-47-4E-0F

DNS Servers . . . . . . . . . . . : 2001:6f8:608:ace::c0a8:5802

192.168.0.251

NetBIOS over Tcpip. . . . . . . . : Enabled

Connection-specific DNS Suffix Search List : pwned.by.v6

It's game over for the poor victim host:

• It has routable IPv6 addresses of its own
• It has an IPv6 default gateway, which is actually the link-local address of evil-rtr's eth1 interface rather than the address we manually gave it earlier on.
• It has an IPv6 DNS server whose address matches the NAT-PT prefix used by naptd, and which will be translated into the IPv4 address of evil-DNS.

We have successfully awakened the victim's latent desire to use IPv6 in preference to IPv4. We've not needed any passwords, hacks or brute force. All we had to do was nudge the victim in the right direction.

Poetry in Motion

When the victim browses to www.google.com, evil-rtr's IPv6 eth1 interface sees this (download capture):

You can see the DNS queries sent via IPv6 to evil-DNS; both A and AAAA queries are sent, and IPv4 and IPv6 addresses delivered in response. Note that the returned IPv6 address matches our NAT-PT prefix, indicating that it has an embedded IPv4 address. The victim will choose to use this IPv6 address over the IPv4 one; evil-rtr is the man-in-the-middle.

The same transaction on evil-rtr's IPv4 eth0 interface looks like this (download capture):

Note that all the IP addresses are IPv4, and all the DNS queries are all for A records instead of the mix of A and AAAA that we saw on eth1.

Developing the Attack further

There are several things we can do to take the attack further:

• Given that this attack uses implanted hardware, we can make it really really tiny. Gumstix is an ideal platform; they're small, they run Linux, and there's a wide range of hardware on offer. An Overo Earth, a Tobi, and a 3G USB stick would give you a very small platform with an Ethernet interface to attach to the target network and an autonomous Internet connection. I've used Gumstix before; once you've got the build environment set up, the world's your oyster.
• We control evil-DNS, so we can make it return any IP address we like for www.google.com, thereby opening up numerous opportunities for phishing.
• In its current state, evil-rtr will MITM all traffic that is the result of a DNS query; this isn't exactly subtle. If we can make evil-DNS return addresses only for sites of interest we can be a good deal more selective. If we can make evil-DNS ignore requests we don't care about, the victim will fall back to their IPv4 DNS server and traffic will flow as normal.
• As we are the man-in-the-middle, we have the opportunity to interfere with the traffic between the client and the server. We could inject malicious iframes, change https:// links to plain old http:// links, etc, etc.
• <insert other creative evil here>

Defending against evil-rtr

The attack is possible because we were able to inject RAs onto a network of IPv6-capable hosts – the key differentiators between this attack and other similar ones is that we are not trying to subvert an existing IPv6 network; we are instead trying to build a new one out of nothing. Nevertheless, our rogue RAs were the catalyst for the successful attack. If we can stop them in their tracks, the attack will go nowhere.

Most of the time, rogue RAs are nothing more than a nuisance, often generated as a result of something as simple as turning on Windows' Internet Connection Sharing. However, it is a serious enough issue for the IETF to put together RFC6104, the "Rogue IPv6 Router Advertisement Problem Statement". This document is more concerned with brokenness caused by "accidentally-rogue" RAs than it is with security issues, but Section 3 gives a useful list of mitigation techniques. Sadly, most of these are difficult to employ either due to the lack of a suitable implementation (e.g., SEND), or a lack of capable hardware (e.g., RA Guard or switch ACLs). Cisco also have some tips on first hop security here and here.

If the attack can't be prevented by the methods listed in RFC6104, perhaps it can be detected instead. NDPMon is an IPv6 equivalent to ArpWatch and is designed to detect suspicious neighbour/router discovery traffic.

However, neither RFC6104 nor NDPMon will help to defend against a SLAAC Attack. Why would anyone deploy IPv6 countermeasures when they "aren't using" IPv6? A SLAAC Attack targets IPv6-capable IPv4 networks, not native IPv6 or dual stack ones. The most effective defence is simply to disable IPv6 on all capable hosts if there's no business reason to use it:

This is in complete alignment with the "Minimized" principle of the Defensible Network, but doesn't exactly foster the accelerated adoption of IPv6. I know which way I'd jump!

Hands-on labs on the SLAAC attack are being added to courses at InfoSec Institute. If you need IT Security training, check out our ethical hacking, computer forensics, reverse engineering courses, CCNA certification class or CSSLP training. Online IT Security training is also available.

References

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Introduction to IPv6 addressing and configuration