It was a whirlwind trip, but I just returned from RSACon. It was a fun trip and I had a lot of meetings while I was there. I had very little time to stop and relax, but there’s no rest for the wicked, or so they say. Anyway, here’s an ultra abbreviated version of the highlights (there will be more posts to follow, this is just a summary for those who couldn’t make it).

Before I even took off, I got a call from a friend of mine who did a search in Google for “RSACon” to get some more information. It turns out that I am ranked number 1 and number 2 for “RSACon” on the search results (randomly). So before I even took off he knew I was coming into town even though I hadn’t told him. How weird!

I landed and within 30 seconds I got a page from Arian Evans asking if I was in town. What, am I wearing an RFID tag?

I meet up with id and we roll down to the XYZ for a late night meeting with some high powered infosec guys and then called it a night around 1:30. I slept on his floor, trying to ignore the jet engine sound of his walk-in-closet/data center - it was not glamorous.

I woke up early and went to a Dark Reading meeting. Met with some good folks, had a technical round table discussion and bailed to go to the con. I’ll probably have to post about what we talked about in the not too distant future.

I arrived to find they didn’t start until 11 - giving me a few hours to kill. I met up with Billy Hoffman. Later I met up with Jeremiah Grossman and we had a quick chat with Jeff Moss (DarkTangent) about some future talks that Jeremiah and I are thinking of doing - we’ll see.

The con itself started and I hit the floor hard, seeing as much as I could in an hour or so. I’ll probably write something up about some of the scanner stuff I was looking at. There’s a lot good and a lot bad about what I saw. This one deserves another post. For the most part the theme this year was scanning, blocking and identity theft. There were a lot more web application security companies this year than last year though. No one really knew who I was (I wasn’t traveling under the RSnake moniker) so I got the raw skinny on a lot of technology. People try to sell me too much when they know who I am.

So then it was about that time to go to the WASC meetup. Wow. Talk about a turnout - it was at least 30 people (compared to the 11 that showed the year before). A shout out to the Danes (Tate and Soren) that showed - I wish I could have chatted with you guys a little more. They were the first ones to come up to us and say, “Okay, which one of you is RSnake?”

Zeno showed, Arian showed, Billy Hoffman, Michael Sutton, Anurag Argawal showed, some ex co-workers, etc… It was quite a powerhouse! Here’s where the apologies begin:

• MicroSoft - Where to begin?
• A friend of mine, Erik shows up to the WASC meet-up who I hadn’t seen in years. He and I chit-chat and he has been to my site. Oh, he works for Adobe now and he didn’t tell me. Yah, sorry about that.
• Daniel Veditz shows up from Mozilla to talk to me. Oooh… yah, sorry about that.

So yah, I don’t think I’ve ever apologized so much in one 24 hour period. I had a really interesting conversation with Billy Hoffman that I’ll have to write about (it’s way too long to include here) about another unique way to detect CSRF.

At some point I got accosted by someone who works for an ubercorp who was giving me the third degree on me setting up my own company. Too much competition, tough to get in, what do I bring to the table? “I run this site called ach ay dot cee kay ee are ess dot org” “No, I don’t think I’ve heard of it.” “ha.ckers.org?” “Oh! Yes! Are you RSnake?”

Later we packed it up and left to go back to the convention. I ran into someone who outed Jeremiah almost immediately but didn’t know who I was until Jeremiah said “If you know who I am you know who he is.” At which point he said, “Are you RSnake?”

What a day. Anyway, it was a rip roaring good time, lots of tech, lots of talk, and I promise to go into depth on more of the tech stuff as I know that will interest more people. Plus there are some photos floating around, I’ll have to see if I can get my hands on some of them and throw them up in the pics section.

