Practical hacking in IPv6 networks with Evil FOCA

ElevenPaths [email protected] elevenpaths.com

Practical hacking in IPv6 networks with Evil FOCA

August 2013

ElevenPaths elevenpaths.com

Page 1 of 27

Table of Contents

Introduction ................................................................................................................................................ 2

IPv6 basic concepts ..................................................................................................................................... 2

Neighbor Spoofing ..................................................................................................................................... 11

SLAAC attack with Evil Foca ....................................................................................................................... 14

Step 1: Sabotage or misconfiguration of IPv4 ....................................................................................... 15

Step 2: Configure IPv6 ........................................................................................................................... 16

Step 3: DNSv6 ........................................................................................................................................ 18

How the attack works............................................................................................................................ 19

Bridging HTTP (IPv6) - HTTPs (IPv4) ........................................................................................................... 22

Step 1: Attacking with Evil FOCA ........................................................................................................... 22

Step 2: Intercepting the credentials ...................................................................................................... 24

23


Page 2 of 27

Introduction

The IPv6 protocol was designed as a solution for the ever growing demand of IP addresses and the

continuous expansion of Internet. The lack of public IP addresses became self-evident after the

introduction of modern mobile devices and concepts such as “The Internet of things” and M2M (machine

to machine). The NAT (Network Address Translation) protocol was a short-term solution compared to the

“new” 128-bit addresses that IPv6 introduces, which guarantees sufficient enough addresses for all

modern devices.

The working and detailed operation of IPv6 was detailed in RFC 2460 which dates back to 1998, and as

we’ll see further on, it introduces various weaknesses and vulnerabilities by design that continue

unpatched nowadays. Apparently, the integration of IPv6 in network and personal devices has been very

slow, although it has been activated and configured by default in most operating systems recently, and

some protocols like SMB and DNS use it by default. Therefore, the study and awareness of the threats

that IPv6 introduces becomes mandatory.

Before introducing the different attack scenarios we will dive deeper in the working of IPv6 for a wider

view and better understanding of the problems exposed in the following chapters.

IPv6 basic concepts

IPv6 is automatically configured by default in most operating systems and if the end user doesn’t take

conscience of it, it can become a security threat.

Figure 1: A local-link IPv6 address configured by default.

IPv6 addresses consist of 128 bits separated in 16-bit groups in a hexadecimal notation. This is

represented as 8 groups of 4 hexadecimal values. As an example, an IPv6 address may look as follows:

fe80:123:0000:0000:0000:0000:0000:1ab0

To simplify this notation, when there is a group of four consecutive zeros we can use the “::” symbol. For

example the address in the previous example would be reduced to: fe80:123::1ab0.

This shortening can only be applied one time for each address. A common IPv6 local area address

(equivalent in IPv4 to 192.x.x.x and 10.x.x.x) could be, for example, fc00::1.


Page 3 of 27

Figure 2: Example of an IPv6 configuration in Windows

Secondly, the equivalent in IPv4 of “network mask” is called in IPv6 Subnet prefix or CIDR prefix.

This element has changed due to the amount of problems caused in IPv4 by subnetting, supernetting and

the use of network masks such as 255.0.254.255 that resulted confusing.

However, the function of the prefix stays the same: subnetting/supernetting and managing the visibility of

the network.

For example, if we were to assign two IPv6 addresses (without configuring a gateway) such as:

A:fc00::2000:0001/96

B:fc00::2001:0001/112

Sending a ping request in IPv6 from A to B would result in a “Time-Out“-response, as well as the same

request from B to A would result in a “Host inaccessible”-response because A is not in the same network

as B, but B is in the same as A.

To interconnect IPv6 networks, like in IPv4, it is necessary to use a Gateway which is configured in the

network protocol properties tab, as well as the IPv6 servers that will be used for address resolution.


Page 4 of 27

For reference, the CIDR prefix table is the following:

For example if an administrator wants to configure a LAN network the default prefix would be “64”, as in

