Mubix sent me a link today to the fact that Com.com is for sale. So what, right? Yet another domain that needs a home. But com.com is incredibly important for security. In fact, one of C|NET’s (the company that currently runs com.com) network admins was listed as the 10th most dangerous and least likely person on the Internet during my presentation at OWASP. Why? Because of typo traffic. A friend of mine used to run csuchico.com instead of csuchico.edu and used to get tons of sensitive information about the local college, including building plans, love letters, medical information, bills, and on and on… And that was just one .edu domain. Now imagine the typo traffic for all of .com!

I’m not just talking about email, but think about all the DNS errors, and the referring URLs and the places that you could XSS just because of sloppy coding? It’s a recon dream come true, and it’s almost entirely passive! I tried to register xn--g6w251d.com at one point (a typo of the simplified Chinese IDN TLD). Most people don’t realize that xn--g6w251d (測試) is a TLD and there are a bunch of others like it. So owning xn--g6w251d.com would allow me to get tons of typo traffic, but ICANN in their infinite wisdom decided you’re not allowed to own things like xn--g6w251d.com anymore because it’s too dangerous. Yet com.com still exists and it’s up for grabs! I’m sure it’s monetarily well out of reach for the average bad guy, but there may be a lot more than average bad guys who are interested in owning this one.

Okay, last post about DNS Rebinding and then I’ll (probably) shut up about it for a while. If you haven’t already, please read posts one and two for context. As I was thinking about the best possible uses for DNS Rebinding I actually landed on something that is extremely practical for botnets, email scrapers, blog spammers and so on. One of their largest problems for most attackers/spammers is that they need to be able to scrape the search engines for targets and the only way to do that is to send a massive amount of traffic at them and if they use a small subset of machines they are also making themselves easy to block or subvert. Google typically tries to stop robots from scraping by showing a CAPTCHA. Wouldn’t it be easier and better if the attacker/spammer could use other people’s IP addresses? That’s the promise of DNS Rebinding, now isn’t it - unauthenticated cross domain read access from other people’s computers.

David Ross had a good post about how another practical defense against DNS Rebinding is using SSL/TLS, but since Google has opted not to secure their search engine, it becomes possible to use DNS Rebinding for its next logical use. Google hasn’t even fixed their other SSL/TLS woes so there’s pretty much no chance they’re going to secure the search engine any time soon. So DNS Rebinding gives the attacker IP diversity. An attacker can use DNS Rebinding to get other people to rip tons of information from Google without Google being able to block the real attacker. Since sites like Google do not respect the host header and they don’t use SSL/TLS an attacker can scrape information from these sites all they want - all the while using other people’s browsers. Now think comment spamming, polling fraud, brute force, and on and on… All of these become extremely easy and practical by burning other people’s IP addresses, instead of the attacker’s/spammer’s. Yes, DNS Rebinding is nasty, and unless the browser companies do something or every attacked web server on earth starts respecting the host header and/or using SSL/TLS it’s a problem that’s here to stay.

I know a lot of people think this is a complicated technique, but it’s really not that hard. It just requires some JavaScript (similar to BeEF or XSS Shell), a place to log data to log whatever the user saw when the attacker forced them to perform the action, a hacked up DNS server (like the simple DNS Rebinding server sample), a domain, a Firewall that is somehow linked to the attacker/spammer application and some Internet traffic to abuse. None of these things are out of reach for a decently skilled attacker. Anyway, I doubt it’s getting fixed anytime soon, which means DNS Rebinding essentially allows nearly free reign for attackers and spammers for the foreseeable future - and no one appears to be doing anything about it.

In part two of my DNS rebinding diatribe I wanted to talk a little more about the previous problem of session fixation. Session fixation is great but it’s only great if by getting them into your account that provides you some value as an attacker. Sometimes that’s useful, sometimes it’s not. But what about a different scenario where the attacker has no access to the page in question so they can’t get access to an account ahead of time - but rather what if the web server is back behind the firewall again? What if it’s a webserver that he wants to compromise but happens to use some cookie as an authentication token? Ahhh… here’s where we might be able to attack it.

A lot of people still don’t get that you don’t need to know people’s usernames and/or passwords to get into their accounts. If you can get (or guess) the credential, that’s good enough. What if the credential were a weak cookie like username=bob or id=1234567? It might be extremely trivial to use DNS rebinding to not only get access to read the login page and perform a traditional brute force attack, but if the format of the credential is known (like in a lot of open source projects) it may be easy to brute force that token. So yes, by getting DNS rebinding and by utilizing brute force you can then fix their session to whatever account you just broke into. And it just keeps getting worse…

While I was out at OWASP, I ran into Dan Kaminsky and we started chatting about DNS rebinding - as we are known to do. Almost immediately he surprised me by saying that DNS pinning is a bad idea. After much explaining, I get why he thinks so, and I found myself nodding. It’s not because it’s not a good idea, it’s because it doesn’t work, and all the crazy ideas we’ve both collectively heard are either hugely cumbersome or are easy to break. Either way, they aren’t good solutions. So the only valid solution that has any real hope of working is respecting the host header. This means that every web enabled firewall, print server, router, switch, and internal Wiki is in danger until they too learn how to respect the host header. So yes, DNS rebinding is probably here to stay.

