A Second-order of XSS

Posted by Gunter Ollmann on April 01, 2008 at 8:00 PM EDT.

Several people have approached me for more information about the spate of search engine iFrame injection attacks that have been occurring for the last few weeks. Dancho Danchev’s blog entry provides a good primer of the threat observed thus far, and lists some of the popular news sites that have been hit with the attack thus far. The USA Today story seems to be getting quite a few hits as well, and contains some further insight from X-Force on the topic.

While there has been a lot of attention upon the fact that the Google search engine is acting as the conduit for the attack, let’s be clear, the vulnerability itself doesn’t lie within Google (or any of the major search engines). At its heart, this is the widespread exploitation of simple cross-site scripting vulnerabilities situated within the Web sites application parsing of "searched-for" content.

Effectively, a number of sites (the most notable being USAToday.com and ABCNews.com – with more listed on Dancho’s Web site) incorrectly parse content retrieved from Web browsers as users visit their Web site, and that their Web application dynamically incorporates that data (in this case a malicious iFrame) in to the page content and URL’s. The attack vector is sometimes termed second-order cross-site scripting and you can read a paper I wrote back in 2004 on this and related vectors at Technicalinfo.net as to why it works.

In this current attack the initiation vector appears to be picked up from the REFERER field of the Web browser as the vulnerable Web site parses that REFERER information for the search words and renders them in to URL format (this is part of the vulnerable Web applications “Search Engine Optimization” phase).

This type of vulnerability should normally be picked up by most Web application vulnerability scanners, and will almost certainly be identified during any consulting-based penetration test – so I’m a little surprised that many of the sites identified thus far are actually vulnerable to this attack because I’d have expected them to have invested in a regular pentesting regimen. Luckily, this particular mass-attack vector is pretty easy to correct and I see that several of the (previously) vulnerable sites have now been fixed.

Organization

An interesting aspect of this particular mass-attack threat is its organization.

The attackers have obviously been searching out and testing these vulnerable Web sites for quite some time.

Mind you, identifying sites that are vulnerable to this particular attack (i.e. the vector being used at the moment –
blahblah.com/app/default.php?search=Obama+President+%3CIFRAME%20SRC=//… ) are pretty easy to spot – and consequently easy enough for the popular search engine providers to identify probable attacks and remove them from returned search results (So, hats off to Google etc. for taking charge and working to preemptively protect users who might have unwittingly been about to visit a vulnerable/exploited web site).

The actual malicious content within the iFrames linked exploit scripts is pretty standard stuff – related in a sense to the IIS/ASP/SQL mass-defacement iFrame injections we’ve been seeing over the last few months.

Search Engine Focus

Of critical importance in this attack is the role of the search engine. Attackers have already used off and on as a vector for Pharming attacks for the last three to four years, and it is increasingly becoming more popular as a vehicle for driving “victims” to sites the attackers control. In this current attack, the cross-site scripting vulnerable Web sites themselves caused the problem as they appear to have sought to “optimize” their page ranking on the search engines.

Leveraging domain hijacking and botnet’s, the attackers have become very proficient in controlling page-ranking of their malicious Web content. I don’t expect this to diminish in the near future.

Protection

As I stated at the start of this blog, several people had approached me information about not only the threat, but also about protection (and remediation). Here is what I’d recommend...

Owners of the vulnerable sites:

Run a good quality Web application vulnerability scanner against your website regularly. In fact, just schedule it to run every day.

Run regular manual penetration attacks against the Web application on a quarterly schedule. It also pays to have a couple of preferred suppliers and round-robin them between tests to ensure that you don’t get the same pentesters each time looking at the same code.

Make sure you fix any scriptable vulnerabilities. Yes, I know, cross-site scripting is "lame" - but as you can see, it can be leveraged quite successfully by an attacker.

Home and Corporate users:

Make sure your computer is fully patched (this includes the operating system and all the other plugins – such as Adobe Acrobat, Flash, etc.) and running an updated anti-virus protection suite (which includes Anti-virus, buffer overflow protection, firewalling and IPS).

Make use of Web filtering technologies where available. Since most of these current generation attacks rely upon the actual malicious exploit script to be hosted somewhere other than the infected Web site, appropriate (updated) Web URL blocking services will more often than not protect against these attacks.

Don’t assume that a Web site is safe. It doesn’t matter if it’s a well known and respected site you’ve used hundreds of times in the past – the bad guys are targeting them precisely because users trust them.