ha.ckers.org web application security lab

Death By 1000 Cutts Case Study


Overview: This is a second case study based in parody of the name of the original Death By 1000 Cuts case study. However, this case study, instead of focusing on hacking a single domain, has a lazer focus on only hacking a single person on the Internet, Matt Cutts (hence the name of the case study, Death by 1000 Cutts). Using a series of small and large issues in tandem, I will show how a single user can be compromised from a targeted domain.

Preface: I did not actually compromise Matt Cutts, nor did I stalk him, visit his house, pet his cat or anything else of the sort. I really couldn't care less about Matt Cutts, he was just the target I chose. Why did I choose him? Because Matt Cutts is the search guru behind Google and heads up their webspam team. As a result, he is a prime target for blackhat search engine hackers. This makes him an ideal target of choice - not just of opportunity. I should note that we get tens of thousands of users a day hitting this site, so it properly represents the type of traffic that would hide a user amongst the noise.

Recon: Let's start with what we know about Matt Cutts just from the occasional read of his website, and from watching a video or two that he put on Youtube. Firstly, we know he works at Google, secondly he is middle aged, he is male, he lives somewhere around Palo Alto, he has one or more cats and he has a blog. Not exactly a lot to go on, however, one day Matt Cutts makes a huge mistake. He posts to my blog.

It was a simple post talking about some old redirection hole that Google finally got around to fixing. However, I don't need much more than that, as it turns out. His browser has touched my website, that is often all an attacker needs, if I know what to look for. Let's look at his posting:

It appears Matt Cutts is using the most current version of Firefox (at the time). There really isn't anything else interesting about this, so let's take a look at some of his other traffic for the day:

Well it looks like Matt Cutts has made a few tremendously huge errors here. Firstly, he has shown me referrers of other sites (including a sla.ckers.org post that describes another Google XSS vulnerability - they have a lot of those to keep track of). You will also notice that Matt Cutts pulls images, CSS and JavaScript files when he visits hacker sites. Probably not so smart. We'll get back to that in a while.

The most important point of this is that you can see that Matt Cutts has also come into my site from Quadzilla's site. I happen to know Quadzilla (and even if I didn't, I could have broken into his machine) so pulling his logs from Quadzilla's machine was as simple as sending an email. Let's take a look at those logs for the same day:

The most interesting line in this log is the POST request. It turns out that Matt Cutts has created himself an account on Quadszilla's server. Oh for shame! Now we have Matt Cutts' username (he chose a really unique name that no one would suspect - MattCutts), email address for his school and password. Let's assume for a moment that Matt Cutts is smart enough to never use the same password twice, and that I couldn't use that to mount an attack against other systems that he might have access to. I mean, he does create accounts on blackhat sites and use JavaScript, but I'll give him that one.

Google Stalking: Okay, let's step back and start doing some Google searching for Matt Cutts. There is bound to be something interesting out there. Lo and behold we find that he has a Myspace profile (it turns out this is not his). While not particularly interesting, and actually misleading since it is not correct, it does give us one more peice of information other than his marital status (Married). It also gives us his birth month and age. (1965 - 41 years old and a Virgo). If it were correct it would have given us only 30 possibilities to guess his birthdate, which is often used in secret questions. However, this information is erroneous. Again, let's take a step back and look at things we know.

We know he is located somewhere near Palo Alto because he says he lives there and he says he works at Google - both we have to take on faith. So after some queries to some various Yellow Page style directories we find out that the only Matt Cutts actually lives in the Los Altos Hills (a mile or so from Palo Alto). Ahhh, Matt Cutts likes to lie. Thankfully we have now found his address. With that we can find his home valuation through tools like Zillow (he has a 5 br 6.5 bath compound) and his commute to work (since we know he works at Google). Wouldn't it be nice to have a 4 mile commute to work?

We also find his home phone number, his work number and address, and some other fun facts like stuff like the two colleges he attended (which might yield more attack points since he still uses his college email account and colleges are notoriously poor at securing themselves). Lastly we find out about his DoD clearance. Okay, so I could go break into Matt's house and steal his computers if I wanted to. I'm sure some people might resort to something like that, but not me.

Some other places Matt visits: During my research I found many other places that Matt visits. Each of these sites could have turned into potential targets depending on how secure or insecure they are:

