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!