Resurrecting Zombies

The title of this article sounds almost like the title of a low budget horror movie but I couldn�t help myself. So, today I want to talk about zombies and how they can be resurrected from the crypt. In this case the crypt is Google Cache, Yahoo Cache, MSN Cache and many other online CACHING services.

I will be as visual as possible.

First of all let�s explain the definition of the word zombie. According to Wordnet, zombie is a dead body that has been brought back to life by a supernatural force. On the other hand, zombie is also a machine that has been taken over, maybe by a supernatural force but I am not going into that. In this article I refer to zombie as a webpage that contains malicious JavaScript code, maybe a worm.

Once the worm/zombie has been discovered administrators and computer security enthusiasts will write signatures and tools that could help to clean up after the mess. That used to be the traditional model used by our fathers:

The zombie/worm has a head. Cut the head. The worm dies. Now clean up!

Unfortunately, the Web tries to mimic utopian way of life. Everything is there and nothing is lost. Vendors like Google, Yahoo and Microsoft prove to be quite good infrastructures for launching all kinds of web related attacks mainly because of the functionalities they provide. Apart from their APIs that give just too much power to harmless JavaScript codies, they have crypts of dead web content. They call it the cache.

You know what will happen when dead bodies are left unburied for too long; they develop diseases.

So, even after the infected are cleaned from the menace, attackers are still able to resurrect the zombie from the crypt and use it over and over again to spawn other zombies. I wonder when Google, Yahoo and Microsoft will start cleaning up their crypts.

Comments

maluc responds:

uh, i’m not sure what you mean? finding sites that were infected with a worm, cached by google, then deleted the bad script without closing the vulnerability that let the worm in in the first place? I suppose that’s possible, but won’t the cache get overwritten once google re-crawls it?

I think it would find the bulk of sites being false-positives that patched the web app.. so i’m not too convinced how useful data-mining the search engines’ caches would be.

-maluc

pdp responds:

The point of this article is to show that web worms cannot die that easily. They can be removed; however users who are attending Google�s cache on an infected URL will resurrect the worm. That will start another propagation cycle. You are right that the cache will be updated at some point but the question is when. Google and other vendors who cache web resources are highly inconsistent. By the time they re-cache the worm will hit even more resources.

maluc responds:

ah, i see what you mean then .. but then the attacker still needs to restore the head somehow to the exact same place. I think it would be much easier to just start up another strain of it, infecting the same vulnerability. The same way you see non-webapp worms come out with 20 different versions: i.e. MyDoom.A MyDoom.B MyDoom.C.. MyDoom.T etc.

And by the way, you might want to take a look at Xoomle’s source code: http://www.dentedreality.com.a.....Le-2.0.zip .. As it uses the Google API to return much more than the 8/10 maximum. Here’s an example returning 40: http://xoomle.dentedreality.co.....MLe+Search

They do it with four separate calls of 10 .. but i’d be interested to know how they did, as i didn’t think Googles API supported offsets.

-maluc

pdp responds:

Well, the head could be Google AJAX Search. That makes the worm a whole lot more modular and self contained.

Xoomle is good but not that special. They are using the Google API SOAP Interface and style the result into their own XML format. That can be quite trivially achieved with Netcat and the XMLStarlet Command Line XML Toolkit. The problem with Xoomle is that there is no way, unless you use the proxy technique discussed here, you can read the result of the query. You see, it is a different domain; the same origin policy applies.

Google API supports offsets. Check Massive Enumeration Toolset. The library is a bit outdated but still usable. I am planning to update this tool soon.

maluc responds:

Ah, i didn’t know that the Google API supports offsets at all. So it’s just in JSON that it doesn’t support it?

And I know xoomle can’t be used like that.. i only mentioned it because i didn’t know how it was able to use offsets..

By the way though, any XSS hole on the search engines domain will let you use it with the same method for proxies (2 iframes) .. yahoo and google are hard to find XSS holes in, but the rest tend to be easy/moderate.

-maluc

pdp responds:

maluc,

By the way though, any XSS hole on the search engines domain will let you use it with the same method for proxies (2 iframes) .. yahoo and google are hard to find XSS holes in, but the rest tend to be easy/moderate

Maybe I misunderstood your statement. A XSS hole is not required to launch an attack similar to the one described in here; only a public proxy/translator.

pdp responds:

Aviv,

I read the report and it has nothing to do with what I am saying in this article. If I am not mistaken they are talking about caching services such as Squid. I am looking at the other end of the pipe… Google Cache and MSN Cache.

maluc responds:

Yes, i know an XSS hole is not ‘required’ .. it’s another option. Instead of going through a proxy, you can go directly to the page by making use of the XSS hole.

This has the added benefit of not all coming from the same IP. Can make a worm harder to spot from googles perspective. (Google could use automated heuristics to say that “If one IP searches for the same thing 10 times in a minute, block future requests”)

Just another alternative to proxies and api’s..

-maluc

Aviv responds:

pdp,

No they are talking about caching services like Google, Yahoo, MSN, etc. and also ISP caching services.
(“..Malware housed on storage and caching servers, such as those used by ISPs, enterprises, and leading _search_engines_, continues to pose a risk after websites containing malicious code have been pulled….” – http://www.theregister.co.uk/2.....ware_risk/ )

They already notified the vendors, so they probably found this long ago.

pdp responds:

Ahh, ok…

GNUCITIZEN

Navigation

Resurrecting Zombies

Comments

Respond

The Others

External Projects

Recent Posts

Random Posts

From The Cutting-edge Network