Alright, let's get back to the hacking: It would appear that our leads are all pointing to having to compromise some server somewhere, or attack some web application that he has an account with, but rather than do that, I'd much rather attack him directly, my computer against his computer. Thankfully in re-inspecting my logs I found this tidbit that made my day:

Wait, Matt Cutts uses Google Desktop? I don't think he reads my blog enough. People often ask me why knowing what a user is running is valuable. For once I can finally answer that question in painful detail. Google Desktop is vulnerable to anti-anti-anti DNS pinning. What is that? Well here is a primer on it so that we can proceed:

DNS Pinning: Let's start simple When you start your web-browser and point it to a location (a URL) you type in an address. Let's say you type in www.example.com. www.example.com unfortunately means nothing to a web-browser because there is no way to associate that with a machine name. So on the back end it uses DNS (domain name service) to query the IP address of the host in question. Let's avoid any complexity about network address translation or any other reverse proxies. Let's just keep this simple. The IP address points to a server. That server listens on a socket (generally 80 or 8080 or 443, etc... for webservers).

When your browser connects to the IP address (111.111.111.111) of www.example.com it sends a header, which looks something like this:

GET / HTTP/1.0
Host: www.example.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: */*
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: super-secret-decoder-ring-number:54321

The Host: header tells the server that the user is looking for data at the www.example.com virtual host, if the machine happens to be running more than one web server on that webserver instance. What an attacker is after is the data that is returned to the user from www.example.com. The browser does something to protect itself at this point, which is called DNS pinning. DNS pinning is where the browser caches the hostname to IP address pair regardless of how long the actual DNS time to live is set for. Let's show an example of an attack that will not work:

The attacker runs www.attacker.com which is a malicious site. The malicious site points to IP address 222.222.222.222. The attacker sets the DNS timeout for one second. When the user views www.attacker.com in their web-browser the IP at this point points to 222.222.222.222 but on that same page is a piece of malicious JavaScript. That JavaScript says to connect to itself in two seconds and pull data from the page it sees. Once that data is seen it should be sent off to www2.attacker.com which points to 333.333.333.333. So here's how it works.

  • User goes to www.attacker.com they see 222.222.222.222 with a DNS timeout of 1 second.
  • The user's browser's sees the JavaScript which asks them to connect back to www.attacker.com in two seconds. The problem (theoretically) is that www.attacker.com's IP address is no longer valid (it really is, but I'll get back to that in a second).
  • Then the user's browser connects to the DNS server and asks where www.attacker.com is now.
  • The DNS now responds with the IP address of www.example.com, which is 111.111.111.111.
  • The brower connects to 111.111.111.111 and sends this header:
    GET / HTTP/1.0
    Host: www.attacker.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: */*
    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

(Notice the cookie is no longer there and the Host: is now www.example.com). Not particularly useful because the hostname doesn't match (that's not a big deal since most sites don't run more than one virtual host) but more importantly the cookie is missing. Lastly, and the deal breaker here is DNS pinning. DNS pinning in the browser prevents the second lookup of the IP address (111.111.111.111) because the browser is attempting to protect the user from anti-DNS pinning. So, that technique doesn't work, thanks to good old DNS pinning. (This is also the reason you must flush your DNS cache (ipconfig /flushdns) or shut down your browser whenever you modify your hosts file or change the DNS of a server). And the world was safe...

Anti-DNS Pinning: ...or was it. Martin Johns posted a message about Anti-DNS pinning. It was a pretty useless technique before Intranet port scanning, but suddenly due to some of the stuff Jeremiah and I built, it became far more useful. I'm getting ahead of myself. What Martin was able to show is that browser DNS pinning relies on one simple fact (at least MSIE). That simple fact is that the server in question is up. If the server is down, it stands to reason that you should query DNS and see if it has changed or moved.