I was going back through my file of older issues, and I started playing with Amit’s header spoofing using XMLHTTPRequest in Internet Explorer and to my surprise it appears to have been fixed! Talk about quiet! So I emailed Amit, and he too couldn’t verify that it was fixed in IE7.0. I finally got to the root of the issue. Apparently in MSXML3 SP8 and MSXML6 SP1 (which ships in Vista) you can no longer do header spoofing in Internet Explorer using XMLHTTPRequest. Amazing!

I was hesitant to post this until I verified the facts but apparently it’s true. Amit told me that his tests were done using IE6.0 (7.0 hadn’t shipped at the point he had released that post). So for those of you who are trying to get it working but can’t, that may be why. I haven’t concluded my testing using some of the other more obscure methods, but so far, so good. MS has been doing a good job of shutting this stuff down, lately!

I laughed out loud when a friend of mine sent me this link on a study by Harvard and MIT on the effectiveness of sitekey. I really want to yell from the rooftops, “I told you so.” I’ve looked into that technology a dozen times, in a dozen different incarnations and each time I just shake my head. It’s just not effective. A) People don’t understand how it works and b) if the image doesn’t show up on the page, users don’t get that they are on a malicious website - at best they think Sitekey is just broken.

This we can file in the “users cannot be trained” category. You cannot expect users to know what a good site is verses a bad site. It doesn’t work (at least in 9 out of 10 people). I would have guessed slightly more people would have figured it out, but even if it were 7 out of 10 people, that’s barely worth wasting your time and money on - not to mention the bad press that comes from rolling out flawed security measures. No, it’s not up to the consumers to protect themselves. That’s OUR jobs. We need to take it out of the user’s hands and bring security to bear to protect them because as we can see, users cannot be trained to protect themselves.

Yes, this is a few months old, but for some reason I just got around to watching it now. Someone mentioned Dan Kaminsky’s name and I did a quick search and found part of a Toorcon presentation he did on SSL security. It sounded interesting but the data he quickly wracked up got me thinking. A huge chunk of big websites use replicated data. They simply ghost image a drive and copy it over indefinitely - which makes patch management much easier). If you happen to run SSL from that machine you get the SSL keys on every machine (and why not, they have the same address due to tricks with squid).

If you have the same SSL/http key on multiple servers an attacker can sniff all the traffic. Crazy! Selling machines at auction was always a risky proposition, but especially so if the SSL keys are intact and even more so if you tend to replicate entire drives. Even an old drive used in a RAID array could prove to be dangerous.

Furthermore something else Dan mentioned in the speech was that by not forcing SSL on the page where the user inputs the data (and only on the page the data is sent to only works in the absence of an attacker). Pretty profound statement. Obvious if you know anything about security, but it really drives the point home. I’ve heard people say that they read the HTML on pages before they submit their credentials - okay, even if I believed that, do you also read every last line of JavaScript on the page and verify the DNS entry for the page you are submitting the data to (especially if it’s on a different IP than the one you are entering the data on)? I think not.

Very cool speech if you haven’t already seen it. No, it’s not new, sorry, I apparently missed this one somehow.

Kanatoko published a very interesting issue in Flash where apparently it doesn’t follow the browser’s DNS pinning cache. So while DNS pinning plagues us and can be circumvented in some very interesting ways, Flash doesn’t adhere to the browser’s DNS cache and instead you can query directly (you just need to wait).

So Kanatoko produced a demo in Flash that does Intranet port scanning in Flash - it’s actually relatively fast too. It only scans one host, but you can see how this could easily be expanded upon without too much work. Very nice work Kanatoko! This would definitely make attacking Intranet applications much easier.

This post will be most likely lost on most of you but today I suddenly realized that formlib.pl is vulnerable to XSS. “What is formlib.pl?” you are probably asking yourself. It’s sort of one of the foundations of CGI programming that was one of the first things built to deal with dynamically generated webpages. It was the first CGI interface library written for PERL before PERL was really even an object oriented language. More code that uses it. Yup, it’s a blast from the past.

