Back in January there were multiple reports about a large number of web sites being compromised and serving malware. Fellow handler Mari wrote the initial diary at http://isc.sans.org/diary.html?storyid=3834.

Later we did several diaries where we analyzed the attacks, such as the one I wrote at http://isc.sans.org/diary.html?storyid=3823. Most of the reports about these attacks we received pointed to exploitation of SQL Injection vulnerabilities.

Yesterday, one of our old friends, Dr. Neal Krawetz, pointed us to another site hosting malicious JavaScript files with various exploits. While those exploits where more or less standard, we managed to uncover a rare gem between them – the actual executable that is used by the bad guys in order to compromise web sites.

While we had a general idea about what they do during these attacks, and we knew that they were automated, we did not know exactly how the attacks worked, or what tools the attackers used. The strategy was relatively simple: they used search engines in order to find potentially vulnerable applications and then tried to exploit them. The exploit just consisted of an SQL statement that tried to inject a script tag into every HTML page on the web site.

The utility we recovered does the same thing. The interface appears to be is in Chinese so it is a bit difficult to navigate around the utility, but we did some initial analysis of the code (which is very big) to confirm what it does. You can see the interface below:

So what the tool does is this:

• The user can configure the tag that will be inserted on the compromised web sites. By default, the tool we recovered had the following string embedded: http://www.2117966 [dot] net/fuckjp.js. Sounds familiar? See https://isc.sans.org/diary.html?storyid=4139
• The tool then checks something with a site in China. My guess at this point in time is that the attackers get paid for this since the tool calls a script pay.asp with an argument SN to verify something.
• Now the user can start the tool. It will connect to Google and will search for vulnerable sites with the following query string: inurl:".asp" inurl:"a=". The parameter is configurable and the tool can search for many strings. For crawling, the tool uses a built-in embedded browser from bsalsa (http://www.bsalsa.com)
• Once the URLs have been identified, the tool tries to attack the web sites with SQL Injection (I still have to analyze this part further to see how it works). The SQL injection string, though, is visible in the file and formatted with the tag defined in the first. Here is how the SQL Injection statement gets formulated

DECLARE @T varchar(255),@C varchar(255) DECLARE Table_Cursor CURSOR
FOR select a.name,b.name from sysobjects a,syscolumns b where
a.id=b.id and a.xtype='u' a
nd (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('up
date ['+@T+'] set ['+@C+']=rtrim(convert(varchar,['+@C+']))+''
''')FETCH NEXT FROM  Table_Cursor INTO @T,@C END CLOSE Table_Cursor
DEALLOCATE Table_Cursor
;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(
%20AS%20NVARCHAR(4000));EXEC(@S);--

The nice thing about this is that we finally managed to confirm that it is SQL Injection that was used in those attacks. The tool has more functionality that we still have to analyze but this is the main purpose.

So, to finish this diary – a call to all web site owners – check your applications and make sure that they are not vulnerable. We covered this many times in various diaries, so here are few links to online resources that can help with this:

http://www.owasp.org/index.php/Top_10_2007-A2#Protection

http://weblogs.asp.net/scottgu/archive/2006/09/30/Tip_2F00_Trick_3A00_-Guard-Against-SQL-Injection-Attacks.aspx

http://portal.spidynamics.com/blogs/msutton/archive/2006/09/26/How-Prevalent-Are-SQL-Injection-Vulnerabilities_3F00_.aspx

http://erratasec.blogspot.com/2007/08/sql-injection-is-surpisingly-easy.html

Some updates

Here are some updates with good stuff we received from our readers. First, let me clarify that this attack is a pure SQL injection. There was another mass attack at the beginning of the year which was more sophisticated and involved complete compromise of the web servers (i.e. the bad guys had the root access to the servers).
The tool described in this diary was used in the attack described in Kevin's diary (http://isc.sans.org/diary.html?storyid=4139).
These SQL Injection attacks are still going on and we can still see sites being attacked with similar (if not the same) tools.

Reader Nathan also sent a nice description of the SQL code, I'm including this e-mail below:

"The SQL in question uses table cursors (as variable Table_Cursor) to enumerate all tables on Microsoft SQL server and the respective columns that are of type ntext, text, nvarchar, or varchar AND the table type is a user table and not a system table.  The code then proceeds to utilize a cursor while loop to iterate through the returned results updating each table.columname concatenating it's current value with an arbitrary value (which appears missing in your SQL, it would appear in the [HERE] area of the query part "rtrim(convert(varchar,['+@C+']))+'[HERE]'"

The code converts the current data to varchar during concatenation to avoid any cast issues and removes any trailing space to the right of the field value.

The cursor is deallocated after update (how nice of them)"

Thanks everyone for great submissions.

--

Bojan