ha.ckers.org web application security lab

Google Desktop 0day


Google Desktop has had a troubled past. It has encountered tons of security problems with its implementation, and continues to suffer. This time may be a little different than most times, but it is systemic of the same issues. When you attempt to combine web-pages with applications that have any significant power you run into security flaws. At times, however, they really are impossible to see, even by the best and brightest.

This is exactly one of those cases. While Google's security is actually fairly tight, it isn't perfect, and when desktop security is involved, you really do want your products to have the highest quality in security practices. Here is what Google does to protect you:

  • They use one time tokens (nonces)
  • They replace the text on the homepage with an iframe and JavaScript. The code an attacker is after is within that iframe.
  • They make sure that their iframe cannot be called from a page that isn't Google.
  • They try to make the page break if it is too small by overlaying whitespace on top of the iframe.
  • They don't immediately show the Google Desktop iframe on the search results in certain circumstances. I couldn't tell if this was a bug or not but it had to be coded around.

With that in mind, it took me two days to concieve of an attack that is plausible. I created a demonstration that shows what I am doing (in the demo I used burp proxy to simulate a man in the middle, but obviously it would be far less obvious to a victim). Here is how it works:

  • User goes to Google and performs a search.
  • Man in the middle detects the action and proceeds to inject their own content.
  • The attacker injects a peice of JavaScript that creates an iframe to the target URL as well as makes the iframe follow the mouse (typically this would be invisible to the user, but for demonstration purposes I made it visible).
  • He then frames another search query to correctly position the content inside the follow mouse script.
  • As the evil search query loads, he injects a meta refresh to reload the same page forcing Google Desktop to load. In the example video below I am launching hyperterm, but you could make it any program already installed on the victim machine that is indexed by Google Desktop.
  • User inadvertantly clicks on evil Google Desktop query which actually runs the associated program.

Watch the video to see a demonstration. The demo does not try to hide what it is doing by making the overlay visible, but this is a demonstration of how it works, so you can see each component. In the video, as mentioned, we launch hyperterm.exe, although we could have launched almost anything you can imagine, including programs that connect out to the web, uninstall programs, etc... We stopped once we realized we could do this much damage, but we are certain this could be used for far more nefarious things.

This should drive home the point that deep integration between the desktop and the web is not a good idea, without tremendous thought put into the security model. As Google's site is unencrypted, and they place their content that can run executables on their site, it can be subverted by an attacker.

Mitigating factors: Obviously this has two big caveats to it. The first being that the attacker is sophistocated enough to launch a MITM attack against you similar to how Airpwn works. The second is that you have Google Desktop installed. To avoid these issues, only use trusted networks while Google Desktop is installed, keep it from indexing certain dangerous files or uninstall it completely.