Defending against Lizamoon Attack

Lizamoon is the name of a SQL Injection attack heavily reported in the press since the end of March 2011. It inserts a <script> tag into your database that when returned, redirects to another site (sometimes with the domain name Lizamoon). That site uses social engineering to entice the user to download what they think is antivirus software, and later to get them to provide credit card information to pay for it. At that point, the hackers have stolen their credit card information.

You can read more with these articles:

pcworld, April 1: “Millions of Sites Hit with Mass-Injection Cyberattack”

eweek, April 1, “'LizaMoon' Mass SQL Injection Attack Escalates Out of Control”

Based on this thread from last September amongst Stackoverflow.com users, I think this attack has existing long before the March 28 date reported in the press:

Users of Peter’s Input Security (a module within my Peter’s Data Entry Suite) have the tools to defend against this attack. But just having the tools, doesn’t mean you are protected. As a rule, you must evaluate any inputs of each page to determine if they are secure or not. A web page has these “inputs” which hackers use to attack: data entry controls like textboxes, cookies, hidden fields, and query string parameters. (They also can use web services.)

This post discusses how to check your Peter’s Input Security settings to defend against the Lizamoon attack.

If you are on a DES 4 version below 4.0.6, get to DES 4.0.6 and apply a hotfix. Future releases will have the hotfix incorporated. The hotfix introduces a new feature that further assists in protecting you, but is not required. If you are using VAM or do not want to use the hotfix, I’ve included instructions for you below.

Getting v4.0.6 and the hotfix

Note: This hotfix has a minor breaking change to Peter’s Input Security that is described in step 5 of “Protecting yourself with the DetectDatabaseElementNamesInQueryString property”, below.

1. You must use DES 4.0.6 to apply this hotfix.
   If you do not have it installed, go to http://www.peterblum.com/getupdate.aspx, login and download it. If you do not know your login, get your serial number and contact Peter at PLBlum@PeterBlum.com to request it.
   Run the .msi to install 4.0.6.
   Run the v4.0.6 Web Application Updater with the option "Update a web application (service release)". This application is found in your Start menu and the folder where you installed DES.
2. Get the hotfix at http://www.peterblum.com/hotfixes/PeterBlum.DES4_0_6_5000.zip.
   Note: This hotfix rolls up all previous hotfixes for v4.0.6.
   Unzip the file.
   Replace the PeterBlum.DES.dll in your web application. Be sure that your Visual Studio project has a reference to this new assembly.
   Clear your IE9 RC1 browser's cache if you were already using 4.0.6.

Understanding the new feature of the hotfix

The new feature is the DetectDatabaseElementNamesInQueryString property on the PageSecurityValidator manager.  When this property is true (the default), the PageSecurityValidator evaluates every query string parameter for any value defined in the <databaseelementnames> node of the [web app]\DES\Security Config Files\master.config file and report an error if found.

This feature detects lizamoon because the attack incorporates the names of tables and columns from you database, previously extracted through another hack directed at your databases’s master tables. Here is its SQL attack pattern:

update [your table name] set [your field name] = REPLACE(…)

The <databaseelementnames> section of master.config is intended to hold names of tables and important column names that you do not want to appear within your inputs. It works best when your table and column names are not spoken languages, such as using “tbl_client” instead of “client” for a table of clients. Here is an example of this node. (The file is here: [web app]\DES\Security Config Files\master.config)

<databaseelementnames>
   <item action="add" >tbl_products</item>
   <item action="add" >tbl_orders</item>
   <item action="add" >tbl_categories</item>
</databaseelementnames>

Protecting yourself with the DetectDatabaseElementNamesInQueryString property

By default, DetectDatabaseElementNamesInQueryString is true, which means the feature is active. Yet, it does nothing if you have not setup the page correctly.

1. If you are new to Peter’s Input Security, follow the directions of the Input Security Installation Guide. This will enable loading the various config files, have you describe key elements about your app, and install a logging feature to capture attacks.

2. If you have not setup the page for Peter’s Input Security, follow the steps in the “Securing a Page” section of the Input Security User’s Guide. There are many actions to lock down all inputs. Be prepared to spend some time protecting each page.

3. At this point, your page has a PageSecurityValidator with the DetectDatabaseElementNamesInQueryString set to true (the default). If you do nothing else, this attack will be prevented.

4. Query string parameters that accept string values may have legal values blocked by the DetectDatabaseElementNamesInQueryString property. Review those parameters against the values in the <databaseelementnames> node of [web app]\DES\Security Config Files\master.config. If there is a legal value, set DetectDatabaseElementNamesInQueryString to false. Then add a ParameterRule object to the QueryStringRules object with its DataType=String and DetectInjection=true (the default). Also adjust the SQLDetectionLevel property, which defaults to the highest protection.

<des:PageSecurityValidator ID="PageSecurityValidator1" runat="server" DetectDatabaseElementNamesInQueryString="false" >
   <QueryStringRules>
      <des:ParameterRule Name="search" DataType="String" DetectInjection="true" SQLDetectionLevel="MediumLow" />
   </QueryStringRules>
</des:PageSecurityValidator>

• do not set DetectInjection, thus using the default.
• has its DataType property set to Ignore or String, or does not set DataType (which defaults to Ignore)

Look through your PageSecurityValidators to locate Rules that are now using DetectInjection=true. If you do not want that behavior, set its DetectInjection property to false.

Protecting yourself with VAM or without the DES hotfix

This topic helps users who have Professional Validation and More (“VAM”) as well as DES without the hotfix.

1. If you are new to Peter’s Input Security, follow the directions of the Input Security Installation Guide. This will enable loading the various config files, have you describe key elements about your app, and install a logging feature to capture attacks.

2. If you have not setup the page for Peter’s Input Security, follow the steps in the “Securing a Page” section of the Input Security User’s Guide. There are many actions to lock down all inputs. Be prepared to spend some time protecting each page.

3. Review the QueryStringRules collection of each PageSecurityValidator to be sure that every query string parameter used by this page is listed, with the appropriate rules. When a ParameterRule has its DataType property set to Ignore or String, or it does not declare the DataType property are candidates for this attack. Your defense is to set DetectInjection to true.

<des:PageSecurityValidator ID="PageSecurityValidator1" runat="server" >
   <QueryStringRules>
      <des:ParameterRule Name="search" DataType="String" DetectInjection="true" />
   </QueryStringRules>
</des:PageSecurityValidator>