We have been working recently on a XSS attack that impacted a huge number of potential victims, as the attack itself has been “optimized” by SEO (Seacrh Engine Optimization) practices that pushed it to Google’s indexes.
In itself, this is not a new technique, but the sheer size of it made us take a second look (incidentally, another security researcher has gone public with the details at the same time while we were communicating with Google’s security team about it). So how does it work? Basically the recipe is quite simple:
- Find an XSS vulnerability on a major site that has a decent amount of traffic (easy).
- Decide what you want your victim to “experience” – this can vary from serving some malicious code, to pure Crimeware marketing (lessons learned from “what to avoid” from SPAM email marketing).
- Start googling it with the XSS in the URL (most sites normally allow parameters to be passed in a GET rather than enforcing POST only).
- Enjoy the show – make sure that the XSS (usually a search page) also contains some keywords that would attract hits from legitimate searches.
XSSed sites used:
From what we have seen so far – including sites such as torrentreactor.net (first one) and zdnetasia.com (on 3/4/2008), tv.com (2/5/2008), torrentportal.com (3/8/2008), University of Pittsburgh’s jurist.law.pitt.edu, torrentfreak.com and fulldownloads.us (3/9/2008).
Unwanted sites used in the attack:
From is-t-h-e.com, through 72.232.39.252, media-toolbar.com, oasdc.info, do-t-h-e.com – all provide some kind of unwanted malware to be eventually dropped onto the unsuspecting user.
And finally – a glimpse into what people are looking for. Looking at the keywords used as part of the search terms, we discovered a sort of a zeitgeist of popular terms. The obligatory mature content terms (which I won’t quote for obvious reasons!) to the other extreme such as “the lost book of the new testament bible”, and the more spiritual “working with emotional intelligence” as well as the mundane “chevy tahoe specs”. Even techies are properly served with “bash if or condition”. In short, it provides us with a truly “inspiring” journey into what makes us tick (although we already know, still, seeing it is truly believing).
And now for the replies we got from some affected parties:
From torrentreactor – who we contacted on 3/4/2008, as their XSS was not public at the time (if you don’t count the outing done by other blogs) – we got a pretty quick response thanking us for the notification, and asking if there were more issues with their site. However, there hasn’t been a fix of the XSS issue yet at the time of this writing).
The more interesting view comes from Google (contacted early 3/4/2008). We contacted them since we saw that some of the search results were sanitized of the offending XSS effect, while other still contained a working XSS.
Google acknowledged that this was a known attack vector, and confirmed that they are indeed working on ways to manipulate and “sanitize” links provided by them in an effort to minimize the effect of incidents such as XSS on indexed sites. They also share our opinion on the reality of XSS and its affects on web browsing: “Google recommends that sites fix their cross-site scripting vulnerabilities as a priority. These can be abused in a number of ways, including bad interactions with search engines. Google is helping by reaching out to affected organizations. In addition, Google has internal processes to block abuses when the situation warrants.”
It will be interesting to see how this will work out since sites still cache search results, thus allowing search engines to index those as results as well. That practice is exploited here where the site is affected by a XSS, which is then in turn “immortalized” when a search engine sees it.
In the meantime we would recommend the following:
- Website owners and developers – XSS is rated no. 1 in the OWASP top 10 web application vulnerabilities (no pun intended). Most of them are known. Test for it, fix it. It may not be a direct threat to YOUR site, but it’s a security issue nonetheless and poses a risk to your users.
- Stop allowing the caching of search results. All the XSS were found in the search pages of the vulnerable sites. Just disable search engine caching for them. There is no added value in it.
- Search Engines – you have the money and the resources. Although it’s OPP (other people’s problem), you can help prevent and mitigate such incidents (kudos to Google for their ongoing efforts).
Ending on a high note – we stand for security of online browsing, as well as responsible disclosure.
).