To explain the IPv6 MITM attack, let's first go over the basics.
In today's post we want to explain why man-in-the-middle attacks over IPv6 can easily lead to success, how to carry them out and what you can do to protect yourself from them. To understand the possible attack scenarios, let's briefly go back to the basics.
IPv6 is a newer version of IPv4, commonly known as the Internet Protocol. The Internet Protocol is one of the basic protocols for switching data packets over the Internet and local area networks. It is always required when data is to be transmitted between networks and systems. IPv6 was conceived because the available IP addresses in the IPv4 protocol are no longer sufficient for the ever-increasing number of networked devices. IPv6 has a much larger address range (IPv4: 32 bits, IPv6 128 bits), so it is very unlikely that the available addresses will run out again in the future.
It is interesting to mention that because IPv6 is the newer protocol, it is usually prioritized.
Another important property of IPv6 is that it can be managed without any administrative effort. We are talking here about the stateless automatic configuration (SLAAC) which allows systems to participate in IPv6 networks without configuration, ie without manually assigning IP addresses or setting up DHCP. This autoconfiguration is one of the bases for the attack. All communication for SLAAC runs over the Neighbor Discovery Protocol (NDP) and ICMPv6. Since systems automatically respond to requests and information from an IPv6 router system, changes can be made to the configuration of the systems that make attacks possible.
To carry out the attack, the attacker sends router advertisements into the network to let other systems know that it is acting as an IPv6 router and is available. Likewise, it acts as an unauthorized DHCPv6 server on the network. In doing so, it uses the "managed" flag to inform the systems that further configuration of the IPv6 interface takes place via a DHCPv6 server
The Fox-IT Security Research Team has released Snort and Suricata signatures to detect rogue DHCPv6 traffic and WPAD responses over IPv6:
alert udp fe80::/12 [546,547] -> fe80::/12 [546,547] (msg:"FOX-SRT - Policy - DHCPv6 advertise"; content:"|02|"; offset:48; depth:1; reference:url,blog.fox-it.com/2018/01/11/mitm6-compromising-ipv4-networks-via-ipv6/; threshold:type limit, track by_src, count 1, seconds 3600; classtype:policy-violation; sid:21002327; rev:2;)
alert udp ::/0 53 -> any any (msg:"FOX-SRT - Suspicious - WPAD DNS reponse over IPv6"; byte_test:1,&,0x7F,2; byte_test:2,>,0,6; content:"|00 04|wpad"; nocase; fast_pattern; threshold: type limit, track by_src, count 1, seconds 1800; reference:url,blog.fox-it.com/2018/01/11/mitm6-compromising-ipv4-networks-via-ipv6/; classtype:attempted-admin; priority:1; sid:21002330; rev:1;)
After performing the above ways to prevent the attack, you may unfortunately have to realize that there are attackers in your network.
If it is known from which IP the attack is coming, the attacker's port / MAC address can be blocked after sufficient information has been obtained in order to prevent further activities.
Especially in an emergency, we advise you to call in professional help and to document as much as possible.
When dealing with the following ISMS framework controls, the vulnerability and its elimination play a role:
ISO 27001:
A. 9.1.2 Access to Networks and Network Services
A.13.1.2 Security of Network Services
BSI Baseline Protection:
NET.1.1.A7
PSN ID: PS-TN-2020-0053
As a result, the client will request an IPv6 configuration in the network. The attacker can also respond to this and pretend to be a DHCPv6 server, thereby making configuration changes on the client.
The attacker now acts as a DNS server for the victim and can thus perform DNS spoofing. In reality this is used to spoof requests to the local domain. So if victims search for resources such as a WPAD via DNS query, the attacker supplies the victim with an incorrect storage address (again his own IP). A false WPAD is then delivered to the victim, and a proxy can be configured in the victim's browser, which can then be used to force NTLM authentication in a further step. This happens when the attacker responds to requests that come in via the newly entered wrong proxy with the http status code HTTP 407 Proxy Authentication required. This differs from the commonly used 401 code. All common browsers will then automatically authenticate themselves to the proxy via NTLM without the user having to do anything, provided NTLM is used and the browser is not explicitly hardened against this behavior. NTLM authentication can now be used for relay attacks or other attack techniques. The attack has been successful up to this point and IPv6 has been successfully exploited.
All network participants that communicate in the same network as the attacker. Windows clients, Windows servers, switches.
IPv6 can be deactivated on Windows systems by changing the registry. However, it must be checked whether the protocol is necessary.
As an alternative or additional solution, the attack can be prevented by configuring the switches. To do this, each switch must activate the IPv6 RA Guard and IPv6 DHCP Guard options.
The mitm6 tool can be used for testing. DANGER! As the tool modifies the victim's network configurations, systems may be compromised during and after the attack. This can result in network resources becoming unreachable. The most likely reason for this is that DNS queries from victim systems come to nothing because no valid DNS server can be reached. It is strongly recommended to use the -d option with the Active Directory local domain. Mitm6 will then only spoof requests for resources within that domain.
Command:
mitm6 -I INTERFACE -d DOMAIN --ignore-nofqdn
To do this, an interface (usually eth0) and the AD domain must be specified
Note:
The attack can also be carried out without specifying the domain, but this does not give the attack a scope. It follows that any query is manipulated, including a Google search, for example. However, this variant can mean a high level of data traffic running through the attacker's machine, which is why the obviousness of the attack is significantly increased. In addition, restrictions in the network will become noticeable for the other network participants because name resolution via DNS no longer works.
Command:
mitm6 -I INTERFACE
There are two solutions to correct the findings. The preferred solution is to deactivate IPv6 on all systems that do not require it. If IPv6 is not consciously used in a network, there is much to suggest that deactivation is possible. Only newer Exchange servers need IPv6 to communicate with each other. IPv6 can be effectively disabled by changing the registry via GPO on Windows systems. If it is not possible to deactivate the protocol, or if additional security measures need to be taken, then two switch options can be used. To do this, the switches must have the two functions IPv6 RA Guard and IPv6 DHCP Guard.
There are two ways to disable IPv6 on Windows systems. We currently recommend rolling out a registry change via GPO. For this purpose, a GPO can be created in which the following additions to the registry are made through an update.
The attack with mitm6 can also be deactivated on the switch. To do this, the RA Guard option must first be activated.
Configuration example:
1: SW1(config)#ipv6 nd raguard policy HOSTS
2: SW1(config-nd-raguard)#device-role host
Line 1 defines a new policy for the ipv6 nd raguard feature called HOSTS. The name can be chosen freely, but should be able to be clearly assigned to the role of systems. If the switch does not have this capability, the solution cannot be implemented. In line 2, all systems to which the policy is applied are assigned the host role with the device-role command. The device-role host means that the system is a client and not a router.
3: SW1(config)#interface GigabitEthernet 0/2
4: SW1(config-if)#ipv6 nd raguard attach-policy HOSTS
In the next step, line 3 selects the switch interface or interfaces to be configured. Since we do not want to allow any IPv6 routers in the network, the policy can be rolled out to all interfaces on all switches. Line 4 is the command to associate the previously defined policy with the selected interface or interface range.
5: SW1#show ipv6 nd raguard policy HOSTS
Line 5 shows the command to check if the policy is associated with the interfaces. If the configuration was successful, this command enumerates all interfaces on which the policy is attached.
In addition to the option for RA Guard, the functionality of DHCPv6 must also be restricted. The settings made here have no effect on existing infrastructures for DHCP in the context of IPv4 addresses.
1: SW1(config)#ipv6 dhcp guard policy DHCP_CLIENT
2: SW1(config-dhcp-guard)#device-role client
Line 1 creates a new policy for the dhcp guard function. In this case it is named as DHCP_CLIENT. The name can be chosen freely, but should be unique. In line 2, systems to which this policy is applied are provided with the device-role client, which means that all systems to which the policy is applied are DHCP clients. As a result, functions of a DHCPv6 server or network packets sent by such a system are rejected by the switch if this policy is applied.
3: SW1(config)#interface range GigabitEthernet 0/2 - 3
4: SW1(config-if-range)#ipv6 dhcp guard attach-policy DHCP_CLIENT
Interfaces are selected in line 3. Similar to the RA Guard, all interfaces can be selected here because there is no legitimate DHCPv6 server in the network. With the command from line 4, the created policy DHCP_Client is linked to the selected interfaces.
5: SW1#show ipv6 dhcp guard policy
Line 5 shows the command to check if the created policy is applied. If the configuration worked, all interfaces on the switch are displayed here.
We use cookies, and Google reCAPTCHA, which loads Google Fonts and communicates with Google servers. By continuing to use our website, you agree to the use of cookies and our privacy policy.