Pentest Diaries – Hunting Bugs in HTTP Headers

Some time ago, I joined a bug bounty program of a household name brand, who shall remain anonymous throughout this article. This write-up documents a journey of finding and exploiting SQL injection in some unexpected places.

To get started, I randomly chose one of the 47 domains which were in scope and decided to perform a manual crawl by navigating to it in a browser. Strangely, the target I chose was throwing a 404 (not found) HTTP error on the root of the page. Therefore, in order to get something to test, I ran a few Google Hacking Database (GHDB) style queries to have some pages I can work with.

The first thing I did was to gather as much information as I could about the website’s technology stack, including what OS (Windows, Linux, UNIX…) it’s running and what server side technology (PHP, ASP.NET, J2EE, Python…) it’s using. After some time interacting with the web app, I found it to be mostly static, and while it had some functionality, this functionality was rather limited. Therefore, I chose to skip testing for logical bugs and instead focused on injection. I mapped out HTTP methods accepted by the web application together with potential injection points where I was likely to find injection bugs.

Things however, turned out harder than they seemed and after some 2 hours of manual testing with nothing to show for it, things started to get frustrating. So I decided to give Acunetix a try. Since I was exclusively interested in injection vulnerabilities, I created a custom Scan Type that focused only on injection bugs. The limited scope helps make the scan quicker and more importantly in this case, it puts less load on the application.

Additionally, since I had already done a lot of manual work in Telerik Fiddler, I could save its output to a .saz and feed it to Acunetix. It’s also worth mentioning that Acunetix also supports PortSwigger Burp Suite .xml and any tool that can output a .har file. This functionality is super useful during a pen-test because it means you’re free to use the tools you’re already comfortable with.

In this case, providing the scanner with a manually crawled structure was necessary since the root page was returning a 404 — therefore, in this case, running a scan on the root of the site would have probably not gotten me very far.

I left the scan running for a few minutes and when I came back to it, to my surprise there was a Blind SQL Injection alert. Upon opening the alert, things got even more surprising — the injection resided in the User-Agent HTTP Header.

This was a nice find, however, I wanted to confirm this was a true-positive before reporting it. To do so, I copied over the HTTP request from Acunetix and pasted it in Telerik Fiddler’s Composer, but again, I could have used any other tool that can craft HTTP requests.

As part of the result for Blind SQL Injection vulnerabilities, Acunetix will not only give you the HTTP request it used, but because it uses a number of requests to verify Blind SQLi (necessary due to the nature of timing attacks), it also gives you a list of the tests it performed. This provided me with a good place to start.

I tested a few Blind SQL Injection payloads and verified that what Acunetix found was indeed a true positive, and with that, I could go ahead and report this Blind SQL Injection bug.

THE AUTHOR

Raghav Bisht

Experienced Security Researcher with a demonstrated history of working in the information technology and services industry. Skilled in Python, Perl, Vulnerability Assessments & Penetration Testing , PHP, Cyber Security Intelligence and OSINT.