A colleague and I were tossing around the idea of preventing XSS Exploitation with CSRF tokens. Now, before people start going "high and right" on me...hear me out... I DID NOT say "prevent XSS" with CSRF tokens, I said prevent "XSS Exploitation" with CSRF tokens. This discussion arose after someone presented me with the following scenario (this same scenario has been presented to me many, many times... typically at a bar after a few drinks):
You come into an organization and take over the application security department because the old security person left/was fired/was arrested/whatever. You take a look at the 10 million line flagship application and realize that its riddled with XSS holes, yet you don't have the resources/time/cojo's to fix all the exposures. What do you do?
This scenario is usually followed up by a pitch to sell me on some Web Application Firewall product..... I'll put my thoughts on WAFs aside for a second... and I'll try to get to the underlying issue of the scenario presented above: You need to do something to stop your customers from getting XSSd, you don't have much time, you don't have many resources and there is a ton of code to go through.
Now, what if you required CSRF tokens/canaries for every request? This doesn't "fix" the XSS exposures, but it makes it a LOT more difficult to exploit (unless you want to exploit yourself). The CSRF tokens effectively prevent an attacker from sending the XSS to anyone else. Considering many token/canary values are implemented at the framework level, in most cases it would require a configuration change for the application. Now, once every page is protected by the canary, you can systematically examine the "high priority" pages or pages where canaries don't make sense and remove the canary requirement after that particular page/functionality has gone through a review. In order to prevent the attacker from sending their own canary value, the CSRF token would have to be tied to the current users session (most good implementations do this anyway).
Now, once again, this DOES NOT FIX XSS, it just makes exploitation harder. This isn't a new concept, in fact this same type of approach is being used by modern day operating systems. Take buffer overflows for example, protections like DEP, ASLR, Stackguard, GS flag... these protections do not prevent developers from writing buffer overflows and they do not "fix" buffer overflows... they do make exploiting buffer overflows a lot more difficult (unless you're a Litchfield brother, HD Moore, or Alexander Sotirov).
Now, of course there are some cons to this strategy... First, the XSS exposures are not fixed (the WAFs don't fix them either). This doesn't protect against persistent XSS. There will be some performance hits to your web server when you have canaries for each request. This will NOT help you defend against injection attacks like SQL Injection or Command injection, that will require an audit... on the flip side... if you're relying solely on a WAF to protect you against SQLi and Command Injection, I'd be worried...
Wednesday, March 19, 2008
Monday, March 17, 2008
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
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
Wednesday, March 5, 2008
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!
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!
Sunday, February 24, 2008
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...
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...
Sunday, January 27, 2008
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!
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!
Monday, January 7, 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:
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:
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
- 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
Wednesday, January 2, 2008
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!
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!
Subscribe to:
Posts (Atom)