SQL Injection Web Server Virus

On April 17, 2008, hundreds of thousands of pages on legitimate domains including several at the United Nations and in the UK government were attacked. Many of these sites ended up serving malware by redirecting users to malicious pages using JavaScript and IFRAMES. Users PCs were loaded with a malware program that tried eight different exploits in an attempt to hijack the system.

On Windows Server 2003, an attacker can leverage the Microsoft Distributed Transaction Coordinator (MSDTC) service that runs as Network Service to acquire a Network Service token into a process that is running as an identity other than a service identity. An attacker canthen use this Network Service token to elevate to System if this process identity possesses the SeImpersonatePrivilege. Problem will only occur if IIS is enabled or SQL Server is installed and a user is granted administrative privileges to load and run code.

Workaround provided by Microsoft.

www.microsoft.com/technet/security/advisory/951306.mspx

How is IIS affected?
User-provided code running in IIS, for example ISAPI filters and extensions, and ASP.NET code running in full trust may be affected by this vulnerability. IIS is not affected in the following scenarios:
- Default Installations of IIS 5.1, IIS 6.0, and IIS 7.0
- ASP.NET configured to run with a trust level lower than Full Trust.
- Classic ASP code

How is SQL Server affected?
SQL Server is affected if a user is granted administrative privileges to load and run code. A user with administrative privileges could execute specially crafted code that could leverage the attack. Caught it at 6am GMT or 2pm SG Time. A remote computer (222.90.0.0 - 222.91.255.255 CHINANET shanxi(SN) province network) injected the following code into our web server:
www.mac-net.com/default.asp?p=320480&c=X
&kid=%7BF30167B0-CAD9-471F-B2C9-A278F23A8602%7D;
DECLARE%20@S%20NVARCHAR(4000);
SET%20@S=CAST(0x440045004...
...0073006F007200%20AS%20NVARCHAR(4000));EXEC(@S);

The following pattern on the IIS log:
;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(
0x4400450043
0x440045
0x44

Here was how the compromised web page was rendered.
bad

Solution:

Change user from "sa" to "www" with out read / write to the selected tables.
Change the mod rewrite to ignore ";DECLARE".
Restore database from a good data backup.

Last attack was on 13 May 2008 13:00 GMT (9pm SGT) - it was able to holdup and not infected the 50 attack. It should be ok now - so next, do a mod rewrite tweak to lower load on the server.

Added the following line on httpd.ini (ISAPI_Rewrite)
RewriteRule .*;DECLARE.* / 404.asp [I,R]

Also it may be a good ideal to disable "Distributed Transaction Coordinator" MSDTC Service, if it is not used. And not to use, user "sa" to run asp script. Create a user like "www" and assign db_dataread & db_datawrite to the database used in your web application.

Use SQL query analyzer and execute the statements below to DENY access to the following system tables:

deny select on sysobjects to [www]
deny select on syscomments to [www]
deny select on syscolumns to [www]
deny select on systypes to [www]

As the above script denies the permission for the system tables to be accessed by the injection script, automatically the injection fails.

Creating a generic replace function that will handle the single quotes automatically, like this:

<%
function stripQuotes(strWords)
stripQuotes = replace(strWords, "'", "''")
end function
%>

This, in effect, stops the injection attack from taking place, because the clause for the WHERE query now requires both the userName and userPass fields to be valid.

By the way, as of writing 20 June 2008, there are still a number of web pages infected (at it's peak (Middel of May 2008, 2 million pages were infected). Try the following search ".cn/ms.js" on Google to see the extend of damage.

Updated On: 08.12.07