Using Burp Proxy to Troubleshoot Web Exploits

When running web exploits against a target, there are times where the exploit may fail to work and the output from the terminal may not give a descriptive error as to what the issue may be. The Burp Suite proxy can be used to troubleshoot why the exploit may not be working by running the exploit through a proxy. This will allow you to view the requests and responses that are sent/received when running the exploit. The benefit is that this will work even if the exploit does not provide a command-line option to specify a proxy. In addition to troubleshooting web exploits, another benefit of running exploits through the Burp proxy is that it enables you to log all the requests/responses you have sent/received, which helps keep track of the actions you have performed during a pentest. This demonstration will show you how to run the time_blind_sqli.sh script through the Burp proxy. The time_blind_sqli.sh script will be run against DVWA to exploit a blind SQL injection vulnerability in the id GET parameter and requires that the user is authenticated. We start by running the below command:

The output of the script indicates that there are no results, but we are certain that it should work as the id GET parameter is vulnerable.

Configuring Proxy Listener

Let’s create a new proxy listener in Burp that redirects to DVWA:

• In Burp, go to Proxy > Options > Proxy Listeners > Add > Binding and set ‘Bind to port’ to 8081

• Select the ‘Request handling’ tab:
  • Set ‘Redirect to host’ to the IP address of your target (in my case 192.168.56.101)
  • Set ‘Redirect to port’ to 80 (443 if the target is using HTTPS) and click OK

• Also, make sure that the Burp proxy interceptor is off under Proxy > Intercept

Running Exploit via Burp Proxy

Let’s rerun the time_blind_sqli.sh script, this time replacing the hostname with the Burp proxy host and port we configured above, which will run the script through the Burp proxy:

In Burp, navigating to Proxy > HTTP history displays all the requests/responses that have been sent/received by the script. Looking at the response in the below screenshot indicates an HTTP redirect (302 Found) to the ../../login.php page, which indicates that we must be authenticated for the exploit to work.

Informed by the above information, we would then log into DVWA and use Burp to intercept the request and obtain the cookie. Rerunning the time_blind_sqli.sh script using the cookie (with security=low) results in the successful extraction of the current database:

By using the Burp proxy, we were able to troubleshoot the time_blind_sqli.sh script and identify that the issue was due to a missing cookie.

tags: burp suite oscp penetration testing