Now, I’ve had a thought for a while about another attack that can be leveraged because of DNS rebinding - and that is session fixation. So here’s the scenario. Attacker goes to goodguy.com and logs into his account there. Then he takes the cookies that goodguy.com set in the attacker’s browser and he writes up a little script on badguy.com to set the same cookies. The attacker also has a DNS server that sends a DNS response with a time to live of only 1 second. Then the user comes to badguy.com and gets the cookies meant for goodguy.com but which are only visible on badguy.com. Then a piece of JavaScript redirects the user back to badguy.com in 2 seconds, (one second longer than the TTL on the badguy.com DNS response) and the attacker shuts down the firewall on badguy.com so the user cannot reconnect. The browser rebinds DNS, making a second DNS request in the process. This time the attacker responds to the user’s badguy.com DNS request with goodguy.com’s IP address. Since goodguy.com doesn’t respect the host header, the cookies that the attacker set now work flawlessly even though the user is sending the host header of badguy.com in each request. The attacker can’t control cookies on goodguy.com but they can on badguy.com, which is where the browser still thinks it is. The important part here is that the user is now not only on goodguy.com but actually inside the attacker’s account for which the attacker had the cookies (assuming the cookies haven’t timed out or became invalid - and assuming they weren’t in some other way tied to the attacker’s browser/IP, etc…). How this is useful? Well that’s for perhaps another post, but think of this as a great way to perform a certain sub-class of session fixation. The moral of the story - respect the host header, especially if your site has client-based authentication credentials! More about this to come…

Dinis Cruz has a series of posts about the future of his work at IBM and O2 in particular. It starts off with a fictional layout of an application assessment, and why IBM is currently well poised to solve the problem holistically. Then it rapidly breaks down as the posts go on. The problem is O2 doesn’t have a good home within IBM (or at least not yet). Being a project of a pretty substantial size and complexity and having no support model, it stands to reason that it may have some rough times ahead without an executive sponsor. It also makes sense why people may be unlikely to adopt it - without the backing of a more robust team like they would get from a commercial code analysis product.

Dinis has an open call to action to the enterprises at large who need static code analysis on the cheap, and want something more robust in the future. I’ll be curious to see if any big companies step up to the plate here and takes ownership. It’s a bit unclear about Dinis’ fate within IBM - I think he’s a bit on the fence. One thing I do know, IBM would be foolish to let Dinis walk. That’s especially true if it is (according to Dinis’ case which he builds up in his posts) in their best interest ultimately. Who knows, IBM might get their act together before it’s too late. Otherwise, I bet Dinis will find a good home for himself and O2 elsewhere.

Well, I’m finally back with a mess load of blog posts that I’ll have to write up over the next several days. But I wanted to get this one out first. The conference was a lot of fun and very professionally put together, but like always, I’d like to see more developers attending OWASP. I talked a lot with Dinis Cruz about this, and I’d love to hear any thoughts people have on how we could get more developers and/or managers who have budget to throw at the problem to the conferences. I love talking to a lot of experts, but we’re not pushing the industry forward unless we get more people to attend. So thoughts are welcome.

On an unrelated note Dave Wichers from Aspect Security did a presentation on the next release candidate for the OWASP top 10. The most important change in my mind is that now unvalidated redirects and forwards are now within the top 10 release candidate. I expect this to be a contentious issue, but it could mean trouble for a lot of companies. For instance, let’s take these two URLs Google. Consider the following URLs:

https://www.google.com/accounts/ServiceLogin?service=sierra&continue=https%3A%2F%2Fcheckout.google.com%2Fmain%3Fupgrade%3Dtrue&hl=en_US&nui=1&ltmpl=default&gsessionid=8zA6kaO2BqY

And:

http://www.google.com/search?/accounts/ServiceLogin?service=sierra&continue=https%3A%2F%2Fcheckout.google.com%2Fmain%3Fupgrade%3Dtrue&hl=en_US&nui=1&ltmpl=default&gsessionid=8zA6kaO2BqY&source=hp&q=rsnake&btnI=

This is a sloppy example, but you can see that both the login for Google Checkout and the open redirect in “Feeling Lucky” fall on the same domain and thus could easily confuse an unwitting user. So Feeling Lucky could turn into a PCI liability depending on both a) if this version of the OWASP top 10 is ratified and b) if Google’s hopefully unbiased QSA/Bank agree that this is an issue. I’ve always thought redirects were dangerous (especially because Google’s redirects have been actively used by phishers and spammers for years now). But does it belong on the top 10? It’s an interesting question. Another interesting question is if they are on different ports (443 vs 80 like the previous example) should that matter? It could be equally confusing to a consumer regardless of the protocol, and ultimately that’s the how this attack is useful - attacking a user’s perception. If you have an opinion one way or another, I’m sure the OWASP review team would love to hear your thoughts. Anyway, it’ll be interesting to see how this pans out - one way or another.