Great idea for usability, terrible for security. You remember why we had DNS pinning in the first place right? Well the assumption that the server will never be intentionally down is a fine when you are thinking about a benign site, but when you are thinking of a malicious site, it can be down at a whim if the attacker wants it to be. So here's the trick:

  • User goes to www.attacker.com they see 222.222.222.222 with a DNS timeout of 1 second.
  • The user's browser's sees the JavaScript which asks them to connect back to www.attacker.com in two seconds.
  • www.attacker.com firewalls itself off so that it cannot be connected to from the IP address of the user.
  • DNS pinning is dropped.
  • Then the user's browser connects to the DNS server and asks where www.attacker.com is now.
  • The DNS now responds with the IP address of www.example.com, which is 111.111.111.111.
  • The brower connects to 111.111.111.111 and sends this header:
    GET / HTTP/1.0
    Host: www.attacker.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: */*
    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
  • User's browser reads the data and sends the data to www2.attacker.com which points to 333.333.333.333.

So that was only mildly useful because what's the difference between that and an attacker just requesting that page himself? Since the cookie isn't there, that's not doing the attacker any good. However, where it is interesting is with Intranet scanning. Let's say that instead of using www.example.com pointing to 111.111.111.111, we are instead interested about intranet.example.com (a private page hosted behind a corporate firewall that we cannot access). intranet.example.com points to 10.10.10.10 (RFC1918 address space).

Suddenly we can get the user to connect to internal addresses where we would never have been able to connect to ourselves. Not only that, but we can read the data from the pages that are not accessable outside a firewall. Crazy! You might call me a conspiracy theory type, but I think it's awfly interesting timing that Martin came out with that exploit, immediately after Jeremiah and I released our Intranet scanner. Oh well, no one will ever know. But anyway, it seems like we've come up with the perfect prevention method to that hack, right?

Anti-Anti-DNS Pinning: Wrong. There is one technique to stop this issue, which to look at the Host: header. Remember above where the host header doesn't match the host in question. That's fine if there are no virtual hosts, but if there are, this falls down. Further, if you make the generic IP address ignore any requests that don't match www.example.com DNS pinning falls down.

This happens a lot on shared hosts, virtual hosts, etc... it would appear that Anti-DNS pinning has a major hole in it. If you can't query the server for the hostname, you don't get to read the data. So sure, that's great for doing port scans like Jeremiah and I were attempting to accomplish, but it's pretty much worthless for stealing information from intranet web-pages. Or is it?

Anti-Anti-Anti DNS Pinning: Are you kidding me? Of course we found a way around that. Amit Klien published a small email to bugtraq discussing a way to forge the Host header using XMLHTTTPRequest and through Flash. This proves that simply looking at the Host header won't do much to stop Anti-DNS Pinning. Tricky, I know, but the point is you are accessing the same domain as far as the server is concerned, so you are allowed to pass whatever information you want to the server and retrieve it as such.

Back to Matt Cutts: Now that we know what anti-anti-anti DNS pinning is we can attack Matt Cutts directly, because we know all the critical facts that we need to know about him. We know a) his IP address b) his browsing habits c) what type of browser he uses d) what type of software he runs on his machine and that e) he renders JavaScript when he visits websites. Although anti-anti-anti DNS pinning is a tremendously difficult attack to mount in this case as it requires that I find an XSS vulnerability on Google to read the nonce that Google Desktop uses to secure itself, in this case it could easily be worthwhile given how much information Matt Cutts has access to.

The attack: So mounting the attack requires only that we get Matt Cutts to visit my site, deliver a custom JavaScript file to his IP address that mounts an XSS attack against Google's website (of which there have been dozens found). That XSS delivers the Google Desktop nonce to a domain we have set up specifically to create an anti-anti-anti DNS Pinning attack against Matt Cutts' Google desktop running on his local drive at 127.0.0.1:4664. That then allows me to read all of Matt Cutts' email, his files, and his browing history. At this point that we have successfully hacked Matt Cutts with 1000 cuts. The only trick to this is getting Matt Cutts to visit any website under my control (which happens to include any website with an XSS hole that I can get him to click on - which turns out to be surprisingly easy).

Lessons learned: If you work at a large company, you are a potential target. As Matt Cutts is an unofficial spokes person for the company, he can expect to be targeted more often than most employees. In this case, Matt Cutts has insiders in a number of locations (we've seen him pull files from places he should have no knowledge of or access to). This being said, he has access to more information than almost anyone in the search industry that would be of value to search engine hackers or anyone looking to know more about Google or somehow influence their own search rankings.

Through a series of small issues, we were able to locate literally dozens of potential attack points, before deciding on the most direct path, however there are literally a dozen places that we left untouched that we could have used to mount our theoretical attack. Knowing things about his system allowed us to mount a highly targeted attack that would certainly work against him in particular, knowing what we know about his system. True, the final attack leveraged a hole in browser technology as well as a hole in Google Desktop, however neither would have been possible without the prior recon to know to target those issues.

Back to the homepage.