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

IE 8 Beta is Out!

The IE8 Beta is out.  You can grab beta 1 here.  I'm not going to comment on my thoughts on IE8 as I'm biased, but I've been playing around with some of the features and it's actually pretty cool.  

    

Probably one of the most interesting/most talked about features is the webslices and activities.  It's a little difficult to explain, but I think the video here does a pretty good job.

    

Happy Hunting!

Hanging with the Feds in DC

Blackhat Federal in Washington DC is officially over!  It was a great time and I'm honored to have been chosen to speak at the event.  Nitesh and I received a lot of great feedback and our talk was mentioned in a few different places (here, here and here).  Nitesh and I realize that the slides by themselves are virtually impossible to understand, so if you're interested in hearing the full talk, please don't hesitate to contact us.


The talks I attended were all great, but there below is a quick blurb on my favorites:




Cracking GSM - I've been waiting months for this talk.  h1kari and Steve from THC gave an incredible overview of how they are able to crack the A5 encryption used by cell phones to protect GSM voice and SMS communications.  They also pointed out several security weaknesses associated with cell phones and cell phone transmissions (strongest signal seeking, JVMs on SIM cards, downgrade attacks, lack of notification when weak/no encryption is being used...).  h1kari and Steve are using FPGAs to generate a 2 TERABYTE rainbow table and use FGPAs to crack the encrypted data.  With the help of a SINGLE FPGA (and the rainbow table) you can crack encrypted GSM communications in about 30 mins (30 mins as in, you capture and store the traffic as is goes by and crack it offline in 30 mins).  Commercial grade equipment that is being developed will be able to do it in 30 seconds!  This the third FPGA based project that has raised my eyebrows over the last year (this, NSA@home, and a third project that will remain undisclosed at this time), expect to see high amounts of processing power used to crack/brute force/solve previously un-crackable/ un-bruteforceable/ and unsolvable problems...  we live in exciting times my friends.




IO in the Cyber Domain, Immunity Style - Sinan from Immunity gave an awesome talk on Information Operations (IO) and how IO differs from penetration testing.  This is a discussion that I've had with many colleagues over many beers.  The basic gist of the discussion is, "how do you defend an organization/individual against sustained targeted attacks over an extended period of time?"  Immunity was basically given unlimited time and budget to break into an organization... it's a scenario very closely aligned with state sponsored Computer Network Exploitation (CNE), Computer Network Attack (CNA) and Computer Network Defense (CND) scenarios, where the adversary can conduct sustained information gathering and targeted attacks against an organization over an extended period of time.  Immunity spiced it up by bringing into play a "few 0-Dayz" and described how they penetrated the organizations defenses in a methodical, well-planned, and well-organized manner.  IO is a topic that's near and dear to my heart and I thought the scenarios presented in the talk were indicative of what some organizations face everyday...


 URI Use and Abuse / Dtrace: the REs Unexpected Swiss Army Knife  - I put these two talks together because Nate, Rob, Tiller, and David really brought out one of the core reasons why I like security conferences... we met the day before the conference at the hotel bar, talked about a few interesting things, and then proceeded to take a vulnerability from "un-exploitable" (as reported to us by the vendor) to "exploitable".  Not to worry, the vendor has already been notified about the vulnerability...

Bad Sushi: Beating Phishers at their own Game

A colleague (Nitesh Dhanjani) and I were recently accepted to speak at Black Hat Federal in Washington DC.  What basically started as a few laughs over a phishing site, eventually turned into months of serious investigation into the entire ecosystem that supports the phishing effort. 

   
Nitesh and I basically infiltrated a few phishing forums, tracking a phisher from compromised webservers, to phishing forums, to carderz sites.  We managed to get a hold of about 100 different phishing kits, various tools used by phishers, and gained some insight as to how phishers do their business.  I was STAGGERED by the amount of PII (full names, DOBs, credit card numbers, SSNs, addresses, phone numbers…) that is placed on public web servers by phishers, hidden only by obscurity.  Once this obscurity is broken, even a simple query in a search engine will reveal a significant amount of stolen identity related information including names, credit card numbers, SSN, DOBs…

   
I was also FLOORED by the number of phishing and credit card fraud related forums.

     



   

Nitesh and I basically stopped our research because the number of sites and the staggering amount of exposed PII was simply too much.  There literally is an entire ecosystem devoted to supporting the phishing effort that plagues modern day financial institutions, one that simply cannot be viewed by two Security Researchers alone.  If you’re in the DC area, stop by for Black Hat and we’ll show you some of the things we saw.  We give a brief description of some of the things we saw during an interview for Help Net Security.  For those of you who are curious, due to the ENORMOUS amount of PII we came across, we’ve contacted the FBI and we’ll be sharing some things with them that WILL NOT be in the talk or any interviews!

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:

 



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

 



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

Straight from the Source!

I hope everyone had a great New Year!  I had a sweet New Year… Liddell laid a serious smack down, I spent a few days boarding the slopes of Mt Baker, and I came across a sweet new blog from Secure Windows Initiative (SWI) at Microsoft.
   
Damian Hasse, Jonathan Ness, and Greg Wroblewski from SWI are going to give a technical analysis of vulnerabilities being fixed by the patches released on “patch Tuesday”.  Taking a look at the analysis and the level of detail they go into and I must say… I’m impressed.  One of the examples discussed by the guys from SWI (MS07-63) shows the differences between pre-patch and post-patch SMB packets and even includes a pcap file of pre-patch SMB packets.

I think initiatives like this are awesome.  Bad guys are going to figure this stuff out via reverse engineering, why not help the good guys understand what they are patching as well.  Providing technical information about vulnerabilities can help a good security team better understand and mitigate the business risks associated with vulnerabilities.  I can even see some resourceful professor using the analysis provided by SWI as case studies for prospective security pros.  Check it out sometime!  Great job guys!

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