Threat Level: green Handler on Duty: Basil Alawi S.Taher

SANS ISC: InfoSec Handlers Diary Blog - The Other iframe attack InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

The Other iframe attack

Published: 2008-03-15
Last Updated: 2008-03-17 18:54:18 UTC
by Kevin Liston (Version: 3)
0 comment(s)

A lot of readers are sending in this link from Dancho Danchev's fabulous blog thinking it's linked to the 2117966.net campaign: http://ddanchev.blogspot.com/2008/03/more-cnet-sites-under-iframe-attack.html

We're also getting this sent in from McAfee's Avert Labs blog: http://www.avertlabs.com/research/blog/index.php/2008/03/13/follow-up-to-yesterdays-mass-hack-attack/

The 2117966.net campaign affected approximately 13,800 ASP pages.  No php pages.

This other attack is reported to have affected around 200,000 phpBB pages.

It's a bigger attack and very important, you should read Dancho's blog, it has IP addresses and domains to look for in your logs as well as what traffic an infected system will generate.

If you're a website administrator, also take a close read of his 04-MAR-2008 entry: http://ddanchev.blogspot.com/2008/03/zdnet-asia-and-torrentreactor-iframe-ed.html

Pay particular attention to how they're inserting the code into the site (from Dancho's Blog):

"(The sites) themselves aren't compromised, their SEO practices of locally caching any search queries submitted are abused. Basically, whenever the malicious attacker is feeding the search engine with popular quaries, the sites are caching the search results, so when the malicious party is also searching for the IFRAME in an "loadable state" next to the keyword, it loads. Therefore, relying on the high page ranks of both sites, the probability to have the cached pages with the popular key words easy to find on the major search engines, with the now "creative" combination of the embedded IFRAME, becomes a reality if you even take a modest sample, mostly names."

This is important.  It's not obvious to me how to fix the problem-- I'm hoping that someone can explain this better.

The writeup at finjan is more readable to me:  http://www.finjan.com/MCRCblog.aspx?EntryId=1905

So we have massive XSS exploitation at work here.

Update: added finjan link that identifies the compromise vector as XSS

 

Keywords:
0 comment(s)
Diary Archives