The only problem is there are some people (like myself) who still use it, because it’s so efficient. Of course I’ve hacked it up over the years by making it more efficient and easier to use etc… but I left in (in some format) the one vulnerable line of code:

&HtmlError("formlib.parse", "bjelli", "Error parsing $_, aborting.\n");

For those of you who can’t read PERL the $_ is an anonymous variable. If you can get it to error out you can get it to execute any JavaScript you like as long as it doesn’t have quotes in it. Here’s a way to get it to error out:

POST /cgi-bin/vulnerable.cgi HTTP/1.1
Host: www.vulnerable-site.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Cookie: dbx-postmeta=grabit=0-,1-,2-,3-,4-,5-,6-&advancedstuff=0-,1-,2-
Content-type: application/x-www-form-urlencoded
Content-Length: 53

<script>alert(String.fromCharCode(88,83,83))</script>

Okay, how do we do that? Well here’s one way. Actionscript inside Flash allows us to do some pretty crazy things (I’m researching an old issue right now with Amit which is how I found this originally).

var req:XML=new XML('<script>alert(String.fromCharCode(88,83,83))</script>');
req.send("http://www.vulnerable-site.com/cgi-bin/vulnerable.cgi", "_self");

Anyway, like I said, this is probably lost on most people, but to me it was a big deal. I found eight places on this site alone that were vulnerable. If you are an old-school PERL hacker and you haven’t upgraded from formlib.pl to something like CGI.pm (despite that that module is bloat-ware) you probably should at least patch up by removing the “$_” from the script.

There’s a lot of different ways to DoS a browser, and I’ve just found one more, simply by accident. Because the mhtml library deals with a number of redirects and because many sites use redirection I intended to see I could follow those redirects to a depth greater than one to uncover session variables in the URL string (one of my clients does this, so I was attempting to see if I could grab it). Unfortunately I DoSed myself.

Click here with Internet Explorer 7.0 with JavaScript enabled. It will cause your browser to hang using an MHTML redirect followed by two more redirects. It also has strange effects on other applications (including Thunderbird - not sure why). You can still easily kill the browser, but until that point it becomes unusable.

I also was unable to reproduce under 6.0 (probably because the XMLHTTPRequest method I’m using doesn’t work with 6.0 but I haven’t validated that the technique wouldn’t work in both). I’m not sure how else this may be useful, but DoSing an application is never good.

I’ve had a number of people over the last year or so ask me what good sites are out there for people to learn about web application security. Honestly, as of a year ago there really weren’t many out there, but suddenly there’s been a bit of an explosion of them. I’m actually really glad to see so many rising up, because the more people do research the better we will understand the issues involved in writing and breaking web applications. Anyway, here’s a list I threw together in just a few minutes. If I missed some let me know and I’ll add them. (And this really isn’t in any particular order, in case you were wondering):

• ha.ckers.org the web application security lab. Nuff said.
  
• Jeremiah Grossman’s blog it’s sort of ubiquitous because it’s such a must-read. This is one of the few blogs that I actually point my RSS reader to to make sure I read things as they come out. It’s a must read.
  
• Stefan Esser’s blog I love that Stefan quit the PHP security team, we’ll get a lot more intelligence out of him now.
  
• WebSecurity.com.ua if you read Ukranian, you’ve got a head’s up, because there is some good stuff coming out of this site.
  
• Sylvan Von Stuppe’s blog he’s a regular in breaking applications. I actually try to visit his site at least once a week to see what he’s thinking. Smart guy.
  
• Kuza55’s blog he may be new to web app sec but he’s scary smart. His blog is definitely one to keep your eye on.
  
• Billy Hoffman’s blog he’s often got a unique spin on a lot of security issues that affect us. I find myself here at least once a month or so reading the backlog of what I’ve missed.
  
• Michael Sutton’s blog another SPI Dynamics guy who writes a good blog. Since he wrote the story on reading Google’s anti-phishing list it’s been a good read. He’s really stepped up his game and I look forward to reading more of his stuff.
  
