Exploiting WPAD with Burp Suite and the “HTTP Injector” extension
I went last week to the ASFWS conference (“Application Security Forum – Western Switzerland”) at Yverdon-les-Bains (CH). This small event (~ 100 attendees) was very well run and offered a diverse set of activities:
– training sessions with top-notch instructors like JP “@veorq” Aumasson
– rump sessions (including unpatched vulnerabilities!) and hands-on labs
– live hacks (the SMS board setup by a sponsor was probably not designed to display kittens 😉
– conferences by people from Facebook, SCRT, Cryptocat, … (slides should be online soon)
I was invited there to give talk about Burp Suite. The organization committee saw my previous HackInParis talk, and they were expecting something more practical. So I kept only two scenarios and went through them with a lot of gory details. The scenarios were MITM’ing clients using WPAD and brute-forcing a CSRF-protected form with short-lived sessions. This blog-post will introduce the WPAD part, including the “HTTP Injector” extension I developed. This extension to Burp Suite selectively modifies responses and is configurable enough to be usable in a lot of different MITM attacks. Let’s dive into the attack setup!
First things first, a network-listening proxy is needed. This is trivial to configure but a few specific options are needed (in “Proxy / Options”) if the attacker needs to be stealthy:
– check “Disable web interface at http://burp” and “Suppress Burp error messages”
– add an empty “SSL Pass Through” entry in order to not break any SSL session
Now, redirect Web traffic to your Burp listener, for example using SpiderLabs Responder. Please note that Responder is designed to serve a “wpad.dat” file only if the “WPAD proxy” option is set. In order to use Burp Suite as the WPAD proxy, delete line 897 where ServeWPADOrNot(WPAD_On_Off) is checked and use the following command-line:
sudo python ./Responder.py -i YOUR_IP -s On -w Off -D Off -L Off -F Off -q Off --ssl Off -S Off
Clients (browsers, RSS readers, updaters, anti virus, …) configured for WPAD will start using your proxy (listening on TCP/3141) for HTTP and HTTPS. Of course, given we configured a global “SSL Pass Through” entry, only HTTP will be visible. Keep this setting unless you’re OK with displaying tons of scary messages to SSL users. By the way, if you wonder what “configured for WPAD” means, it’s just a simple check box you probably already met:
HTTP traffic is now visible in “Proxy / History” and “Target / Site map”. An attacker can now conduct passive attacks (like obtaining credentials or cookies) using the “Search” and “Analyze target” features available in “Engagements tools” (Control-A + right-click in “Site map”). A few active attacks are also available by default in Burp Suite, like “SSL Stripping” and redirecting to a malicious server. But there’s a lot more tricks we may want to play: modifying links to executables on trusted sites, inserting invisible images stored on a SMB share in order to capture hashes, adding some BeEF JavaScript code or inserting an iframe pointing to a Metasploit autopwn page.
For all these active attacks, we need to apply some (not so) complex manipulations to selected responses. Given Burp Suite is lacking this kind of functionality, I developed the HTTP Injector extension. This extension will “infect” pages matching some criteria:
– is the response of type HTML?
– is the response in scope (as defined in Burp Suite)?
– is a specific string present?
– is the client already infected?
There’s four ways to define what is an already infected client:
– mode 0: do not manage duplicates, infect every page (if MIME type and scope are OK, of course)
– mode 1: one infection by source IP, useful when deploying client-side attacks (Metasploit, image stored on a SMB share)
– mode 2: one infection by source IP and service (tuple protocol+host+port), useful when using BeEF
– mode 3: one infection by source IP and URL (including GET parameters), useful when injecting FireBug Lite in a dumb browser
The extension will print its configuration and detailed information in its own window. Additionally, infected pages are tagged and colorized, as visible in “Proxy / History”. In the next screenshots, the victim (IP 192.168.2.63) is browsing http://www.laposte.net/ (a French webmail) and an invisible image pointing to a SMB server (IP 192.168.2.66) is inserted just before the