Archive for the 'Web Application Security' Category
Tuesday, January 8th, 2008
There’s an OAK TREE in my blog!?!?!
A while back I came across another interesting issue that allowed me to steal an arbitrary Google Doc (assuming I knew the DocID). This issue has already been fixed by Google, but the details are pretty interesting so I thought I would share! Now, before I get into the gory details, I’d like to mention two things about Google:
- I know some people have had issues with Google’s Security Team (GST), but I’ve always had pleasant experiences with them. GST moves with LIGHTING speed and they are usually great about keeping in me apprised of the status of various issues I’ve reported to them.
- In addition to fixing this particular exposure, GST has also increased the entropy of the DocID making sploits based on DocID guessing totally impractical. It’s a great example of going the extra step to help protect users…
Now… the gory details… First, I went to Wordpress.com and created a new blog (there were other ways to pull this off, but this was the easiest way). Once the blog was created, I logged into Google Docs with my account, created a document and selected the “publish this document” option. Once in the “publish” menu, I selected the “Blog Site Settings” option. This option basically allows a Google Docs user to create a document in Google Docs and POST it directly to thier blog! I entered my blog provider, blog username, and blog password into the blog settings page. The page is shown below:
Once my blog settings were properly entered, I selected the “Publish This Document To Your Blog” option. The POST request made by my browser looked something like this:
POST /MiscCommands HTTP/1.1
<HTTP HEADERS>command=cmdvalue&localDate=datevalue&docID=doc-id-here&finis=finisvalue&POST_TOKEN=posttokenvalue
When this feature is selected, it appears that the Google Docs server makes a request to the xmlrpc.php file on the blog server (Wordpress.com), passing the credentials I gave in the blog settings. When the blog server indicates that the blog creds were valid, the Google Docs server sends the contents of the Google Doc to the blog server. hmmmm… that docID value looks reeeallly interesting… I changed the docID in the POST request from the docID of my newly created document to the docID of the “Article For Oak Tree View” (the document used by Google to Demo Google Docs).
After changing the docID and sending the POST request, I logged into my Wordpress Blog and LO AND BEHOLD… my first blog POST was the Oak Tree Newsletter!
I tried it on some friends documents with the same result and then contacted the GST….
Links to other Google Docs Stuff here, here, and here
Monday, December 24th, 2007
Happy Holidays!
Merry Christmas and a Happy New Year to all!
It’s been awhile since Billy or I have posted, as we’ve been busy enjoying the holidays, but rest assured, we’re still working hard. 2007 has been a great year for Billy and I, hopefully we can continue the pace in 2008. I know Billy has several posts to catch up on, and I personally can’t wait to see all the details! In the meantime, I thought I’d update everyone on the research I’ve been doing with URI Handlers on the Mac operating system.
As some of you know, I recently purchased a brand new Mac Book for Christmas. I did some research into how the Mac handles its URI handlers and discovered that URI flaws are not new on the Mac! To my surprise, URI issues have been one of the major plagues of the Mac operating system for some time. The Month of Apple Bugs, from back in January 2007, clearly illustrates several major flaws on the Mac with regards to URI Handling issues. Additionally, Daring Fireball’s site, discusses the issue as far back as 2004.
Well, this peaked my curiosity, so I had to take a deeper look. I found an application called RCDefaultApp, which was developed by Carl E. Lindberg, which gives a graphical representation of URL Handlers (amongst other things) on a Mac. Carl was nice enough to write up some command-line code for me to dump out the URL Handlers. I had expected to modify it up to do exactly what I wanted, but at this time, I’ve just been to busy. In the meantime, the current code can be found here.
This code actually led to the discovery of a new URL Handling bug on the Mac OS X in the most current and patched Leopard version. At this time, I’ve notified Apple, and they expect to have a bug fix out in January, so I will release details at that time. Apple has been great in responding to this issue, and I thank them for working with me on it.
Thanks and Merry Christmas!
-Nate
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…).