Responder: Beyond WPAD

Penetration testing demands a diverse skill set to effectively navigate and defeat security controls within the evaluated environment. It’s a confluence of technical knowledge and familiarity with available tools to tactfully utilize these resources in a time efficient manner against a wide spectrum of potential targets. Knowing exactly what a given tool can do and how it works often leads to the discovery of new, novel uses. One such tool is Responder. 

Responder is a man-in-the-middle (MiTM) tool that exploits broadcast name resolution protocols. Broadcast protocols have historically been targeted in MiTM attacks, because they lack authorization checks to validate the origin of a packet. Responder specifically targets link local multicast name resolution (LLMNR) and NetBios name resolution (NBT-NS) protocols. LLMNR is derived from DNS protocol, and is intended to enable hosts on a local network to easily perform name resolution. NBT is technically an API, but is used by SMB protocol within Windows environments to resolve the IP address of named hosts within a domain. Responder is effectively preying on a race condition to exploit these protocols. If the attacker system running Responder can respond to a broadcast name resolution request before any other system, then the response is poisoned and traffic from the victim host can now be sniffed. 

WPAD

One of the most common uses for Responder is to exploit a default configuration setting on Window systems called Windows Proxy Automatic Detection (WPAD). WPAD is a protocol that probes for a WPAD server hosting a proxy configuration file at the DNS address “wpad.domain.com”. In most organizations a WPAD host does not exist. When a DNS request for the IP of “wpad.domain.com” is sent to the domain controller, no DNS record is returned. On Windows systems, if a DNS request fails to resolve to an IP lower level protocols are automatically attempted by the OS that include NBT-NS and LLMNR.  In the “WireShark” network sniffer output below, you can see the WPAD “NetBios” requests being sent out by a VM with the default auto proxy setting.

These conditions set a fertile stage for MiTM attacks using Responder. Poisoning the name resolution response is just one of the clever tricks going on in the background as the tool runs. Once a poisoned response has been received by the victim, the system attempts to connect to a Responder HTTP server and download a file called “wpad.dat”. When this happens, Responder prompts the victim host for NTLM credentials, which are then sent transparently to the attacker, as demonstrated  in the figure below.

Using a cracking tool such as “Hashcat”, it is then possible to resolve the NetNTLMv2 hash to a clear-text password. While this attack method remains functional, it’s less common to find hosts afflicted by the insecure default settings. This can be attributed to Microsoft security update MS16-077 that changed a number of default settings to a more secure state. Most significantly the update limited WPAD name resolution to DNS and disabled auto login to proxy servers that prompted for authentication. Despite the release of this patch in 2016, WPAD NBT-NS and LLMNR name requests can still be observed in most large corporate network environments. 

Exploiting WPAD and more broadly broadcast name resolution protocols has its clear adversarial advantages, but this is one of the most basic use cases for Responder. One of the critical aspects of the attack is that Windows systems can be compelled to transparently send NTLM credentials to untrusted systems. This does not require a man-in-the-middle condition, and can work across the Internet. 

To evolve the utility of this attack technique we must consider out-of-band methods through which a Windows host can be maliciously forced to interact with an arbitrary server across the Internet. 

Retrieve Database Passwords via Stacked Query SQL Injection 

Web applications are common targets during a penetration assessment, especially first-party web applications resident in corporate networks. One of the more serious vulnerabilities to impact web applications is SQL injection. Assuming you identify an application prone to a specific variant of SQL injection, called stacked query execution, it’s possible to execute stored procedures and functions against the database. The most common method to obtain database credentials via SQL injection is to access tables within the database itself. However, this requires elevated privileges, which are often not granted to services supporting web applications. 

Microsoft SQL Server has functions that allow limited file system interactions, which includes “xp_fileexist”. This function accepts a file path as an argument, and returns true (1) or false (0) if the file exists. Leveraging this function call it’s possible to bypass permissions restrictions and use Responder to hijack the NetNTLMv2 hash of the database service used by the vulnerable web application. 

In this example a Responder server is hosted at IP 10.200.32.6, and the database server is hosted at IP address 10.100.75.119. For the purpose of this example a database client is being used to execute the “xp_fileexist” stored procedure, however the principal is directly applicable to stacked query SQL injection. The trick to this particular attack is to get the database server to access an SMB resource instead of a local file path. On Windows hosts, SMB resources can be accessed by prepending double forward slashes to an IP address, ex “\\192.168.0.1”. This intrinsic behavior of Windows makes accessing SMB resources ubiquitous throughout the OS. By leveraging this behavior, it’s then possible to force the database server to connect to an untrusted SMB server. When the database server attempts to establish a connection with the Responder SMB server, the victim transparently passes along NTLM credentials. The figure below demonstrates the execution of the stored procedure.

 

On the Responder server, the execution of the stored procedure resulted in an intercepted NetNTLMv2 hash, as demonstrated in the figure below. 

 

Using this attack technique, the intercepted hash can be relayed to hosts that lack the protection of SMB signing or cracked offline using a utility such as Hashcat. 

Cross-site Scripting and HTML

Building off the behavior of Windows to implicitly trust SMB servers, it’s possible to craft a very simple cross-site scripting (XSS) payload that steals domain credentials. XSS is a class of injection vulnerability that enables an attacker to reflectively or persistently execute remote commands or render malicious HTML within the browser of the target victim. XSS can be exploited to accomplish a wide range of sophisticated attacks, including system compromise. However, injecting cross-site scripts as simple as an HTML IMG tag can result in credential theft on Windows systems. There are two easy ways to stage this type of attack. Either inject an IMG tag as an XSS payload or via JavaScript using “document.location” to redirect the victim to an attacker-controlled HTTP server that hosts a malicious HTML page. For our purposes, a very simple HTML page was created and hosted using a Python “SimpleHTTPServer”, as demonstrated in the figures below.

 

Using this attack harness when the malicious HTML page is visited from a Windows system, the domain credentials of the authenticated victim are transparently sent to the Responder server, as demonstrated in the figure below.

The simplicity of this attack makes it incredibly useful across a range of vectors. A malicious IMG tag can be embedded into phishing emails or it can be included in WiFi hijacking attacks through a malicious captive portal, all of which can result in transparent credential theft. Once captured, hashes can be cracked or relayed using tools such as NTLMRelayx.py to authenticate to other systems within internal network environments. Although these conditions are not guaranteed to manifest on every engagement, it’s helpful to be familiar with the utility of Responder in various offense security engagements and attack scenarios. 

 

References: 

https://support.microsoft.com/en-us/help/3165191/ms16-077-security-update-for-wpad-june-14-2016