Attackers booby-trap searches at top Web sites

Updated at 11:22 a.m. PDT Saturday to include a comment from Wal-Mart.

A million search queries have been "poisoned" at dozens of well-known Web sites over the past several weeks, according to security analyst Dancho Danchev.

Attackers are using programming errors to hijack keyword searches by automatically attaching malicious HTML code to specific search queries. Unwitting visitors who type in the selected key words while performing a search at the affected sites are then redirected to booby-trapped Web sites.

This is where the attackers attempt to install malware onto the victims' computers.

Among some of the Web sites that have been attacked are USAToday.com, Target.com, ABCNews.com, Walmart.com, and several sites owned by CNET Networks, the publisher of News.com. A CNET employee confirmed that the attack had occurred but did not know to what extent it had affected site visitors.

Representatives of CNET and USAToday could not be reached on Friday night. Wal-Mart spokeswoman Amy Colella on Saturday said the matter "has not impacted our site in any way," adding, "We take these matters very seriously at Walmart.com, and continuously use measures to protect our customers from any fraudulent online activity."

The attack differs from other IFrame injection attacks in that the traps are being set in the search results and not on a Web site's main pages, said Joris Evers, a spokesman for security firm McAfee.

"This means that a Web user would need to do a search query using one of the terms picked by the attacker to hit a poisoned page," Evers said. "This is in contrast to previously seen attacks where just visiting a site would launch an attack. This reduces the severity (of the most recent attack) somewhat."

Evers added that the Web is quickly becoming one of the most popular means to attack users. This is due in part to improvements made to e-mail security and filtering and also because Web vulnerabilities are a new frontier, he said.

[Leria]

This is frightening

And I am wondering how these crackers were able to pull this off, without anyone noticing that there was 'extra code' in the search results.

[kLevkoff]

How it was done - short answer

The short answer is that, apparently, a BUG in the search engine code allowed the hackers to substitute their own fake result pages for the legitimate ones in the outgoing cache for the search engines in question. So, when you sent a query that had been recently done before, and the site returned the copy of your result page in their cache to save time and effort, they instead returned the fake one provided by the hackers. This substitution was achieved using some sort of security FLAW in the web site or search engine code itself.... a flaw which SHOULD have been discovered and fixed if the software was properly tested.

[kojacked]

The neighbors will be calling...

Great! Another weekend of fix every computer in the neighborhood... <br /><br />Instead of the government looking to tax us for music on behalf of the RIAA how about they use OUR money to catch and imprison these guys instead?

[Stating]

Use Firefox With Noscript

This is why I use Firefox with Noscript. By default any new site I visit has Java, Flash, etc. disabled.

[eingram1]

Firefox

Yes, but think of all those entertaining ads you're missing

[umbrae]

Great Tools

NOSCRIPT and COOKIE SAFE are great plugins for Firefox. Only problem would be whitelisting a site that is compromised. SO be careful what you whitelist and when.

[millionmade03]

This is true

i have used no script on my Firefox and i have not seen any spy ware on my computer since also i have been using no script for almost a year. I just don't need to run it in Linux just on my "windows" systems

[ejevo]

I dare you to get people to do that

Most web surfers won't last 5 minutes with NoScript, Flashblock, etc. all in place and preventing content from appearing. Most web sites lose important functionality when those items are in place. Protected? Sure. Usable and practical? Sadly, no.<br /><br />We need a better way.

[WJeansonne]

Need to pull arms and legs off of hackers

while they are still alive to set an example. These evildoers need to be siezed with an eye for eye.

[kLevkoff]

iFrame injection - just FIX the BUG

I agree that the people who launch these big attacks should be retaliated against - and ninjas with black masks and poisoned darts seem quite appropriate to me - preferably in the dark of night with orders to leave no survivors.<br /><br />The fact remains, however, that they are only able to do this because the web site software is BUGGY. I am tired of hearing about "scaling defenses" and the like, followed by all sorts of questions about "blocking the attacks". The "defense" is to fix your code so the bugs are no longer there, then apply enough QUALITY CONTROL to prevent it from happening again. This is happening because of a BUG; inputs are apparently NOT being properly and fully validated, which is something that any decent programmer supposedly learned to do in school. What's to scale - replace the defective code containing the exploit with new code that works correctly and the problem is gone!

[kLevkoff]

Who's the victim, and who's the problem?

I agree that the perpetrators are, well, the perpetrators, but I believe that a major portion of the blame rests with the Web sites - after all, it IS their defective code that allows this exploit to work. Virtually every posting I've seen seems to ignore the fact that none of this would have happened if the code used by the Web sites themselves was well written, well tested, and working properly. <br /><br />The bad guys were able to get in because basic security precautions, the kind that any first year programmer SHOULD be aware of, were apparently not correctly implemented in the code. The Web sites attacked were NOT "innocent", they were neglectful and they ARE partly to blame.<br /><br />If the sites were using search engine code written by someone else, then the creators of the code are responsible for selling or providing defective and insecure code, and the sites themselves are responsible for using code without testing it - and risking the security of their customers as a result of their sloppiness.....<br /><br />Lets stop talking like they did everything right and got "blindsided" by this.....