id sent me a link today about how PGP zip file password cracking on Amazon EC2 could work. I’ve actually seen presentations about cloud password cracking in the past, so it wasn’t new to me, per se, but this is a great writeup on the nitty gritty details. But it occurred to me that finding a command injection vulnerability on EC2 gives an attacker a whole new shiny toy to play with.

By utilizing their command injection within the cloud, the attacker can boost their cracking abilities to unprecedented levels. When id and I started talking about it, he said, “Or you could just use a botnet.” True, but that said, this could even put companies out of business from an economic perspective, as they are forced into much higher utilization than they may have expected. However, id’s right, and yes, botnets are another viable solution to cloud cracking. Botnets are the hacker’s version of the cloud.

This post has been sitting in my to-post-about file for ages. I don’t know why it took me this long since thankfully, it’s one of the few things that I don’t actually have to research to post about (which is rare for me, actually). Anyway, almost exactly a year ago the Microsoft Live Labs group came to me and asked me to check out their web sandbox. Unlike Content Restrictions which is browser specific and still not available publicly, Live Labs tries to solve the problem of allowing rich user content by way of an API that blocks all known bad inputs.

It was written, in large part, by Scott Isaacs, who was one of the original guys who worked on the JavaScript engine within IE - so he knows what’s he’s talking about. The upside is that I wasn’t able (in the admittedly small amount of time I looked at it) to get around the filter. It may be possible to do, especially as technology changes, but it certainly wasn’t straight forward. I’m sure the Live Labs team would love feedback if someone was able to. The down side is that this is an API that you must send your data through. So it’s not on-page entirely, as it must go through a filter that they’ve developed server-side. If you can get around that one barrier, it’s a pretty slick little tool. I’m sure they’d appreciate feedback.

Either I’m just blind or I never actually got into the nitty gritty of testing DNS pinning in Mozilla’s Firefox, but I never realized until today that Firefox doesn’t actually pin DNS at all. I guess you learn something new every day. For a project un-related to security, a customer needed to fail over to another domain, and they wanted to know how quickly they could do that without necessarily taking their primary site offline in the process. So we started doing some tests. Internet Explorer pins DNS for 30 minutes it looks like. Still short in my mind, but according to the documentation I could find that’s because 24 hours or more broke a lot of things (I’m imagining things like Dyndns and so on.)

All the documentation I could find online was erroneous and said that Firefox rebound DNS in one minute. In reality Firefox rebound DNS as fast as the DNS time to live expired. We got it to switch DNS within one second. Meaning there was no need for that trick where you close down the port or firewall off the client IP address or anything similar. Nope, all you need to do is turn down the TTL and you’ve got yourself a DNS rebinding scenario. Seems really surprising to me and makes the whole attack way easier on Mozilla since now all you need is access to DNS and a web server to make it work (no access to anything else required). I don’t know why I thought DNS pinning existed in Mozilla’s browser. Has something changed? Can someone verify?

Just about every conference I speak at someone comes up to me and says, “I’ve been reading your stuff for years, but you don’t write anywhere near as much as you used to - what happened?” Alas, I actually have been writing more now than I ever have before. Just not on this blog. My latest endeavor has actually been the most ambitious writing experiment I have ever undertaken. I decided to write a new book from scratch with no outside additional authors. For those of you who’ve done it or tried it, you know what I’m talking about. I shopped the book around to a number of publishers, but in the end, I decided to pull the publishing rights back from O’Reilly (yes, it was going to be an O’Reilly book for a while) and after working with a few other potential publishers I eventually decided to simply drop the price and make it an eBook.

When I originally started writing the book it’s working title was “The First 100 Packets” because it was going to be all about what you could detect about user intentions within the first 100 packets - makes sense, right? Well, as I wrote it I started thinking that was a worse and worse title because, of course, long term user disposition is a really important and related topic (and just as interesting to me as well). So I up-ended the book and re-wrote a big chunk of it and the title became "Detecting Malice". You can check out the website for a table of contents. Now, why should you buy this book?

What if you could get the equivalent of 500 hours of my brain shoved into one big 300+ PDF book for only $39.95? What if it was written very similar to this blog, in bite sized chunks and from my own voice, so it wasn’t stuffy and boring like a lot of technical books tend to be? I’m honestly very proud of this book and I think it’ll have a lot of value for anyone who is tasked with the horrible job of trying to secure a website, as opposed to breaking into it. As such it’s also not for everyone as it was not written with offense in mind at all. This is not a book to learn how to be a better penetration tester! This is a book for people who want to know how to detect malicious users, and understand user intent through data analysis.

Anti-fraud and fraud loss prevention is an important area of security that I don’t talk about all that much on the site, mostly because security is less sexy than hacking - let’s be honest. I’ve received a lot of flak over the years for not talking about security enough from those who are on the defense side. People have told me that I focus way too much on the hacking side of things and don’t help the good guys out enough. Well, consider this my big contribution to the area of anti-fraud research! Like I said, I’m actually very proud of this book for its technical merits but feedback is always welcome as I revise it and make it better in future revisions.