Update: Nevermind… it’s all a mistake (refer to the comments for details). While TRACE is enabled, the cookies are not sent. The world is still safe.

I’ve spent a good chunk of today working with Jerimiah regarding the XST (cross site trace) issue he has resurrected from the dead. Yes, this is the same old attack from the 2002 era and it’s back to haunt us. Pretty much every browser technology has gone ahead and broken this for us, including JavaScript and Flash. The one that didn’t, however, is Java. Yup, good old fashioned Java. Java can be instantiated from JavaScript space, so Jeremiah was able to concoct a rather nasty and fairly buggy example of how you can get sites with TRACE enabled to give up HTTPOnly cookies, or other things hidden in the HTTP protocol. So yes, I have to eat my words on the fact that TRACE isn’t a problem - it is again.

So now the next question is how do you patch against it. So, yah, Apache has not made this easy _at all_. I spent at least half an hour combing through old ways to do it using mod_rewrite and no, they do not work (at least for me on apache 2.x). Your mileage may vary. Mod_security is an option if you trust it not to break your website (in my case it almost certainly would without turning almost everything off). Also a nice little re-compile is also possible, but given that an XSS is necessary in the site for this to work (or some other browser bug perhaps) I’m not sure in my particular case it’s worth patching. Others? Yah, it’s worth it. Also, worthy of note, I had a really hard time getting his exploit to work. It did work in Firefox in safe mode, but I had problems with plugins, and no luck with IE at all. Anyway, it’s aliiiiive! Good work by Jeremiah!

Stefano di Paola had a really interesting post the other day about how you can do HTTP Response splitting inside digest authentication in IE7.0, Firefox and Safari. For those of you who aren’t familiar with how this works, older browsers allowed you to do authentication on URL field with the syntax http://username:pass@site.com/. Most browsers have tried to somehow reduce or completely remove how this works, although it is still possible in some cases.

In the example Stefano gives he was able to inject arbitrary headers using the trick of putting a newline %0a into the username of the URL field. Very cool hack, and suddenly brings back a wide variety of exploits that were pretty much out of commission because all of the XMLHTTPRequest and Flash tricks had been removed. It’s not clear how long these will stick around, but it’s great work by Stefano.

And sorry about talking about this late. I knew about this several days ago but I am still very much immersed in my move. I’m living out of a hotel room at this point. Oh, I never truly knew the joys of domestic violence in the morning. It’s better than a cup of coffee.

In the spirit of beta testing, I was sent a link from Gianni Amato on a new extension he’s written for Firefox called XSS Warning. Unsurprisingly, it warns you of potential XSS attacks on the URL string with a large blocking page. I have not spent a tremendous amount of time playing with this, but I had a few thoughts. Granted this is experimental, so I’m not trying to rip into it, because it definitely provides a service. But here are some thoughts.

Firstly, it only works in the case of reflected XSS. While that’s the most common form of XSS, it’s also only one form. Secondly, because it doesn’t generate an alert box, if the XSS is loaded inside of a hidden iframe, the user would never be warned that it failed (also making it easy to check for, incidentally). So while I love this research, and I want a lot more of it, this shouldn’t be considered a panacea, although I think we are well on our way now that we finally have people like Gianni and Giorgio looking at this. Very cool, and I encourage everyone to check it out.

I’ve been auditing a website over the last few days that has been seriously compromised. The good news is that they are prepared and determined to fix the problem, the bad news is that they have so many potential holes it would take a small army to fix them all in a reasonable amount of time. I found myself saying something I really thought I’d never say - “What about a WAF?” There are two special circumstances that struck me about this situation that made me have a bit of a change of heart.

First of all, anyone who has read this site long enough knows that I’m pretty critical of WAFs in general, so I’m not here selling them or anything. They can represent a single point of failure in many applications, add additional complexity, have false positives and false negatives and require administrative overhead - not to mention the cost. But here is where I changed my mind. In this case the client had between 1,000-5,000 customer facing attack points to secure. There is no possible way they could fix that by hand in any reasonable timeframe.

Secondly, the attacker left malware on the system that was intended to infect the users of it (a la the superbowl hack). Like firewalls, WAFs could theoretically be used for egress filtering. Even during a complete compromise the system could prevent consumers from getting infected with any future malware that the system leaves for them. This assumes that it is not re-assembled via JavaScript (or other client side code), but in most cases it would at least slow down the rate of infection. So yah, I had a moment of weakness and let the three letters out of my mouth, but in this case, I think it’s justified.

I had a really interesting conversation with a guy out of Romania this morning regarding a team of CAPTCHA solvers that he has set up. The basic premise is that he has 5 guys set up to solve CAPTCHAs like Yahoo, MySpace, and Hotmail. He does this for clients all over the world. The economics are probably the most interesting part, since his team is non-technical and only types in what they are given by their clients.

