Responder and IPv6 attacks

 Responder 3.1.1.0 comes with full IPv6 support by default, which allows you to perform more attacks on IPv4 and IPv6 networks. As pointed by several people over the years, Responder has always been lacking of IPv6 support and missed several attack paths, especially when it comes to IPv6 only networks or even mixed IPv4/IPv6 since IPv6 is always the preferred stack on Windows.

Responder also comes with a basic DNS server answering to A, SRV and now AAAA records. Tools like mitm6 can be used to get IPv6 traffic (via DHCPv6) and Responder will take care of answering the resulting IPv6 and IPv4 DNS requests.

While working on Responder IPv6 implementation i started to wonder how could it be possible to inject some network settings on IPv4 hosts with a static IP, such as a Windows domain controller. One of the great thing about IPv6 implementation, from a pentester standpoint,  is that you don't need to be on an IPv6 enabled network to successfully conduct these attacks.

IPv6 Router Advertisement:

Since DHCPv6 had already been pretty well covered by @_dirkjan with mitm6, and since we are primarily targeting hosts with a static address, ICMPv6 Router Advertisement seemed like a good option. In this case, we don't need to inject a route, or even an IP, the ideal goal would be a DNS server, which is possible on any Windows workstation/servers even when their IPv4 DNS settings are static, but not on a domain controller.

 

IPv6 RA DNS / DNSSL:

Since I was not able to either inject an IPv6 IP or DNS server on the domain controller, the only option left was DNSSL (RFC 6106).

DNSSL allows you to provide a DNS suffix or also commonly known as DNS Search List. For example, if you're part of the domain name "test.local" and your workstation name is desktop-123, the FQND would be "desktop-123.test.local" and the DNS suffix would be "test.local".

Scapy to the rescue:

Scapy is a great tool/library to quickly test this kind of payload on your network.
The following Python proof of concept will add a DNS suffix on a domain controller (server 2019, with latest updates):

>>> from scapy import all

>>> ra = IPv6 (dst = 'FF02::1')/ICMPv6ND_RA (routerlifetime = 0, reachabletime = 0, prf = 0)/ICMPv6NDOptDNSSL (lifetime = 120, searchlist = ['data.rogueserver.live'])

>>> send(ra)

These lines means send a multicast ICMPv6 Router advertisement to 'FF02::1', router lifetime and reachabletime is set to 0 and we inject a DNSSL called 'data.rogueserver.live' with a lifetime of 2 minutes; We don't want to mess for too long, since every hosts listening for ICMPv6 RA advertisement multicast, will get poisoned with that DNSSL.

Effect on The Domain Controller:

Basically, every DNS requests that were not resolved by the DNS server (domain controller) will be sent to 'data.rogueserver.live'. So for example, if your workstation is joined to the "corp.local" domain, and it's looking for "wpad.corp.local" and that entry does not exist then the PDC will issue a DNS lookup (before NBT-NS/LLMNR -if enabled-) for "wpad.data.rogueserver.live".

This should not cause much disruption on the network since normal DNS queries will be first resolved by the domain controller, actually most home modem/router usually has a '.lan' '.local' DNS suffix and those DNS requests goes unanswered all the time.

 

Responder Attack:

 Now that we have successfully injected a DNS suffix on the domain controller, we need to exploit it.
Steps are similar to SSRF, SQLI, XXE exfiltration, first you need a cheap domain name, like 'rogueserver.live' and a server on the internet.

Next step is to configure DNS settings on your domain name:

• Set an A record like 'rogueserver.live' for your domain name pointing to your server IP.
• Set another A record like 'ns.rogueserver.live' for your domain name pointing to you server IP
• set a NS record for 'data.rogueserver.live' pointing to 'ns.rogueserver.live'
• set 2-3 NS records for 'rogueserver.live' pointing to your DNS provider. Usually ns1.provider.com, ns2.provider.com, etc.

DNS has been setup, now comes the Responder part. First, i had to update Responder's DNS server to take care of the pseudo-record OPT for EDNS since every requests coming from the PDC will have an OPT additional record (RFC 7873).

 

You need two instances of Responder. One on the target local network, let's say hosted on 192.168.0.175 and one instance on the internet.

 

The instance on the internet will be used as a rogue DNS server, answering to the domain controller with the local IP of the other Responder instance hosted on the local network.

The attack looks like that on the VPS Responder instance:

 

Here, we are using Responder with the -e option, which poison the request with an IP of our choice, in this case a local IP (192.168.0.175), poisoned from the internet.

And on the other Responder instance (192.168.0.175), which is located on the local network where the target PDC is located:
 

Additional Remarks:

With that DNS suffix injected, any sysadmin on the network who mistype a name like 'pdc02' instead of 'pdc-02' will get poisoned, since the name wont be resolved by active directory DNS server, and our rogue server will resolve it. Basically, it will act as what LLMNR/NBT-NS use to do before it was disabled; Resolving queries that were not resolved by the domain controller, but with the priority of a DNS lookup.

Remediation:

Disable IPv6 on the domain controller if it's not necessary.
If IPv6 is necessary on your network, look for switch security option such as RAguard on cisco.

Responder's DHCP Poisoner

 Responder 3.0.7.0 comes with a new DHCP poisoner module. This module allows you to remotely inject a WPAD server with no user interaction (0 click) and capture/relay NTLM credentials on all Windows versions ranging from Windows 98 to the current version (Windows 11, Server 2022).

WPAD and DHCP

 Windows uses several custom DHCP options such as NetBIOS, WINS, WPAD settings. When a workstation sends a DHCP request to get its networking settings, these additional settings can be included in the DHCP answer to facilitate straightforward connectivity and name resolution.

