Giters

dirkjanm / mitm6

pwning IPv4 via IPv6

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

DNS server spoofing only working once

KBCShared opened this issue · comments

commented

Hi,

I came across the following problem in my lab:

I've set up a Kali Host and a Win10 machine on VMware residing on the same network. No changes have been made to the IPv6 configuration of the Win10 machine:

Connection-specific DNS Suffix  . : localdomain
Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
Physical Address. . . . . . . . . : 00-0C-29-54-B5-84
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::2527:53eb:9abd:8df2%15(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.13.129(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Freitag, 12. Juli 2019 15:43:06
Lease Expires . . . . . . . . . . : Freitag, 12. Juli 2019 16:13:08
Default Gateway . . . . . . . . . :
DHCP Server . . . . . . . . . . . : 192.168.13.254
DHCPv6 IAID . . . . . . . . . . . : 50334761
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-22-15-BB-A2-00-0C-29-54-B5-84
DNS Servers . . . . . . . . . . . : 9.9.9.9
NetBIOS over Tcpip. . . . . . . . : Enabled

When i start wireshark on Kali I can't see any DHCPv6 requests.
Update: I now know, that this is because of my lab running on an ESXi. Kali won't see the DHCPv6 messages because vSphere virtual switches implement the MLDv2 protocol. Windows sends DHCPv6 solicit to the all-dhcp-agents multicast address and the Kali machine is not part of this group (although this functionality could be added to mitm6 I guess).

If I start mitm6 with mitm6 -i eth0, Win10 will recognise Kali (due to the RA or Router Advertisement I guess) and send a DHCPv6 request. mitm6 sends the reply and Win10 sets the IPv6 parameters as intended:

Connection-specific DNS Suffix  . : localdomain
Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
Physical Address. . . . . . . . . : 00-0C-29-54-B5-84
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::9900:1%15(Preferred)
Lease Obtained. . . . . . . . . . : Freitag, 12. Juli 2019 15:54:12
Lease Expires . . . . . . . . . . : Freitag, 12. Juli 2019 15:59:12
Link-local IPv6 Address . . . . . : fe80::2527:53eb:9abd:8df2%15(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.13.129(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Freitag, 12. Juli 2019 15:43:06
Lease Expires . . . . . . . . . . : Freitag, 12. Juli 2019 16:13:08
Default Gateway . . . . . . . . . : fe80::b49f:39ff:fe37:9cd6%15
DHCP Server . . . . . . . . . . . : 192.168.13.254
DHCPv6 IAID . . . . . . . . . . . : 50334761
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-22-15-BB-A2-00-0C-29-54-B5-84
DNS Servers . . . . . . . . . . . : fe80::b49f:39ff:fe37:9cd6%15
                                   9.9.9.9
NetBIOS over Tcpip. . . . . . . . : Enabled

The corresponding wireshark log looks like this (IPv6 ending in 9cd6 being Kali, 8df2 being Win10):
image

mitm6 is sending fake DNS responses and I get connections from Win10 to ntlmrelayx.py. Everything OK so far!

If I stop mitm6 on Kali, everything regarding IPv6 is reverted in Win10 after the lease timeout:

Connection-specific DNS Suffix  . : localdomain
Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
Physical Address. . . . . . . . . : 00-0C-29-54-B5-84
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::2527:53eb:9abd:8df2%15(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.13.129(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Freitag, 12. Juli 2019 15:43:06
Lease Expires . . . . . . . . . . : Freitag, 12. Juli 2019 16:28:08
Default Gateway . . . . . . . . . :
DHCP Server . . . . . . . . . . . : 192.168.13.254
DHCPv6 IAID . . . . . . . . . . . : 50334761
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-22-15-BB-A2-00-0C-29-54-B5-84
DNS Servers . . . . . . . . . . . : 9.9.9.9
NetBIOS over Tcpip. . . . . . . . : Enabled

The interesting (or annoying) thing now is that I cannot get the attack to work a second time. If I start mitm6 again with mitm6 -i eth0, a RA is sent via multicast but Win10 doesn't send a DHCPv6 request:
image

Win10 only sets the Default Gateway and that's it. No DNS server is set, no DHCPv6 messages are exchanged:

Connection-specific DNS Suffix  . : localdomain
Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
Physical Address. . . . . . . . . : 00-0C-29-54-B5-84
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::2527:53eb:9abd:8df2%15(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.13.129(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Freitag, 12. Juli 2019 15:43:06
Lease Expires . . . . . . . . . . : Freitag, 12. Juli 2019 18:28:08
Default Gateway . . . . . . . . . : fe80::b49f:39ff:fe37:9cd6%15
DHCP Server . . . . . . . . . . . : 192.168.13.254
DHCPv6 IAID . . . . . . . . . . . : 50334761
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-22-15-BB-A2-00-0C-29-54-B5-84
DNS Servers . . . . . . . . . . . : 9.9.9.9
NetBIOS over Tcpip. . . . . . . . : Enabled

The IPv6 gateway stays there for a while (I guess 1800s as announced in the RA) and then disappears. If I start mitm6 again the same thing happens again.

I tried the following things which didn't help:

  • Assigning a new MAC and IPv6 address to Kali
  • Starting mitm6 with --no-ra: Nothing happened at a network level because Win10 never sent DHCPv6 requests on its own. It only reacted to RAs. Update: I now know, that this is because of my lab running on an ESXi. Kali won't see the ICMPv6 messages because vSphere virtual switches implement the MLDv2 protocol. Windows sends ICMPv6 solicit to the all-dhcp-agents multicast address and the Kali machine is not part of this group (although this functionality could be added to mitm6 I guess).

These things did help:

  • Rebooting the Win10 machine
  • Deactivating the IPv6 protocol on the network adapter on Win10 an re-enable it.

I found the following Microsoft thread:
https://social.technet.microsoft.com/Forums/office/en-US/b16e7d78-e390-4ada-a24b-3ccba60fa571/no-ipv6-dns-statelessdhcp-since-windows-10-anniversary-update

Reading the second last comment from bigjoesmithh indicates that this could be a problem within Windows 10:

Windows client will not correctly pull DNS information from a DHCPv6 server after correctly doing stateless address configuration using router assignment [...]

So the problem maybe occurs only if Win10 doesn't send DHCPv6 Solicit messages on its own but only reacts to router advertisements.

The following questions occur to me:

  • Do you have an idea why Win10 behaves this way?
  • Is there a way we could tell the victim, that it should forget everything it learned from mitm6? Some message that notifies the Win10 machine, that the DHCP/DNS server no longer exists?
  • Do you have an idea why some Win10 machines send DHCPv6 Solicit messages but others don't?
commented

Hey @KBCShared Did you ever get any further with your research on this one? I just opened an issue for what is likely a totally different issue, but part of my issue is seeing some of the Win10 behavior you mention above.