The economics are as follows: 300-500 CAPTCHAs per person per hour. The clients pay between $9-15 per 1000 CAPTCHAs solved. The team works around 12 hours a day per person. That means they can solve somewhere around 4800 CAPTCHAs per day per person, and depending on how hard the CAPTCHAs are that can run you around $50 per day per person (his estimate). The reason it’s not higher is because they take breaks, and fail sometimes.

He also admits it takes some time to ramp them up on new CAPTCHAs. Eventually they get faster at solving them. So for $50 a day, you can get your own human CAPTCHA solver. The ages of the solvers range from 18-23 years old. Pretty interesting stuff - what a crappy job!

This is actually a really serious issue that was sent to me. The funny part is that I’ve known this was possible for years now and even already put it into a presentation I’m doing in a few weeks, but anyway Google’s ads have been spreading malware. A few people with Google accounts have been buying sponsored ads (no doubt with stolen credit cards/identities). It’s sure easier than getting to the top of the search results page!

Although I don’t think this signals the end of text ads, I think it’s a wise choice to consider any paid links to be just as untrustworthy as anything on the SERPs. Google, nor any search engine have been particularly good about vetting how good or bad a domain is before linking to it. Hey, money is money right? Although, I believe they will probably do a cursory scan of the domain to make sure it isn’t spreading malware in the future given the bad PR, it’s pretty easy to fool spiders into not seeing malware. So I’m not sure what actual protection this will provide.

My next thought was CSRF - if you buy a search term and include a few images to remote domains you can pretty easily get them to do things on your behalf, and it’s extremely targeted at the same time. Yah, that’s bad. Don’t trust those paid ads - it doesn’t matter if they are “sponsored” or not. As a side note, I was a little annoyed to read that Matt Cutts wants people to snitch out paid links. I think Google should look at it’s own problems before trying to hurt people’s revenue streams. At least with my paid links, I wouldn’t be risking people’s identity to click on them!

Wow, 24 hours in a car… I made it to Texas safe and sound. There were a few interesting things that happened that are strangely enough interesting to security. First the actual packing. I hired a company to do the packing and storage of my stuff until I’m ready to bring it out. They wouldn’t take my guns or alcohol or anything in liquid so I had to drive. Annoying, but manageable. Anyway, the packing guys did an amazing job. They packed up my entire place and got it into the truck in 6 hours, and I have a lot of annoying stuff to pack. They had four guys working on it, but I realized that even if I had all the right packing stuff, there’s no way I could have done what they had done in 48 or more hours, let alone 24 man hours.

It’s not because I’m lacking the skill, or the strength or even in the interest. In fact, I’m more interested than anyone. The moving company has no interest in my stuff whatsoever. Granted, they don’t want it broken, because they don’t want to get sued, but short of that, they couldn’t care less about any of the individual items in my apartment. So for them to move my stuff is an emotionless event for them. For me, I would have take every individual item, inspected it, thought about what it meant to me, where I bought it, what condition it is, where I want it to end up in the new place, and sorted it accordingly. All without really thinking about it, but each item would have taken me 2-10 times as long to pack depending on what it was.

The moral of the story? I think the same is true when you are talking about assessments. I remember back when I was a lowly programmer and we did code reviews. The person coding it would spend days or weeks programming something and we would tear it apart in a few minutes. They were lacking the distance to know better. They were thinking about the classes and sub classes and data structures. No one on earth knew the code better than they did, yet they lacked the distance to be able to assess it quickly. Since we didn’t care we could to so efficiently. It’s not that they were lacking the skill, far from it. They were lacking the self distance. Obviously, sometimes people are purely lacking the skill (like how to lift a box into a truck without hurting yourself) and that would make the results even more dramatic.

The second interesting part of the story was when I got pulled over. The border patrol was pulling every one over near the border between Texas and Mexico. I thought at this point the deal was over. For sure they were going to arrest me. I was bringing cases of alcohol, firearms, hacking stuff, liquids that could easily make some sort of chemical nightmare (cleaning supplies) not to mention the various foods that I’m sure you’re probably not allowed to take across state lines. I was prepared to turn myself in for a lenient conviction. Alas, they asked me only one question. Here is the sum total of that conversation:

Officer: “Goodmorning.” RSnake: “Goodmorning.” Officer: “Are you a citizen?” RSnake: “Uh, yes?” Officer: “Have a good day.” RSnake: “You too!”

So it occurred to me as I was pulling away from the checkpoint, that is a pretty damned easy test for me to pass, and I wasn’t even good in school or anything. How many thousands of dollars a day does it cost to run that thing and what exactly does it stop? I could have had 5 mexican guys and an Al Queda member under the boxes in the back. Maybe they were scanning my truck with x-rays looking for human passengers, or using geiger counters looking for radioactive materials who knows? Anyway, it was worth a laugh. It would have been hard to fail that test, unless I accidentally blurted out, “Si!”

