New Burp Suite (Beta) Out!

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...).

Hello and Happy Thanksgiving!

  

Hopefully your holiday was as good as mine. This year I was fortunate enough to get an early Christmas present in the form of a new MacBook to continue our research. I'm happy to say that URI issues do exist on Mac's! More importantly I'm really close to releasing DUH4Mac. It'd be done by now, but a deadly combination of turkey, beer, and great football games all weekend have slowed my progress and nearly put me into a coma.

  

Also, for those who haven't read it yet, Billy and I were asked to write a guest editorial for Ryan Naraine's Zero Day Blog. Go read it if you get a chance! I'd like to thank Ryan for supporting and publicizing our research and asking Billy and I to pull together a guest editorial for his site, it was a huge honor.

Java Applets and DNS Rebinding

For those of you who were able to see Billy and I present at Hack In the Box Malaysia this year, you already know that Java Applets were vulnerable to DNS Rebinding attacks. For the benefit of those of you who didn't get to see that presentation, here's a link to it, but the simple of it is that we can XSS a victim, force a Java applet to be cached and then DNS Rebind that applet by reloading the JVM or loading a new JVM after we have modified the DNS entry for the name of the host the applet was served from. This is because, as many things on the Internet, applets are pinned to DNS name as opposed to IP address.


  
Why do we care? Well, unlike DNS pinning with Flash sockets, we can actually make request to ports less than 1024 and additionally, Java provides us with a huge set of libraries for doing everything from communicating with database servers to communicating with RMI servers.


  
Interestingly enough, a recent post by the NGS guys that was on seclists detailed how this was vulnerable in another way, which appeared to not have to rely on a new load of the JVM. Here's a comment from that post:


  

By specifying a codebase URI prefixed by "verbatim:" it is possible to
load an applet from a remote location but have the browser plugin believe
it has been loaded from the local host. This allows an untrusted applet
to connect to and attempt to exploit network services running on the local
host. It should be noted that unlike binary sockets in Flash 9, an applet
can connect to any port, not just those greater than 1024.


  
At the time of reporting this issue, NGS provided Sun with a demonstration
applet that exploited MS06-040 ("Vulnerability in Server Service could
allow remote code execution") on a vulnerable XP SP1 system.

  
Fortunately for all of us who have Java installed on our systems, this has now been patched by Sun, but I find it interesting that Java has its own URIs that it respects, like the verbatim: URI. Very interesting indeed.