Tuesday, November 27th, 2007
BK here… I’ve been on a little bit of a hiatus lately, but Nate has been holding down the fort with a couple posts here and there. I’ll post more about what I’ve been working on later but for now, I wanted to let everyone know that I had a pleasant surprise in my email inbox (besides the ads for cheap Viagra)… PORTSWIGGER put out a new BETA version of his Burp Suite!
Burp Suite is my favorite tool for web application assessments. If you haven’t played around with Burp Suite, you’re really missing out. I haven’t had a chance to play around with the new functionality, but I’m sure it will ROCK. I love the entire Burp Suite but there is one piece that’s my fav… and that’s Burp Intruder.
The attacks possible via the Intruder payloads make it a truly special tool, providing a capability that I have yet to see in any other web app testing tool (trust me… I’ve looked). Although the number of sweet findings made possible through the use of Intruder are too numerous to mention here, I’ll mention two that have a special place in my playbook:
1.) Error based SQL Injection leading to full exfiltration of an entire database: I was working on an engagement with Raghav “The Pope” Dube when we discovered SQL Injection. The injection point was nested DEEP inside a hideous SQL Query and there was just enough server side validation so we couldn’t comment or truncate the rest of the query out. We could however, see verbose error messages which revealed some of the database structure. We used Burp Intruder to send an HTTP request, receive the response, take a portion of the error message text (via regex) and use that text as the payload for the next HTTP request. Intruder looped through that sequence thousands of times, extracting DB information along the way. It took us about a minute to setup the regexes and about 10 minutes to pull the entire DB… We setup Intruder faster than we could have written a Perl Script! Intruder even organized the results for us!
2.) Race condition in a web sever module: I was running some Intruder queries against a web server and noticed that every HTTP response size was exactly the same; EXCEPT for one lonely response (sorting by HTTP response size is AWESOME). I examined the single request that caused the unique response size, reissued the request, and this time I had a HTTP response size that was back in line with the 1000s of other HTTP responses. Scratching my head, I decided to push up the thread count in Intruder and let loose against the web server… turns out, if I could make a request just before an authenticated user made a request, I could sneak my request in as “authenticated” and I could see that users info. After talking to the owner of the web app, we eventually discovered that it was a flaw in a Web Server Module and not the application! (Which reminds me… I need to report a race condition in a web server mod…).