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

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.

Hey all, Nate here...


  
In the last two weeks we got the opportunity to speak at both ToorCon and Black Hat Japan. What an awesome experience! Rob Carter and I spoke about the research that our URI Use and Abuse research, including giving video demonstration of all of our exploits. Unfortunately, Billy couldn't join up with us for the talks due to some other commitments, but he did manage to come out to Japan and got to hang out with us in Tokyo. Rob and I also discussed the future of URI use and abuse and where it is going next... *Nix... and Mac! Just wait till I buy my Mac Book and iPhone!


  
At ToorCon, Rob and I got to catch up with former co-worker Brett Hardin and had a great time hanging out with him in the Gas Lamp district. We also met Dan Kaminsky and had a chance to talk with him about research and share some Jager Bombs. The weather was amazing, and we were fortunate enough to fly out of San Diego right before the fires started coming. If you saw us present, I recommend you check out our Black Hat presentation below, which is the full version of our research. A lot of things had to be cut out for the 20 minute time slot we were alloted for speaking at ToorCon.


  
At Black Hat, Billy, Rob, and I hung out all week with Jeff Moss, Dominic, and the Black Hat Crew who treated us like kings, and got a chance to meet such industry renowned researchers as Billy Hoffman, Halvar Flake, and Kanatoko-san just to name a few. Tokyo was a stunning city, I've never seen anything quite like it, just skyscrapers for as far as the eye can see. We had a great time in Tokyo, and our presentation seemed to go very well. It was awesome trading war stories with Dom, Moss, Kanatoko-san, Hoffman, and all the speakers.


  
As promised to all in attendance at our talks, here is the source code to our DUH tools for both Windows and *Nix. In order to use these files, simply rename them to either .bat or .sh, then run them from the command line using either cscript.exe or /bin/sh. Thanks again and as always to Erik Cabetas for the help with DUH 4 Windows! See the Black Hat page in the coming weeks for our video demos, as these are not likely to work from the powerpoint slides. Our updated slides can be downloaded from here.


  
-Nate, Billy, Rob

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.

Google Docs puts Google Users at Risk

The whole concept of "Taking Ownership" of someone else's content can be VERY dangerous.  The reason taking ownership of content is so scary is because the ENTIRE trust model for the World Wide Web is basically built on ONE thing... the DOMAIN NAME.

   

This is why issues like XSS on sites like google.com are such a big deal... XSS basically allows an attacker to execute client side code in the context of the vulnerable domain.  Malicious client side script is one thing... but malicious client side script executed in the context of a trusted domain is something entirely different... but I digress...

   

Google Documents basically allows you to upload your documents (aka content) to a Google server.  Once you've uploaded the document, Google has essentially "taken ownership" of the document (content).  There are ways to minimize the risks associated with taking ownership of content and it seems that Google has taken some measures to sanitize for XSS... but it seems that their focus on XSS may have caused them to miss a different type of cross domain exposure.

   

Flash Players (>7.0.19.0) support a new method for making cross domain requests.  This method allows a user (or attacker) to specify where a crossdomain.xml file is located on a particular server.  Essentially, if the flash player finds this crossdomain file (and the file is properly formatted) the flash player will allow cross domain requests to the domain that "owns" the crossdomain policy file, in this case... Google.com.   We talked about issues like this at our DEFCON talk.... but I guess Google missed out.

   

So, the Proof of Concept works like this:

1. NO XSS IS REQUIRED!


2. Create a Google Docs Account and upload a properly formatted Crossdomain.xml file


3. Once the file is uploaded, you publish the file, exposing the file to every authenticated Google.com user.


4. Create a flash object on a malicious server, pointing the System.security.loadPolicyFile() to the document that you uploaded to Google Docs.


5. Once the Flash object has read the contents of the crossdomain file from the Google server, it assumes that Google has allowed cross domain requests (I mean… who in their right mind would allow random people to upload random files to thier server and serve that content under the context of their trusted domain name?).


6. Now, the flash object has full access to the google.com domain and can steal all your Google information.

   

Proof of Concept can be found here.  The PoC just displays your contact list, but I have full access to the Google.com domain, so the sky is the limit (aka I can read all your email too)... I left out one key step needed to pull this off and the source for the Flash applet will not be published at this time in order to slow the kiddies. 

     

If anyone from Google Security comes across this page, send me an email and we can go over the missing step as well as the Flash Source... I'd also like to talk to you about another hole in Google Docs that allows me to ACCESS ANY ARBITRARY USERS DOCUMENTS.

Stealing Pictures with Picasa

