Slashdot Mirror
Cache Servers Keeping Exploit Code Alive
1960's architecture writes, "At last some evidence that exploit code is hiding on servers used to cache website content. According to Techworld, Israeli outfit Finjan has come up with evidence that real exploits have hidden on cache servers used by large search engines, effectively extending their life for periods of weeks after the original website had been taken down. The exploits detailed are from 2003-2004, but the principle would still apply to any exploit website around today, and any cache servers used by any one of the three unnamed search engines. It's almost literally malware 'life after death.'"
why erase it?
The brilliant study says: "content available as cache, even after the original source is not there, for some time"?
Bravo! Bravo! Revolutionary thought!
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Great.
1. use google code search to find security holes
2. use google cache to exploit it
3. profit!
What's the use of relying on a site been taken down?
You should patch your software in any case, otherwise the exploit still works if it is put somewhere else.
Hey sucka, gimme your cache!
Exploits from 2003 and 2004? You've had 2 years to patch your systems. Don't cry.
Blar.
How about fixing the problem that's exploited rather than try to hide the problem's existence in the first place?
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
gimme a break, a cache is a cache, it's supposed to have old information, even if that information is wrong, or destructive.
any one of the three unnamed search engines.
There's more than one search engine?
i guess i'm going to show my complete ignorance of web development and teh intarweb at large, but here goes:
why on earth would something get cached if it is malware infected/contains exploits without being cleaned at some future time when said malware or exploits are discovered?
i know the caching is an automated process, but the caches themselves aren't scanned for malware/code exploits like the live sites?
This space intentionally left blank
Exactly. It's as if they're claiming you can use old, fixed exploits because of caches somewhere. A cache is like a photocopy. Is anyone suprised that the photocopy exists after the original is lost? Isn't that the whole point?
Blah
Yahoo's cache can be addressed at rds.yahoo.com (compared to Google's cache, which uses IP addresses with no associated hostnames). Thus, all the various message boards that use the slashdot style of putting the domain name of the host will show yahoo.com even if it might be serving up an IE exploit that was hosted at mynastystuff.ru, increasing chances of click through. MSN uses a resolvable name for their cache as well, but it's at least identifiable as msncache.com rather than just msn.com.
Nothing for you to see here.
Just us trojans invisibly taking over your system.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Since when has an exploit been considered malware?? If you publish your source code with a password in it, don't get mad that google code search can find your password - change the damn thing and get it out of your source. Same goes for any other source code bug or published exploit.
I think the real issue here is that people don't want a history of how they fucked up. Those that don't learn from their history are doomed to repeat it...
[...]
//Information does not want to be free; it wants to breed.
Think Microsoft has patched them yet?
Thhis is idiocy.
Content is kept on cache servers, not the actual application to be exploited.
The cache server isn't executing the code with register_globals on it, its simply saving the results>
I thought that if an exploit was discovered, systems that could be infected were patched, rather than worrying too much about the virus itself staying in the wild.
Sure, a lot of caches can keep very old content (the Wayback Machine www.archive.org would be a good example). But spread infection is mainly prevented by immunising systems, not by removing all known traces of the virus / trojan / etc. Bacteria and viruses can live in harsh conditions (relative to those that they require to thrive) but immunisation is how we battle them. Sterilisation is a big part of localised treatments (small to medium sized networks) but impractical across the whole net.
So this is hardly big news is it? Caches holding copies of *content* people want to suddenly make unavailable, now that's an issue.
Conversion Rate Optimisation French / English consultant
Why don't we try to regulate this pesky internet annoyance as well like we did with the Can Spam act? We all know how good that worked. "All sites hosting malicous code are now required to include the tag in their pages or face harsh whining from everybody else"
Exactly. The people behind this "discovery" seem to think that the best way to combat security holes is to go after the exploit demonstration code, rather than, say, actually fixing the problem.
That's what's really frightening; that there are exploits that have been in the wild and in the hands of the black hats for three years, which still have not been patched.
Those "exploit sites" are not the enemy here. If anything, they're a powerful tool that lets the 'good guys' be on equal footing, or near equal footing, with the bad guys, who are probably trading exploits around in IRC channels regardless of whether they're on the WWW or cached or not.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Its important to cache, so you can find jems like this!
<META NAME="msnbot" CONTENT="noarchive">
Done.
There are no karma whores, only moderation johns
All your base are belong to us.
Even after we are dead.
Yeah, if you're running your vulnerable server code out of the same cache. ;-)
That's because removing the content doesn't combat the threat at all. Fixing the bugs that allow malicious code to work, is the only way to combat the threat.
It is useless to try to put genies back into bottles.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
After 11 years in the software industry there's too much red tape, bureacratic nonsense
tied up in upper management that has no idea what to do, except keep their jobs.
A kid may write on their xanga about how drunk they got thursday night, then decide to take it down saturday, but it's always possible a future employer could come up with it anyway. Likewise, developers should assume that any exploits that have ever been mentioned on the web will always be available to anyone who wants them. Once has been published on the web, you can't make it disappear. End of story.
So, does the Wayback machine keep exploits forever?
Excuse me, but please get off my Pennisetum Clandestinum, eh!
This article has (here on /.) already raised the question "Why can't we stamp out the viral code from archives?" Well, let's take a lesson here from biology.
c le/2006/10/04/AR2006100400127.html). The problem? You simply can't squash all the bugs. Only recently has attention turned to developing an artificial method of immunity from the disease, so that the bugs won't matter (at least, from that perspective).
The human race took two different solutions to polio and malaria. (I'm not a doctor, so forgive any minor inaccuracies.)
With malaria, we took the "stamp out the viral archive" approach. We tried to kill the carriers - the mosquitos. If we can eliminate all the mosquitos that carry the infection (like eliminating old internet caches), nobody will have to worry about getting infected. Well, guess what - it didn't work. Malaria is a HUGE problem in many third-world countries, routinely killing a million Africans a year and costing $12 BILLION annually in Africa alone (see last week's WashPost Magazine article for details; registration required: http://www.washingtonpost.com/wp-dyn/content/arti
With polio, we took the approach that preventing infection was the key. We innoculated EVERYONE, so that even if the virus surfaced, it wouldn't cause infections. It's proven to be a largely effective solution, with only a few periodic pockets of infection occurring in remote parts of Africa where the youngest are not innoculated afresh. And that problem is fairly easy to control.
Same thing here. Forget the archives. That's naive. Instead, focus on better immunity.
--Brandon / Split Infinity Music
So what? I find exploit code all the time, week, months, years after the fact. It's called Packet Storm Security or elsewhere.
Hell, google.com cache pages are great for shit like this.
Here's a long-view perspective though. In my research (chemistry) I use a 486 almost daily. The computer is infected with an old innocuous boot-sector virus, and I simply don't remember enough DOS/486 era stuff to put on a proper antivirus solution without seriously diverting my research in the short term. Luckily, my modern-era computer is solid vs. this old school virus - this is the other reason I haven't bothered fixing the old one. If this were a nastier virus, and my AV protection didn't go back far enough, I'd be in trouble. I think this scenario is where the problem lies (now and in the future) - how retroactive do we need to be with AV? In 20 years, it's conceivable to me that malware writers will start focusing on more esoteric classes of victims (such as science laboratory Win 98/NT/XP computers - they're generally networked on fast connections, unmonitored for long periods of time, and likely to be mentally written off as "not my responsibility", especially re: hardening vs. decades old attacks).
In summary, security-through-obsolescence is as big a fallacy as security-through-obscurity, and the article point out that just because the tech is obsolete doesn't mean the cracks will be...
But is it almost literally, or literally almost? What would make it true life after death? (Literally)
To the tone of a speech by a famous U.S. General --
"Old (xxploits) never die, they only (hid) away (in proxy cache...)"
ELOI, ELOI, LAMA SABACHTHANI!?
Does anyone else remember when if you wanted to be sure something would remain available for a few weeks, you just posted it to usenet?
Cut that out, or I will ship you to Norilsk in a box.
Trying to get something off of the internet is like trying to get pee out of a pool.
Why not just patch the vulnerabilities? If publishers would fix their shortcomings then it wouldn't be an issue.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
I didn't RTFA, but could there be a day in the future when somebody writes an exploit to find cached exploits?
I think I just died in a fit of irony...
this actually is a security hole in itself. If U add the logic for checking the version of any web app and not letting it interact with anything at all it if it isn't the latest version, then problem solved. More excuses from lazy programmers that want to blame someone else.
Is it just me or is it not going to upgrade to Vista in here?
My former boss said back in 1997, "Whenever you put up a web page, you've just joined the PR department." A reasonable corollary might be, "Whenever you put up a web page, you've just created a PR department for yourself." Think about it.
$nice = $webHosting + $domainNames + $sslCerts
What about this link to the Python website. Using redirecting urls on websites can be pretty dangerous. Many other websites like microsoft.com have similar features you can take advantage of.
You don't fix security holes by trying to track down all the code that exploits it on the web, you fix security holes by fixing the software containing the security hole. So, it doesn't matter how long this stuff stays in anybody's cache.
The submitter needs to watch his terminology. When I hear "exploit code" I think "code which produces an exploit for a given vulnerability when compiled/interpreted". When I hear "exploit" I think of something which leverages a security hole to run code or gain privileges.
.C or .PY modules are being cached is a newsworthy headlines. But what they're *really* talking about is exploits for client-side browser bugs surviving in caches, which is vaguely interesting, as often code written in a scripting language (which may or may not be cached) is required to exploit these vulnerabilities.
So from this perspective, it's utterly bizarre why the idea that a bunch of