IPv4 the default network mask would be 255.255.255.0.

Local link addresses in IPv6

Every NIC (Network Interface Card) that supports IPv6, no matter if configured manually or automatically

(default setting in Windows and Mac OS X), will have an associated Local link address.


Page 5 of 27

Figure 3: Default settings in Mac OS X

This address is generated automatically and announced in the network to avoid colliding addresses using

the NDP (Neighbor Discovery Protocol). Generally the duplicity of local link addresses should not happen

because of the generation algorithm which depends on the physical MAC address of the network card.

Although the NDP protocol is used for matters of redundancy and avoiding conflicts.

Local link addresses are part of the fe80::/10 range, which would be equivalent in IPv4 to 169.254.1.X -

169.254.254.X. This range is not regularly used in IPv4, in IPv6 they’re very frequent, though.

Obviously this address range is not routable, although it is used for communicating with the router or any

server that is located in the same local area network segment. The default configuration assigns one of

these local link addresses and can be used for example to ping any other computer in the LAN with an

IPv6 local link address.


Page 6 of 27

Figure 4: Pinging a NETBios name using local link IPv6 addresses

Common IPv6 addresses

In addition to local link addresses, in IPv6 there quite many interesting addresses that should be well-

known. Here is a list of the most important ones:

• ::/128: The undefined IPv6 address (all bits to 0).

• ::/0: The address that is used to represent the default route in a routing table. Equivalent in

IPv4 to 0.0.0.0.

• ::1/128: Localhost in IPv6. Equivalent to 127.0.0.1 (IPv4).

• fe80::/10: Local link addresses. These are not routable but they generate a local area network

in the fe80::/64 range.

• ff02::/16: Addresses of IPv6 Multicast networks. Equivalent to (224.X) in IPv4.

• fc00::/7: Private IPv6 network addresses. These aren’t routable either and they’re equivalent

to 10.X, 172.16.X and 192.168.X in IPv4 networks.

• ::ffff:0:0/96: IPv4 addresses mapped in IPv6. They’re used for conversions and

interconnection of IPv4 and IPv6 protocols.

• 64:ff9b::/96: IPv6 addresses generated automatically from IPv4. They’re used when it is

necessary to generate new IPv6 addresses from the IPv4 address in use.

• 2002::/16: Sign of a 6 to 4 mapped network that will use the IPv4 192.88.99.X address as

gateway for interconnecting the network.

Apart of these addresses there’re some reserved ones for special purposes such as the following:

• 2001::/32: Used by the Teredo tunneling protocol which allows doing tunneling of IPv6

networks over IPv4 in the Internet. This is used when implementing Direct Access in

Windows Server 2008 R2 and Windows 7.

• 2001:2::/48: Assigned to Benchmarking Methodology Working Group (BMWG) for

benchmarking in IPv6. Similar to the 198.18.0.0/15 network range for benchmarking in IPv4.

• 2001:10::/28: ORCHID (Overlay Routable Cryptographic Hash Identifiers). Non-routable IPv6

addresses used for cryptographic hash identifiers.

• 2001:db8::/32: Used for documentation and examples in IPv6. Similar to the 192.0.2.0/24,

198.51.100.0/24 y 203.0.113.0/24 network ranges in IPv4.

Protocol precedence

In today’s computers most probably IPv6 coexists with IPv4 and the operating system itself is the

responsible of choosing between both protocols complying with certain rules. These rules are defined in a

protocol precedence algorithm confined in RFC 3484 and the more recent RFC 6724 that was published in

September 2012 and is entitled “Default Address Selection for Internet Protocol version 6 (IPv6)”. This

paper establishes the rules for protocol selection between IPv6 and IPv4 in a mixed environment.


Page 7 of 27

Figure 5: RFC 6724

The document illustrates two algorithms based on the addresses of origin and destination for choosing

one protocol or another. These algorithms consider complex situations such as the existence or not of

gateways. For example, it could happen that the addresses of origin and destination are both IPv4-format

