Archive for the 'Web Application Security' Category
Tuesday, November 27th, 2007
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…).
Sunday, November 4th, 2007
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.
Friday, September 28th, 2007
All Your Google Docs are Belong To US…
It’s been a rough week for Google Security… It seems like everyone had some Google vulnerability they wanted to disclose this week. You can see some of the various vulns here, here, and here.
Well… the week isn’t over YET! I’m actually disclosing this vulnerability because Google has already fixed it. Although I don’t use Google Docs (because I’m a paranoid guy), I know a lot of people who do and I didn’t want to put their docs at risk. Without further delay, the details…
This vulnerability allowed any Google Docs user to STEAL ARBITRARY DOCUMENTS from the Google Docs Server. The basis of the vulnerability stems from a simple Session Management issue. Once a user has logged into Google Docs and has created a document, they are presented with several options. Under the “Share” tab, the user has an option to “Email Collaborators”
Once the user clicks the “Email Collaborators” link, the following HTTP GET request is made to docs.google.com:
GET /Dialogs/EmailDocument?DocID=<ANY DOC ID HERE> HTTP/1.1
<appropriate HTTP headers here>
If you changed the DocID value to another DocID, Google Docs WOULD NOT VALIDATE whether you should have access to that DocID. The title of the stolen document you requested will be shown (as a javascript variable) in the HTTP 200 OK response that is returned. Once this step is completed, you can make a POST request to a Google Docs Server Side Script named MiscCommands. The POST request looks something like this:
POST /MiscCommands HTTP/1.1
<appropriate HTTP headers here>
command=validate_address&docid=<ANY DOCID HERE>&addr=gmail%40gmail.com&finis=true&POST_TOKEN=POSTTOKENVALUE
If you changed the DocID in the POST request, the entire contents of that document would be emailed to the addresses specified in the “addr” parameter! I tested this against several friends Google Docs and it worked EVERYTIME!
This issue does stem on being able to predict the DocID for the document that you want to steal. At first glance, the DocID seems to be a fairly stout “random string”, but a little bit of analysis shows some interesting characteristics. It seems that the DocID is delimited by an “_” character. The characters preceding the underscore represent the Google Docs UserID. Each document uploaded to Google Docs by a particular user will have the same characters up to the underscore. Now… what about the characters after the underscore? Well… take a look at what happens when I generate 10 different DocIDs in rapid succession:
mydocsid_14ggbd48
mydocsid_15gt54pt
mydocsid_16c44jws
mydocsid_17cnnfw8
mydocsid_18ggzpm7
mydocsid_19dczf6g
mydocsid_20c8h7nx
mydocsid_21czqc3h
mydocsid_22d48w8j
mydocsid_23f4hk9b
mydocsid_24gdwfzk
Maybe the last set of characters isn’t as “random” as we thought…… Throw in some DocID enumeration (which exists) and we may be on to something here… I’ve seen Session Management issues like this in MANY of the web applications I’ve assessed. If your hired gun (webapp pentester) looks at you funny when you ask if they are testing for Session Management issues, FIND A NEW ONE! There isn’t a web app vulnerability scanner on the market that can detect this and Web App firewalls will not prevent this either! It takes an actual brain and some experience to find these types of issues!
In closing, I would like to give a shout to the Google Security Team. If you’ve ever dealt with the Google Security Team, you know that they take security seriously and they move fast…. VERY FAST. After giving them the details for a couple of Google vulnerabilities, it took Google ONE DAY to fix the issues and to deploy the fixes worldwide… Kudos to Chris and the GST.