In celebration of our acceptance to Black Hat Japan, we've decided to post the details on our Picasa exploit which allows an attacker to steal images from victims.  Perhaps this should be the month of Google flaws considering our posts in this previous week and some of the posts that are on their way in the next week or two.

   

If you've read our previous post Say Cheese! then you know that Google's Picasa registers the picasa:// URI in the Windows registry and it is possible to abuse this registered URI through a Cross-Site Scripting exposure to steal a victim's images.  My personal feeling on this issue is that it represents a HUGE privacy breach for users of Picasa. Ok, so without further dramatic build-up, you can find the gory details here and you can find the source code we use for the exploit here.

BK for Mayor of Oak Tree View

I’m excited about Google Docs.... although there is NO WAY you could convince me to upload my sensitive documents to a Google Server, I’m still very interested in seeing how Google’s Engineers tackle the security issues with online document sharing.  Security for online collaboration tools is TOUGH, every online collaboration tool I’ve ever assessed has had major issues. 

    
So I made my way to docs.google.com to see what the hype is all about.  I found the link for “Watch a Video” on the login page.  I like Google’s videos and this one did not disappoint.  About half way through the video (1:60), I saw something that made me put my beer down… a link to a Google Document.

   



   

Being the curious sort, I entered the link into my browser address bar.  I was surprised to see the following document:

   



    

Now, being able to view someone else’s document is pretty bad… but this is a demo… maybe they WANT everyone to see this document… that’s understandable.  So what happened next REALLY surprised me…  I clicked on the “Edit this page” link, entered my creds… and lo and behold…  I had full rights to edit/modify the Oak Tree View newsletter! 

   



      

I was planning on using the Oak Tree View newsletter to launch my campaign for Mayor of Oak Tree View, but I decided against modifying the page, as I’m not interested in pwning Sam’s pretty little newsletter.  I’m sure she’s not interested in what I have to say about Oak Tree View….

 

The Old Dog and his Old Tricks (Part I)

Lets say I found a CSRF that allows me to hijack your Gmail account to send an email from you to another Gmail user... would you consider it a risk?  Well, the good news is I don't have a CSRF to send out email from your Gmail account, but the bad news is I don't need CSRF (or any other exploit) to send an email from your Gmail account.

    
Using Google's SMTP servers, I can send an email from any Gmail (or @google.com) account to any other Gmail email address.  The process is simple... and is shown in the images below (addresses masked to slow the kiddies).



   

This is NOT a vulnerability in Google's infrastructure... it's merely how SMTP was DESIGNED to work.  This same procedure works on other SMTP servers as well.  Many of the old protocols (like SMTP) that we continue to use everyday are inherently insecure.  My favorites are DNS, SMTP, and ARP.  Many of the exploits based on these protocols aren't really even exploits... they are simply an abuse of functionality intentionally built into the protocol!

    

How could we let things get so bad?  Why should I be ALLOWED to send an email on your behalf, sending colorful messages to other Gmail users?  Honestly....  I don't know... what I do know... is instead of fixing the underlying protocol (which is painful, costly, and resource intensive) we've "bolted on" temporary fixes like spam filters to help us "fix" the issues with the underlying protocol.  After a while... we get used to having these "bolt on" and the temporary fixes become permanent fixes and the underlying protocol remains vulnerable to simple attacks like this one.

    

I know what you're saying.... "SMTP was created in the wild wild west... times have changed... that will NEVER happen again!"  The sad thing is... we're starting to see the same things happening to HTTP.  Just as SMTP Admins have turned to Spam filters and other appliances to make up for the shortcomings of SMTP, we are now seeing that many are turning to Application Firewalls to make up for the shortcomings of HTTP and poor coding practices.  There are some that claim that application firewalls are a great "temporary fix", and they probably they are!  Just as Spam filters were a temporary fix for SMTP abuses!

      

HITB 2007!

I'm back from HITB in Malaysia!  HITB was held in Kuala Lumpur, Malaysia from September 3rd - 6th.  The conference was AWESOME.  Dhillon really out did himself this year.  The talks were awesome and the company was second to none.  You can find the slides for all the talks (including our slides on DNS rebinding with Java Applets) here.  Dhillon will be posting links to the VIDEOS in December!

   

It was a truly amazing experience to sit down and have a beer (or two) with the likes of Phiber Optik, Emmanuel Goldstein, Window Snyder, Andrew Cushman, Mikko, Lance Spitzner, fx and many many others.   

   
All the talks I attended were great, but I particularly enjoyed:

