Telling White Lies with Responder
A question that I receive often enough to include in this blog post is, "What fascinates you so much about cybersecurity?" While I can never come up with an excellent response at that moment, I think my fascination stems from what a joke that term is. Cybersecurity was never something that was planned. Computers were such an intricate advancement that nobody was worried about spoofing IP addresses or building in buffer protections; the engineers just wanted to get them working! Even today, many manufacturers are too worried about pushing products out the door to address the elephant in the room, which is security. This is the perfect time to shout out to all the Agile software teams. Thanks for my job security!
Jokes aside, cybersecurity truthfully has been an afterthought. Take a minute before we get into the meat and potatoes of this blog post to ponder this. Many computers operate purely on the honor system. When you decide that your roommate has had enough internet for the day and begin sending wireless de-authentication frames to their devices, their Xbox doesn't reply with "Hey, are you really the router?" This level of ask-and-you-shall-receive mentality makes me adore Responder as a tool suite.
Consider the following as an introductory crash course for those unfamiliar with Responder. Windows devices were designed to be used with many other Windows devices to communicate effectively, share resources, etc. To achieve this, Windows bakes in some additional networking protocols. While many of these protocols exist, today we'll be covering the infamous NetBIOS Name Service (NBT-NS), Multicast DNS (mDNS), and Link-Local Multicast Name Resolution (LLMNR) protocols. If all of these protocols sound like an off-branded DNS, good, that's because they are. Windows uses these protocols as a fallback when DNS can't help resolve a local service. Much like our example above regarding the de-authentication packets, these protocols are also unauthenticated (insert winky face here)!
Firing off Responder with nothing but the designated networking interface will allow an attacker to spoof the previously mentioned protocols. When a user attempts to resolve a local NetBIOS name that the network's local DNS cannot resolve, Responder will perform some malicious magic under the hood. I'll use my virtualized lab environment along with Wireshark to depict this scenario.
Attacker IP & MAC Address: 10.0.0.10, 08:00:27:13:F1:BE
Victim IP & MAC Address: 10.0.0.20, 08:00:27:71:51:DE
First, let's kick off Responder and monitor for new network traffic.
Immediately, our attacker machine sets the stage for its nefarious activity. Using the Internet Group Management Protocol (IGMP), our attacker joins the 224.0.0.251 and 224.0.0.252 multicast groups. Why is this important? mDNS and LLMNR use multicast routing so the client can request naming services. Since our attacker machine joined these multicast groups it will now receive the query traffic for further hacktivity. Using our victim machine, let's navigate to a non-existent share such as "\\WhitehatWays\test."
While not much has appeared to take place on our victim's screen, Wireshark tells a different story behind the scenes.
A page full of traffic isn't necessarily self-explanatory; let's break this traffic down. Our first packet captured shows that our victim machine made a NetBIOS Name Service request to the network's broadcast address querying for "WHITEHATWAYS." Subsequently, similar multicast queries can be seen coming from our victim machine. Each query request is met with a corresponding answer from Responder on our attacker machine, claiming that the requested share can be found at its IP address. Upon receiving these queries and wrongfully assuming they are trustworthy, our victim machine completes a 3-way handshake on port 445 (SMB) with the attacker machine. SMB authentication traffic begins to flow, prompting Responder to step in and beautifully display that data in our attacker machine's console.
If you have your hacker thinking cap on, your next question may be, "How often are my clients (or victims ;) ) navigating to non-existent shares?" The answer to that is, well, unknown. Legacy Windows machines may reach out to shares that don't exist constantly, an Administrator could fat-finger the name of a common share, etc. In some real-life scenarios, Responder used in this way may be less effective. Instead of relying on pure chance alone, it would be beneficial to manipulate a widely-used un-authenticated protocol. Sit back in your seat, fellow Whitehat. Responder has this one covered!
Before we discover which protocol we're referring to, you must understand the concept of the Web Proxy Auto-Discovery protocol- or WPAD for short. Often employed in insecure corporate networks, WPAD allows for central proxy configuration management. Most browsers reserve the ability to automatically update their proxy settings using WPAD. WPAD has a lot of strange nomenclatures that I won't cover in this blog post, but feel free to continue your learning here. (Wikipedia link!)
DHCP! Yes, DHCP is our mysterious, vulnerable protocol. Hosts requiring the assistance of a DHCP server will automatically be compromised by Responder injecting a false WPAD entry into their network configuration. What's better? Hosts already leased to an IP address will ultimately reach out within a pre-configured time to renew that lease. This makes Responder the world's most profitable waiting game. Once again, let's look at how this works under the hood with Wireshark. Let's set up Responder and get rolling, I'm excited to show you this!
With the -Pdv flags enabled, Responder will now, drum roll, please, respond to DHCP requests and inject the falsified WPAD record. Switching to a network that supports DHCP and issuing "ipconfig /release" and "ipconfig /renew" will allow us to realize this attack vector.
Attacker IP & MAC Address: 192.168.1.139, 08:00:27:13:F1:BE
Victim IP & MAC Address: 192.168.1.143, 08:00:27:71:51:DE
Similar to our last encounter with Responder, our attacker machine joined the same multicast groups upon initialization. Additionally, Responder is going to generate a DHCP Discovery request. Our attacker machine is already configured via DHCP; why would it need to generate a DHCP Discovery request? Great question! If Responder is to impersonate the local DHCP server, it must know the IP address of the local DHCP server. When Responder generates this DHCP Discovery request, the local DHCP server, often a router, will respond with a DHCP Offer response detailing the network's configuration. Responder now has all it needs to start poisoning local victims! Let's renew our lease on the victim machine and analyze the traffic.
Once again, let's break down this traffic. Firstly, we can see the DHCP Release packet generated by our "ipconfig /release" on the victim machine. This simulates what it will look like when a device's IP address lease expires in the wild. When the "ipconfig /renew" is executed, our victim machine uses its MAC address to broadcast a DHCP Discovery request. The exploit comes in the highlighted packet from "192.168.1.1" with a DHCP Offer. 192.168.1.1 is my home router. No communication between my attacker machine and my home router occurred, so how could my router be serving the malicious WPAD entry? Simple, Responder is spoofing my router's IP address! If you look closely, you'll see that the MAC address associated with this response from my "router" matches the MAC address of the attacker machine.
Now that the victim machine has taken the DHCP configuration from our attacker machine, we just have to wait until the victim machine makes a web request. Luckily for us, Windows is constantly making API requests!
The victim machine begins by GET'ing the malicious WPAD.dat configuration file. Upon applying this configuration and making an HTTP request, our attacker machine responds with "407 Unauthorized." This block requires that the victim machine authenticate via NTLM. To continue making the HTTP request, the victim machine authenticates to our attacker server, compromising its password hash. Let's check our console and see if we get a similar story!
Bingo!
Responder is a stellar security tool that can compromise Windows-based machines without the need for inherent vulnerabilities. This idea of ask-and-you-shall-receive vulnerabilities is everywhere! Reviewing the generated network traffic with Wireshark, we can see how simple it was to convince our victim machine to repeatedly hand over its password hash.