but the destination address is located in another network which is only reachable via an IPv6 gateway. In

this case, the algorithm could choose routing IPv4 traffic over IPv6.

In Microsoft Windows it is possible to configure the priority table with the command netsh interface ipv6

show prefix which will show a table similar to the illustrated in Figure 6.

Figure 6: Default precedence table in Microsoft Windows 7

The precedence algorithm gives priority to IPv6 over IPv4 if it’s possible to establish communication with

the mentioned protocol, however it is possible to change this behavior using the netsh command.

• netsh interface ipv6 show prefixpolicies: Shows the local policies table.

• netsh interface ipv6 add prefixpolicies: Adds new entries to the table.

• netsh interface ipv6 set prefixpolicies: Configures entries in the table.

• netsh interface ipv6 delete prefixpolicies: Deletes entries from the table.

Example:


Page 8 of 27

netsh interface ipv6 set prefixpolicies prefix=2001::/32 \

precedence=15 label=5

This behaviour doesn’t interfere with the choice that an application or an user may have previously made

explicitly. It’s a behaviour rule that works when no other restriction has been previously established.

Neighbor Discovery Protocol

Discovering adjacent devices in the same IPv6 network is based on ICMPv6 messages. The Neighbor

Discovery Protocol implements five different messages. Similarly to ARP there are Neighbor Solicitation

(NS) and Neighbor Advertisement (NA) messages. These are used to resolve a MAC address given an IPv6

address and to respond with the corresponding MAC address, respectively.

Most commonly these messages are sent to a multicast address, but unicast messages for direct

communication can also be used.

Figure 7: Neighbor discovering with a multicast NS message and an unicast response.

Every MAC address associated to an IPv6 address will be stored in a Neighbor table that can be seen using

the following command: netsh interface ipv6 show Neighbor.

Figure 8: IPv6 Neighbor table


Page 9 of 27

These messages will be important in some of the IPv6 DoS (denial of service) and MiTM (man in the

middle) attacks.

Name resolution in local networks

In Microsoft Windows to make name resolution compatible with IPv4 and IPv6 the LLMNR (Link-Local

Multicast Name Resolution) protocol was introduced (described in RFC 4795). LLMNR is a protocol that

uses multicast and makes it possible to resolve domain names via IPv4 or IPv6. It allows making local

searches or resolving A/AAAA DNS registers.

Figure 9: Resolution of “srv” with LLMNR using multicast IPv6, IPv4 and DNS

Using LLMNR address resolution, MAC address searches with NDP and the precedence table, Microsoft

Windows computers have a complete set for IPv6 communication.

IPv6 Configuration

There’re different ways to configure IPv6-enabled computers in a network. First of all, manual

configuration can be chosen which needs individual configuration (or using a script) of IPv6 address,

gateway and DNS servers.

The second way is using DHCPv6 for configuring every property in an IPv6 network. DHCPv6 is supported

in Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012. Its use is very similar to

DHCPv4 and allows assignation of IPv6 address, network prefix, gateway and DNS servers.


Page 10 of 27

Figure 10: DHCPv6 server in Windows Server 2008. DNS configuration.

The third way of configuring IPv6 devices is using the NDP (Neighbor Discovery Protocol) protocol, RS

(Router Solicitation), RA (Router Advertisement) and Redirect messages together with SLAAC (Stateless

Address Auto Configurator).

SLAAC enables devices to connect automatically to an IPv6 network if they know a router to connect to.

For doing so, a simple RS packet is sent in search of a gateway.

Every router in the network will respond with a RA packet, which gives SLAAC the necessary information

for the device to configure itself with an IPv6 address that allows it to connect via the router. If there’s

more than one router in the network, the device chooses any router available. If the router detects a

more favourable route it will send back a “Redirect” NDP packet with the information for refreshing its

routing table.

DHCPv6 and SLAAC will be used for DoS and MiTM attacks in IPv6 networks as we will see.

DNS Autodiscovery