• Zeno’s blog he’s had his site up for forever and a day. He’s recently started posting more and I regularly check his site out for anything interesting he might have come up with. He’s also a proponent of building security into the QA cycle, which jives with a lot of how I’ve structured a secure PDLC. Good read.
  
• Jungsonn’s blog he floats back and forth between pure webappsec stuff and random other thoughts, but I always keep my eye on what’s he working on. Jungsonn has got a lot of interesting thoughts on securing sites with Apache rules that is probably interesting to the individual webmasters out there (myself included).
  
• Mightseek podcast it’s not updated much anymore but it’s still interesting. I am always looking forward to his next podcast. I’ve never been into listening to podcasts because it’s annoying and I’m a much faster reader than a listener but his is one I’ll make an exception for.
  
• pdp’s blog he’s the guy who built attack API, came up with quite a few vulnerabilities in quicktime and runs a good security site. He goes back and forth between technical and high level, but it’s quite often an interesting read.
  
• V-wall’s blog he’s barely got started, but I bet it’ll be an interesting blog to read in the not too distant future.
  
• Sven Vetsch’s blog this is a pretty new site and a pretty technical read but like V-wall’s site I have high hopes.
  
• Martin Johns’ blog while not updated that often, it’s one of the few sites that really delves into some of the more technical research that actually builds new exploits. He’s definitely opened the door to some of the more interesting anti-DNS pinning exploits.
  
• Kyran’s blog he’s new with webappsec but he’s really come out with some interesting stuff, including some writeups on Kuza55’s XSS fragmentation issues in MySpace.
  
• Luny’s blog he keeps it updated and focuses primarily on social networking worms and MORPGS. It’s often a very interesting read.
  
• Anurag Agarwal’s blog he primarily keeps up on mitigation techniques and also does some biographies on hacker types. Could be a good one to keep up with.
  
• A Day in the Life of an Information Security Investigator a funny outlook and a smart blog on information security. He does delve into webappsec issues as well as a ton of other stuff.
  
• Bruce Schneier’s blog okay, maybe it’s not really webappsec, but it’s one of the few security blogs that I type in by hand on a regular basis to see what he’s talking about. He doesn’t just talk about crypto. Sometimes he does talk about web applications and whenever he does I lift my head up. It’s one of the few interesting sites out there that is updated regularly (2-3 times a day).

I got some complaints with how I wrote my mhtml library so I’ve modified it to be a little better (fixed the restriction functionality and expanded it to support https as well as http). I also uploaded a sample of how it works so people can actually see what’s going on here (you must use Internet Explorer 7.0). The example I chose is probably more interesting than most.

Expanding on the original example that Trev built, I pulled a page from Google, but I picked a slightly more interesting page that includes not only the user’s email address, but their actual email address that they used to register their account.

Assuming the user visiting the page is already authenticated to Gmail we can de-anonymize people who hide behind the gmail.com domain and use Internet Explorer. There are probably lots of other interesting things you can pull with this, but I just wanted to throw together an example that people could really understand.

I’m really behind in email so this is a few days old, but Michael Sutton wrote up an interesting post about the rate of vulnerability for a few simple search terms. He found that around 17.3% of the sites he checked for were vulnerable to XSS on the exact page that the search engine sent him to (when querying for things like inurl:"search=xxx" intext:"search results for xxx").

Of course that’s not actually the number of vulnerable sites, that’s just what he was able to find at that given URL on those sites. The statistic may also be slightly misleading because it depends on the search term given. Obviously there are other Google dorks that could have proved to be 100% or 0% depending on how they are constructed. But still, it’s interesting, and certainly a valid way to identify large scale swaths of vulnerable sites.

Writing automated scanners to pick up huge chunks of vulnerable sites is incredibly easy if you are uninterested in targeted attacks or are more of a opportunistic exploiter. But providing a JSON interface to a search API could also help in cross domain XSS virus propagation as well.