WPAD configuration is currently provided in DHCP option 252.

The DHCP protocol is quite old (1993), and doesn't provide any relevant security. Requests are broadcast, can be relayed across subnets with DHCP relay and obviously anyone on a subnet who can answer more rapidly than the actual DHCP server can inject any network settings on the client who issued the DHCP request.

Spoofing DHCP challenges

Spoofing DHCP responses with no disruption can be challenging since you're interfering with a workstation network configuration. Usually, you need to have very good knowledge of the target subnet, where is the DNS server, where is the switch, routing table, domain, netmask, DHCP server, etc. Any mistake with these settings will result in disruption on the network.

 

However, spoofing DHCP answers has unique benefits. It's definitely stealthier than ARP poisoning; One unicast response is sufficient to permanently poison a victim's routing information, it's also common to see multiple DHCP servers operating on a network. Unicast DHCP answers are more complex to detect, a few switch provides security settings to prevent DHCP snooping, however those settings are not straightforward and are often misconfigured when enabled.

Responder approach

 Previous Responder version included a DHCP.py script in the tool folder. This script was not the easiest to operate and the fear of causing disruption on client networks made it a "last option" tool.

 

Responder 3.0.7.0 changed that and DHCP poisoning is completely automated and cause no disruption on the network.

To understand how Responder do that, you need to understand how DHCP works, 
A client performs a broadcast DHCP REQUEST when the workstation is restarted, when the network adapter is enabled or simply when the DHCP lease expires (usually a few hours), the DHCP server reply with a DHCP ACK answer containing all network settings and additional options.

Responder takes advantage of that and race against the legit DHCP server to answers with a DHCP ACK containing invalid network settings, a valid WPAD server (Responder IP) and a very short lease time (10 seconds).

 

The workstation gets the WPAD server injected and will issue a new DHCP request right after, Responder will let the legit DHCP server do its job and provide the right network settings. 

 

Due to Windows DHCP client design, an injected WPAD server is permanent until next reboot regardless if another DHCP server provides a new configuration :)

A maximum of 4 spoofing attempts by MAC address has been configured in the DHCP module, which should be more than enough to get the WPAD server injected.

 

How to run it:

The new DHCP module is disabled by default, you can enable it with the -d command line option.

When enabled, you need to edit Responder.conf and update the WPADScript setting:

WPADScript = function FindProxyForURL(url, host){if ((host == "localhost") || shExpMatch(host, "localhost.*") ||(host == "127.0.0.1") || isPlainHostName(host)) return "DIRECT"; if (dnsDomainIs(host, "ProxySrv")||shExpMatch(host, "(*.ProxySrv|ProxySrv)")) return "DIRECT"; return 'PROXY ProxySrv:3128; PROXY ProxySrv:3141; DIRECT';}

The text in bold should be replaced with your Responder IP address, because LLMNR/NBT-NS is likely disabled, so you want to avoid any lookups going unanswered and lose valuable NTLM hashes.

Wpad script configuration is automated, the next step is to launch Responder with the following arguments:

./Responder.py -I eth0 -rPdv

Why -P and not -F? Nowadays, WPAD NTLM authentication is unlikely successful, therefore forcing NTLM authentication on wpad.dat retrieval is not recommended. The concept is to serve the wpad.dat file with no user authentication, and as soon the client starts using our proxy, we force authentication with the Proxy-Auth module :)

When a WPAD server is injected, the user on the workstation doesn't need to open or do anything, NTLM hashes starts to flow in Responder automatically.

Final words

This Responder version is currently available for our sponsors on Porchetta Industries. 

This functionality will be released publicly for everyone else in a few months on github.

Porchetta Industries is a unique platform allowing tool makers to be sponsored for their work and tools they provides freely to the security community at large.

For more information, visit: https://porchetta.industries

 

 

Status of Submitted Vulnerabilities To MSRC

This list is intended to give vague information about submitted bugs, but important information about communication process and timeline.

Bug Title: Microsoft SMBv1 Disabled; Not Fully Disabled.

• Affected software: Microsoft Servers 2019, 2016, 2012.
• Type:Protocol Implementation Issue.
  
• Submitted: 07/04/2021
• Coordinated disclosure agreement expiration: 13/07/2021.
• Notes and updates:
  
  -Complete detail was sent on 07/04/2021, ACK by MSRC on 08/04/2021.
  
  - MSRC ask for PoC
  
  - PoC sent with extra details.
  
  - MSRC ask to extend deadline to 13/07/2021 instead of 07/07/2021 since their July release is the 13th.
  
  - Agreed to MSRC's request and offer to provide more details if needed.
  
  - Requested update to MSRC on 16/04/2021
  
  - MSRC responded the 19/04/2021 and asked what is the security issue with having NetBIOS enabled by default.
  
  - A complete description on why it is a security concern was sent the same day.
  
  -  on 21/04/2021 a status update was requested.
  
  - MSRC answer on May 7th, and asserts multiple falsehoods about the protocol in question, referring to MSFT documentation, and states that NTLM messages are safe even when intercepted. Additionally, MSRC mention that I'm allowed to blog/disclose this issue.
  
  - A lengthy factual answer is sent back on May 9th, detailing the incoherence in both MSRC answer and MSFT documentation. Especially when publicly available NT4/Windows XP source code directly contradicts the said MSFT documentation. MSRC was also asked to run MultiRelay in conjunction with Responder in an A-D lab environment, and confirm if NTLM message are really that safe when intercepted. A temporary hold on disclosure was offered until the said email is assessed.
  
  - MSRC answers on May 10th, stating that they will review the "added submissions".
  
  - On may 26th, MSRC responded stating that they finally understood the issue and will be working on a fix.
  

• *Check for more updates*.