Well, we are finally done with the XSS book (XSS Attacks - Cross Site Scripting Attacks Exploits and Defense). It’s off at the presses, and should be on the shelves in a few week’s time. We were authorized to throw up a sample chapter and the table of contents from the book for anyone who would like to read it. You can download a zipped up version of Chapter 5 and the table of contents.

Since it wasn’t super clear, and because we had a tiny bit of a cast change, here is the final author list from the book: Jeremiah Grossman, Robert “RSnake” Hansen, Petko “pdp” D. Petkov, Anton Rager and Seth Fogie (both a technical editor and contributor). I hope anyone who buys the book likes what they read. Please take a look at the zip file for anyone curious about what the book is like. It’s a technical read, but I think it’s a good reference for anyone new to the field or anyone unfamiliar with the nuances of what we talk about every day.

Btw, I am in the process of making a big move across the country, so starting tomorrow and over the next several day the posts on the site will slow or completely stop. I’ll have next to no access to any computer. I’ll be back online hopefully by the end of the week. Catch you on the flip side!

Yesterday while I was helping Jeremiah with he forced basic auth cookie testing he asked a good question, which is how you can better de-anonymize users through alternative methods. Some of the initial thoughts he had wouldn’t work, but the first thing that popped into my head was FTP and Gopher. Using out of bound methods to make TCP or UDP connections to a monitoring site are easy ways to correlate users (compared with time).

Now, having had a day to think about it, there are a ton of ways to do this exact same thing. Here are just a few ways I was thinking of:

ftp:// FTP connections (port 21) - quietly connects to the port of the remote host. Many proxies don’t forward FTP, meaning it will connect directly from the client to the server, bypassing any FTP servers.

gopher:// Gopher connections (port 70) - quietly connects to the gopher port. Could be popped up in an iframe or anything similar.

telnet:// Telnet connections (port 23) noisily opens the assigned telnet client. If you haven’t already done this once, and authorized the application in Firefox it will warn you upfront about what is about to happen.

file:///\\ Windows networking microsoft-ds and netbios-ssn (ports 445 and 139) although this can kind of grind your browser to a halt until it fails, it really can help identify the computer. In IE it will also cause a popup alert if it doesn’t connect.

scp:// WinSCP protocol (port 22) if WinSCP is installed the remote web server can ask you to connect to it. It will open the external application in a very obvious way.

The next question people are going to ask is, how do you do this if you have dozens of people hitting it at relatively the same time. This part of the technique is borrowed from a page out of HD Moore’s decloak and some of Martin Johns’ stuff. If you create a unique hostname per request, you can correlate that information back to the timestamp. However, because you aren’t necessarily aware of the host (just the IP) this technique has to be modified slightly. Instead of hostname tricks you can use a number if IPs. Of course that means needing a lot of IP space. Setting up a packet sniffer in front of or on the host means you don’t even have to keep any of those ports open.

Of course other protocols may be in place with external applications that are installed (similar to the scp example). Knowing them can be tricky and noisy if they fail, depending on how the fail. The point being there are a lot of alternative paths to getting a machine to connect directly to the machine in question by bypassing the normal hypertext transfer protocol completely.

I was sent this link today on Clickbot.a written by the Google adwords guys. It’s a pretty interesting high level read for the most part, if you don’t know much about click fraud, but does get into some of the technical stuff near the end on how the bot actually worked. While the conclusions of the paper are fine, I was struck that the authors failed to address the most important point.

The most important point being the only reason this bot existed, and the only reason the hackers used it to compromise 100,000+ machines - because it was economically lucrative to do so. That means Google’s detection was too slow to respond to and prevent the attackers from making enough money to make it worth their while. Also, it was at the expense of the advertisers as well as the poor web sites who were compromised for this purpose no less. Which means that Google’s detection methods need to improve to not just pick up this particular variant but also polymorphic versions that are far less easy to detect. So while it is commendable for Google to fix this one issue, it shows they are lacking the technology to pro-actively defend against future and less immature variants.

While Google’s executive management feels that economics will solve this issue I feel that Google is failing to see how detrimental this is to the advertisers who depend on quality click traffic. In lieu of this quality, alternative solutions must be in place to allow advertisers to recoup their costs while Google struggles to build new technology to defeat the issue. However, without access to the actual landing pages that the advertisers use, Google cannot have deep insight into the full picture. Ultimately, this will cause a bigger rift with time that the attackers can exploit on the vast majority of sites that don’t use alternative click quality tools. Until the time when Google can come up with a creative solution, companies like Click Forensics fill that void.