• Rise and Fall of Info Sec in the Western World - Phiber Optik - Listening to Phiber Optik talk about pwning a major corporation live for the audience during conference he was speaking at was sweet. 

• The Evolution of Hacking - Emmanuel Goldstein - Listening to some old skool hacks is always fun and brings back memories of 300 baud modems and wildcat bbses...

• SCADA (in)Security - Raoul and Alessio - I'm EXTEMELY interested in SCADA systems and the security surrounding them.  There are basically a handful of SCADA security experts around the world and Raoul and Alessio are two of the best.

• Exploiting the Intranet with a Webpage - Martin Johns - It was nice to hear about DNS rebinding from the guy who basically brought DNS rebinding back from dead!

• Locks, Lies, and Liability - Mark Tobias and the TOOOL USA - Watching these guys pick apart "high security" locks was pretty scary... especially when I saw a few locks we used in the Marine Corps in the speaker slides!

• Online Crime and Crime online - Mikko Hypponen - It seems that Mikko is VERY well connected to the underground.  Not only did he describe (in crystal clear detail) how the general Internet population is getting pwnd, he showed exactly where all the action is taking place!

During our talk, we mentioned that we would post the details of a recent Picasa URI vulnerability (which will be patched in next version of Picasa).  We'll have the details, screenshots, and a dedicated POST up in a few days.

  

In closing, I would like to thank Dhillon for inviting me out to HITB 2007 and the wonderful country of Malaysia.  It was an amazing experience and everyone (including the street vendors in China Town) were such gracious hosts!

Firefox File Handling Woes

It seems recent URI remote command execution bugs in Firefox have long been forgotten.  Mozilla put out a patch in a lighting fast manner, probably spurring on bravado like the “10 Fucking Days!” claim overheard at Black hat USA.  Let’s take a closer look at the vulnerability, starting with an interesting piece of the description provided in MFSA2007-27: 

   

“…Further investigation by Secunia showed that a % not followed by a valid two-digit hexadecimal number also triggered the problem for the affected protocols. The Firefox and Thunderbird 2.0.0.6 releases contain fixes that prevent the original demonstrations of this variant, but it is still possible to launch a file type handler based on extension rather than the registered protocol handler. A way to exploit a common handler with a single unexpected URI as an argument may yet be found. Since this handling is a property of the Windows Shell API this variant appears to affect other internet-enabled applications that pass these URIs to the Windows Shell.”

   
   Well, to make a long story short, Nate and I have discovered a way to “…exploit a common handler with a single unexpected URI…”  Once again, these URI payloads can be passed by the mailto, nntp, news, and snews URIs, allowing us to pass the payload without any user interaction.  So, it seems that although the conditions which allowed for remote command execution in Firefox 2.0.0.5 have been addressed with a security patch, the underlying file type handling issues which are truly the heart of the issue have NOT been addressed.    

    

    We contacted Mozilla a while ago about the issue and they are working on it.  We’re going to refrain from giving out the exact details of how this particular issue is executed (based mainly on the efforts and conversations we’ve had with Jesse Ruderman), but we’ll include a screenshot of a payload in action.  In the screenshot below, we use the mailto URI, which passes the URI to the Windows File Handler, which calls the appropriate program (in this case Windows Scripting Host), which in turn calls our attacker controlled file.  We’ve purposely pointed the Windows Scripting Host to a file that doesn’t exist as the error message allows the user to see that WSH is using the URI passed from Firefox.   

Say Cheeeeeese!

We’ve received a lot of email about the recent Slashdot article, which spoke about additional URI vulnerabilities discovered by Nate and I.  Most of the emails ask why we haven’t posted the details of the flaw… well, today is your lucky day… kinda…While we’re not going to post the exact details of the vulnerability until Google has had some time to fix the issues (they have been contacted), we will give you a high level summary of the issue.

   