When a device connects to an IPv6 network using a SLAAC configuration it can’t configure the DNS servers

by itself. Address resolution is reduced to LLMNR in search of servers in its own network.

However, if the domain is outside of the internal network it is necessary to have a DNS service in the IPv6

network. Microsoft Windows devices search automatically three IPv6 addresses established by the

standard “IPv6 DNS Autodiscovery”.


Page 11 of 27

Figure 11: DNS Autodiscovery

If a company doesn’t want to use DHCPv6, they can configure a DNS in some IPv6 address and send RA

messages with an IPv6 router for the client devices to configure themselves.

Neighbor Spoofing

The first attack in IPv6 networks that has to be taken in consideration is Neighbor Spoofing which very

similar to ARP Spoofing in IPv4 and also enables man in the middle attacks.

As mentioned before, to discover a Neighbor in the same network the NDP protocol is used. This subset

of ICMPv6 messages counts with two specific messages that will convert an IPv6 address into a Local-Link

address which in local area networks will be the MAC.

The general operation is one device which sends a Neighbor Solicitation NS message to a multicast

address and the corresponding device sends back an unicast message called Neighbor Advertisement NA

with the information of his MAC address. This address will be saved in the Neighbor table of the

requesting device.

However as in the ARP protocol in IPv4 an attacker can send a NA message without having been asked by

a NS and put arbitrary information in the cache of the victim’s routing table. A man in the middle scenario

will therefore send two NA packets to two network devices adding in both machine’s neighbor table the

convenient IPv6 and MAC addresses.

Figure 12: NA packet sent spoofing the IPv6 address fe80::f47c:d2ae:b534:40b2


Page 12 of 27

Figure 13: NA packet sent spoofing the IPv6 address fe80::f95c:b7c5:ea34:d3ff

The attack is made by spoofing the IPv6 address of the origin of the packet and simulating a packet that

comes from the victim’s computer. In both sending attempts the MAC of the attacker is established in

order to trick the switch to send the messages to the “middleman”.

Neighbor Spoofing with Evil FOCA

The Neighbor Spoofing attack is implemented in Evil FOCA and it is as easy as selecting two devices for the

MITM (man in the middle) attack and Evil FOCA will forge the necessary NA packets.

Figure 14: Man in the middle attack with Neighbor Spoofing using Evil FOCA

Once the attacker has access to the communication between the victims it is easy to capture the files

transmitted in a local network via IPv6. For example, Windows Server 2008 R2 and Windows 7 use IPv6 by

default for SMB communications. Sometimes MiTM attacks with ARP Spoofing seem to fail in IPv4 but the

explanation is as simple as IPv6 being used to access the SMB server.


Page 13 of 27

For example in figure 14 it can be observed that Evil FOCA has discovered two devices that have both IPv6

and IPv4 enabled, but we chose to do an IPv6 Neighbor Spoofing attack with ICMPv6

One of the victims connects to a SMB server which contains a file named Password.txt.

Figure 15: Accessing a shared file through SMB

Analyzing the traffic captured by the attacker we can observe the SMB packets and obtain the password

that was transmitted over IPv6.

Figure 16: SMB traffic over IPv6

Following the TCP Stream it’s possible to access the file that has been transmitted.

http://3.bp.blogspot.com/-z_S6kfao34k/T468i-_YemI/AAAAAAAAKKw/D3B7kuXJHx8/s1600/Wireshark.png


Page 14 of 27

Figure 17: Capturing the file sent over SMB

SLAAC attack with Evil Foca

The SLAAC attack consists of a Man in the Middle attack to a victim that tries to connect to a server

without IPv6 support which will be necessary to contact over IPv4. Evil FOCA will automatically act as the

middleman configuring IPv6, preventing the victim from connecting over IPv4 and configuring NAT64 and

DNS64 services for the victim not to lose connectivity. The scheme of the attack can be seen in figure 11.

Figure 18: Connection scheme

In this example RootedCON.es will be used