This particular issue involves Google’s Picasa.  As you probably know, Picasa is used to organize and touch up photos by adding various effects.  What you probably didn’t know is… Picasa registers a URI (picasa://) in the Windows registry.  This URI is used to extend the functionality of Picasa in many ways and it’s this functionality that we are abusing.  By abusing the registered URI, it is possible to steal the images that have been loaded into Picasa.  For some this may not be a big deal… but for others, this may represent a HUGE privacy risk.  From a security researcher standpoint, this vulnerability is unique in that it doesn’t require ANY restricted characters to be passed in the URI.  This makes it virtually impossible for a browser to filter the URI to prevent this attack.  In fact, if the browser did somehow stop this attack, it would probably break this particular piece of functionality offered by Picasa (albeit it is really insecure functionality and should probably be removed anyway)!

  

Nate and I have become extremely interested in what we call “Functionality based URI exploitation”, which involves abusing the functionality intentionally placed within software that is made remotely accessible through registered URIs.  These vulnerabilities are nearly impossible to detect through automated tools and typically require an experienced blackbox effort, as most of the functionality offered by registered URIs is poorly documented and the software is typically closed source.  We’re ALWAYS up for the challenge though… 

   

If functionality based URI exploitation isn’t your cup of tea… you’ll probably be happy to know that Picasa also has some overflow and “cross application scripting” issues as well… These issues are VERY serious as well, but we found the functionality abuse especially interesting.

   

On a final note, I wanted to personally thank Rob Carter for all his work on this issue.  While Nate and I put the attack together from a conceptual standpoint and provided the foundation for the attack, Rob was the guy who basically wrote the code to make this vulnerability “real”.  The attack is fairly complicated but Rob has a solid understand of each step and it shows in the PoC!  THANKS ROB!

Dude... where's my passport?!?!

The XS-Snipers are ready to roll to Malaysia.  We'll be presenting at HITB 2007 on the 6th of September.  Our talk will be on some new DNS Rebinding attacks that are pretty legit.  It will be nice to finally meet Martin Johns (the guy who basically brought DNS Rebinding pinning back from the dead).  I’ll be sure to buy him a couple beers and pick his brain!  It will also be really cool if we could meet Mark Abene (Phiber Optik) and Emmanuel Goldstein, those two are larger than life in my book!  We might also give a teaser or two about some new attacks we pulled off with the URI abuse. 

  

We've had an interesting couple of weeks recovering from DEFCON, including some discouraging feedback about our "disclosure policy"... perhaps we should actually get one of those someday.  Surprisingly enough, it wasn't from the folks at Mozilla, who were actually quite cool and just asked us to work with them in the future (which we will).   

   

We've just been featured on /. which has linked to an interview we did with Robert from IDG.  Article was pretty nice, however, it's received some /. criticism for lack of technical content...  We also leaked a little pre-release information about a new piece of URI Use and Abuse we are playing with... this one allows us to steal data from a user's computer thru an XSS exposure and a URI abuse.  Interestingly enough, we've been blasted a bit on /. because we haven’t released the details of the flaw.  Sometimes you can’t win the disclosure game (as I’m sure other security researchers have encountered).  We’ve gone through vendor disclosure, third party disclosure, and full disclosure, and we’ve been criticized each and every time….  We’ve got the FULL PoC ready and we'll release when we’re ready (shoutz to ROB CARTER for all his actionscript and sever side skillz!).  I’m sure we’re not alone with our experiences; shoot me an email if you have an interesting disclosure story…   

   

Finally…..  I’m sad to say that Mark Hinge and Mark Anderson of Whitedust have hung their hats up!  I’ve been a fan of Whitedust over the last few years....you'll be missed….  If you're ever in the Seattle area, look me up...   

   

-BK and Nate

I Survived BLACKHAT and DEFCON (Barely...)

Blackhat and Defcon are now officially in history books!  Nate and I had the opportunity to catch up with lots of old friends, as well as make a few new friends in the security world.  Nate and I were lucky enough to get a speaking spot at DEFCON (which was AWESOME) and I’ll be posting the slides and demos on the site within the next few days.

     

I had a lot of questions about the specifics of the Flash demo I finished with during my DEFCON talk.  I’ll be putting up some PoCs on how to force well known web mail servers to take ownership of a custom Crossdomain.xml file, which could allow for crossdomain requests through flash applets (as demonstrated in the DEFCON demo).

     

We also had a lot of questions about URI exploitation.  Nate and I should have some more examples coming soon…  but in the meantime, any questions we didn’t get a chance to answer in Vegas can be sent to our email accounts. 

I’ll be in and out for the next few days as I wrap up some forensics training, so my response may be a little slow.  If anyone is interested in talking about forensics, shoot me an email.

     

Next up on the list for me is HITB Malaysia!  It should be interesting as I’ll be showing how to pull off Anti-DNS Pinning in full blown Java Applets (JVM, not LiveConnect).  It works with IE and no proxy is required!

Remote Command Execution in FireFox et al

**** UPDATE ****

Apparently this flaw affects Firefox users that also have IE7 (with full security patches) on their system.  Just to be clear, this vulnerability is delivered through the Firefox browser, NOT IE.  You simply have to have IE7 installed somewhere on your system for this to work (which is basically most WindowsXP Sp2 systems)  You can read about the details HERE.   So it seems once again... as my first post (HERE) about URI handling issues stated.... IE PWNS Firefox.....

  

On a good note... I've noticed that this Mozilla bug ID has been changed to RESOLVED - FIXED.  That was LIGHTING FAST...  I'll be waiting for the patch to get pushed out...

**** UPDATE ****

   

IE has gained a LOT of attention from the way it handles registered URIs.  We (Nate McFeters and I) have repeatedly mentioned that IE isn't the only browser that has issues dealing with registered URI handlers.  In fact, some of the behavior exhibited by URI handling issues by other browsers can lead to remote command execution.... some examples can be found here.

  

Once again....  these issues are shown using FireFox (2.0.0.5), Netscape Navigator 9, and Mozilla, but many other browsers are affected as well.  It's time to take a good look at the registered URI handlers and how browsers interact with those registered URI handlers!

    

Developers who intend to (or have already) registered URIs for their applications MUST UNDERSTAND that registering a URI handler exponentially increases the attack surface for that application.  Please review your registered URI handling mechanisms and audit the functionality called by those URIs...

   

NOTE:  If another program (outlook, notes...etc) has modified the registered URI handlers on your machine, these examples may not work...

More URI Stuff... (IE's Resouce URI)

The resource (res://) protocol is built into Internet Explorer 4.0 and later. Typically, the resource protocol is used to pull resources like images, html, xsl... etc from DLLs and executables. You've probably seen the resource protocol in use and didn't even realize it (take a look at the properties for the images on a typical IE error page). The resource URI (like other URIs) has access to software on YOUR local file system. So, it's possible to call the resource URI from a remote web page, use the resource URI to check for the presence of certain executables and DLLs, then report back to a remote server whether that file exists or not. So in essence, an attacker can use the resource URI to:

• Enumerate the software on your machine


• In many cases, determine the exact version of software enumerated


• Use the enumerated software list to target specific exploits and attacks

The software doesn't have to be "installed" for this to work... simply having the executable on your system can also allow for enumeration. I've posted a proof of concept HERE. The PoC should work for pretty much all versions of IE (including IE7).  If you want more information about using the resource URI, check out our paper - URI Use and Abuse.


Now, before Firefox users start snickering, Firefox had a similar issue which was fixed recently. Their issue involved the "resource:" URI supported by Firefox browsers. Besides... FireFox has other URI handling vulnerabilities they should be worried about....

Firefoxurl URI Handler Flaw

When certain versions of Firefox are installed, the Firefoxurl URI handler is registered in the Windows Registry.  I'm sure everyone has seen the various PoCs where Internet Explorer basically forces Firefox to execute an arbitrary command using the Firefoxurl URI... its pretty cool.  Although I reported this to Mozilla shortly before Thor released his PoC on his blog page, my research was based off his original Safari exploit, so I think he should get full credz for this one!  


Now... a few people have asked me whether I consider this an IE flaw or a Firefox flaw... and the answer is BOTH.  Problems with URI handlers will not be fixed until BOTH the browser (in this case, IE) and the registered application (in this case, FF) change how URI handlers are used.  Before you start accusing me of fence sitting, let me explain my stance and maybe give you some insight as to why I feel this way.

1. IE doesn't properly sanitize parameters passed to URI handlers.  There are a lot of different exploits that can be pulled off because of this lack of sanitization... everyone knows about the Firefoxurl example, but did you know about Netscape Navigator, or Trillian?  Bad IE...


2. Firefox registers the URI handler in the Windows registry.  None of this would even be possible if Firefox didn't register their URI handler.   Know that when you register a URI handler in Windows, that URI can (and will) be remotely called by web pages through the browser (including IE).  Maybe the Firefox devs should have known a little more about how URI handlers are called before they registered their URI on my machine.  Bad Firefox...

This is just the tip of the iceberg... really.  Some colleagues and I have been looking into URI handler vulnerabilities for quite some time now and I can tell you this.... IE isn't the only browser that has problems sanitizing parameters passed to URI handlers... remote command execution can be initiated from other browsers as well.  To make matters worse, EVEN IF the browser did its job and sanitized malicious characters, URI handlers can still allow attackers to pass argument values to applications on YOUR system.  If there are flaws in the software that registered the URI, you are still vulnerable (as evidenced by the 2nd Trillian exploit). URI Handlers should be used with caution, browsers should sanitize, devs should understand the dangers of URI handlers before registering them, and anything dealing with URI handlers should be audited on a regular basis (as registering URI handlers greatly increases your attack surface)....more URI handler vulnerabilities to come... stay tuned.  In the meantime, here's a whitepaper about various URI uses and Abuses.