http://3.bp.blogspot.com/-5yw1Ht5Tor8/T464n9v3ugI/AAAAAAAAKKg/GsrYtI1AXLM/s1600/Wireshark3.png


Page 15 of 27

Doing a search for the DNS registers of RootedCON will show that there are no IPv6 associated to the

domain.

Figura 19: www.roootedcon.es doesn’t have IPv6 addresses

The first step is to get the victim to navigate to this page using IPv6 setting up a man in the middle attack.

Step 1: Sabotage or misconfiguration of IPv4

The easiest way is to search for a device that is connected to the internet through a router that has only

support for IPv4 with DHCPv4 enabled. In this scenario we’ve managed the router not to give the victim

any IP address using a Rogue DHCPv4 or DHCP ACK Injector attack. This will force the victim a Local link

address and no IPv4 gateway. Another possibility is a DoS attack against the DHCPv4 server for it to run

out of IP addresses and prevent it from assigning any to our victim.


Page 16 of 27

Figure 20: Victim with only local link address.

In any case, what we’ll achieve is that the victim will have a IPv4 configuration with only a local link

address (169.254.X.X) without assigned gateway and therefore no connection to the Internet.

Step 2: Configure IPv6

For the victim to obtain an IPv6 address only configuring a gateway pointing to the attacker’s IPv6 address

running Evil FOCA is needed. For this purpose, a SLAAC packet will be sent and the victim will have an IPv6

address with connectivity to the Evil FOCA and a gateway pointing to the attackers machine.

For achieving it, we need to find our victim’s computer in the list.

Figure 21: Scanning the network with Evil FOCA

After that, we select the SLAAC attack and the network prefix necessary for the victim to have IPv6

connectivity.


Page 17 of 27

Figure 22: Selection of the victim

Clicking on the “Start”-button will send the victim his specially crafted RA packet for configuring himself

with the configuration imposed by the attacker.


Page 18 of 27

Figure 23: SLAAC attack successfully launched

Step 3: DNSv6

During this attack there’s no need to configure the DNS over IPv6 because as soon as the victim has a

gateway with connectivity to the Internet it will automatically search in the DNSv6 servers the addresses

forced by DNS Autodiscovery as illustrated in figure 24.


Page 19 of 27

Figure 24: IPv6 address forced by SLAAC, gateway pointing to attacker and DNSv6 servers

set up by DNS Autodiscovery

As the DNS servers are out of the victim’s local network every request will be controlled by the attacker.

Evil FOCA will process them correctly for the victim not to lose connectivity.

From this moment on, the victim has its configuration ready for navigating. We only need it to connect to

the given URL and Evil FOCA will do the rest.

Figure 25: Navigating to Rootedcon.es without IPv4 support

How the attack works

After having the IPv4 environment configured with local link address only, IPv6 gateway pointing to the

attacker and DNSv6 configured what Evil FOCA does is offer DNS64 and NAT64 prepared for the attack to

be successful.

DNS64

Evil FOCA is intercepting the DNSv6 requests, therefore no matter where requests are sent (DNSv6

servers in the Internet, a DHCPv6 configured server…) the response will always be manipulated by Evil

FOCA and will always provide an IPv6 address. When the victim tries to ping www.rootedcon.es Evil FOCA

will respond with an IPv6 address.


Page 20 of 27

Figure 26: www.rootedcon.es associated with an IPv6 address

If we observe a traffic capture made with Wireshark by the attacker the process is verified to be as

follows:

Figure 27: DNS address resolution of www.rootedcon.es

a) First the victim sends an AAAA address resolution request of www.rootedcon.es to a

server given by DNS Autodiscovery.

b) The attacker makes an A address resolution request to resolve www.rootedcon.es using

IPv4.


Page 21 of 27

c) The DNSv4 server responds with the IPv4 address of www.rootedcon.es

d) Evil FOCA generates an IPv6 address from the real IPv4 address and hands it over to the

victim which will use it for the rest of the requests.

NAT64

Once the victim is given the IPv6 address associated to www.rootedcon.es that Evil FOCA has crafted for

him the subsequent HTTP requests will be sent over IPv6. Today’s modern browsers support IPv6 and it’s

usually the network or the server itself which doesn’t provide support for IPv6.

Figure 28: Default configuration of DNS AAAA register resolution in Mozilla Firefox

Once we have IPv6 addresses forged by Evil FOCA for Internet hostnames the rest of the work consists of:

a) Listening to the IPv6 request from the victim.

b) Make the IPv4 request to the server.

c) Listen for the IPv4 response.

d) Hand it over to the victim over IPv6.


Page 22 of 27

Figure 29: HTTP request passing through the NAT64 service

Figure 29 illustrates how the IPv6 request made by the victim is resent by Evil FOCA over IPv4

One of the characteristics of MS Windows computers is that they show the network status icon in the

bottom right corner. The victim can detect whether connection to the Internet is available or not.

Figure 30: DNS requests for checking Internet connectivity

Evil FOCA detects these DNS requests that are made for checking Internet connectivity and responds to

them without alerting the victim.

As a countermeasure against a SLAAC and flood RA attacks we can disable “routerdiscovery” in a

Windows machine using the following command:

netsh interface ipv6 set interface "Nombre NIC" \

routerdiscovery=disabled

Bridging HTTP (IPv6) - HTTPs (IPv4)

Evil FOCA is also capable of bridging HTTP(IPv6) to HTTPs(IPv4) for man in the middle attacks in websites

that only work under HTTPs.

An example using tuenti.com:

Step 1: Attacking with Evil FOCA

The first step is identical to the previous attack: sending a SLAAC packet for assigning the attacker’s IPv6

address as the gateway of the victim. For this to work, IPv4 can’t get its configuration over DHCPv4 and

has to configure itself with a local link address.


Page 23 of 27

Figure 31: Sending a RA packet to the victim

As previously described the network settings of the victim are to be as follow: a local link IPv6 address and

an IPv6 gateway pointing to the attacker.

Figure 32: Victim configuration (DNS servers given by DNS Autodiscovery)

Resolving the www.tuenti.com hostname, an IPv6 address generated by Evil FOCA is handed over to the

victim.


Page 24 of 27

Step 2: Intercepting the credentials

The rest of the work is done by Evil FOCA transparently. Every HTTPs link suffers a sslStrip process (the “s”

is removed) so that the communication is done in HTTP (cleartext) including the login process with Tuenti.

Once the victim sends the HTTP request Evil FOCA will try to replicate it with the, although if the server

only accepts HTTPs it will retry the same request over HTTPs for obtaining a normal response. However,

the traffic between the victim and the attacker is cleartext.

Figure 33: The credentials are sent over IPv6 using HTTP

In figure 33 we can clearly see that the navigation is done over IPv6 using an URI in the HTTP request. The

attacker can therefore see the credentials of its victim who could only notice that he’s not surfing using

TLS/SSL as usually.

Figure 34: The victim navigating normally over IPv6 and HTTP

For the victim to maintain its navigation session, Evil FOCA delivers the user’s cookies without the Secure

flag. This process is automatic and transparent.

In case that the victim only has IPv6 activated (IPv4 switched off) when resolving a hostname the requests

will be of type A instead of AAAA. In other words, the request to the DNSv6 server will return an IPv4

address which prevents the MiTM attack from working.


Page 25 of 27

For solving this issue, when the victim makes a type A request to the Evil FOCA it will automatically act as

if it was asked an AAAA type record and manipulate the request.

This trick seems to work and is illustrated in the following example using www.elladodelmal.com

Figure 35: The victim requests type A records but Evil FOCA delivers type AAAA.

In the response packet to a DNS query the initial request is also included, this is also modified by the Evil

FOCA making the victim believe that he asked for a AAAA type record.


Page 26 of 27

Figure 36: Evil FOCA responds as if an AAAA type record was requested

Technology

Practical hacking in IPv6 networks with Evil FOCA