Neil Carpenter's Blog : Tool

SQL Injection Hijinks

neilcar — Fri, 31 Oct 2008 23:07:00 GMT

or Why I Keep Harping On Blacklisting

Summary:

An incident reveals attempts to get around blacklisting by manipulating behavior in ASP, illustrating the weakness of blacklist approaches.

A new version of UrlScan is shipping today with a change specifically to address this.

Discussion:

I was working with a colleague on an incident last week that looked like a garden-variety SQL injection drive-by except for something interesting.

While looking through the IIS logs from the affected server, I saw this:

abc=120364DEC%LARE%20@S%20VAR%CHAR(4000)%3BS%ET%20@S%...

As I looked at this, "DEC%LARE", "VAR%CHAR", and "BS%ET" immediately stood out to me. Obviously, the percent sign is usually used to escape something in a URL (like the %20's in there, which are spaces); however, this naked percent sign thrown in there didn't seem to have any purpose and should have caused SQL to not execute the code in question.

When I see somebody do something like this, it's usually for a purpose so I took another look at it. I realized that, if ASP silently stripped that percent sign out of there, then this would be an efficient way to bypass a lot of blacklist-based filters.

I wrote a quick test ASP page(1) and found that my guess was right on -- ASP drops a percent sign from the query string if it isn't followed by two valid hex characters(0-9, A-F) when it actually interprets it via Request.QueryString. This means that any filter that inspects raw headers using Request.ServerVariables is going to miss "DEC%LARE" if it is looking for "DECLARE" but, on the other hand, the ASP app that actually consumes that string using Request.QueryString("abc") is going to get it without the percent sign.

Conclusion:

As this incident illustrates, a blacklist approach to SQL injection only works for as long as nobody finds a way around your blacklist. As soon as somebody finds a way around it (and experience suggests that attackers are motivated to do so), the value of your blacklist is zero.

The right approach is to fix the actual vulnerability in the code using parameterized queries. See the articles below for more information and examples.

http://msdn.microsoft.com/en-us/library/cc676512.aspx

SQL Injection Mitigation- Using Parameterized Queries

SQL Injection Mitigation- Using Parameterized Queries part 2 (types and recordsets)

The IIS team is releasing an update to UrlScan today that includes changes to address this in their filtering product. Of course, as I've said over and and over, no filter-based approach is going to be perfect, but UrlScan is still an excellent defense-in-depth tool and a way to mitigate SQL injection vulns in the short term while your developers fix them.

For more information on the UrlScan update, Wade Hilmo has all the details:

http://blogs.iis.net/wadeh/archive/2008/10/31/urlscan-3-1.aspx

(1)

<HTML>
QUERY_STRING = <%= Request.ServerVariables("QUERY_STRING") %> <BR>
test =<%= Request.QueryString("test") %> <BR>
</HTML>

PASSGEN

neilcar — Wed, 22 Oct 2008 21:52:02 GMT

Occasionally, I see a security incident where one of the things that went wrong was that all of the customer's machines have the same password for the built-in administrator's account. Whenever this happens, I suggest the PASSGEN tool that was included with the book "Protect Your Windows Network" by Steve Riley and Jesper Johansson. Obviously, most people don't want to run to the bookstore in the middle of a security incident but, fortunately, it was available on their website.

Unfortunately, the website disappeared recently and I had to scramble around to find it. If you're looking for PASSGEN (and you should be if you have the same password for local admin across a number of machines), you can find it in two places:

Err

neilcar — Wed, 13 Aug 2008 05:10:00 GMT

I might be the last person to know this but one of my favorite internal Microsoft tools is now external. Err.exe is a command-line tool that looks up error codes and spits out possible matches from various header files. This is invaluable when you're reading through a log and run across something like "Failed, err 0x80070003" -- just run err and you'll find out what this possibly means:

C:\Users\Neilcar\Downloads\Err>err 0x80070003
# for hex 0x80070003 / decimal -2147024893 :
COR_E_DIRECTORYNOTFOUND corerror.h
# MessageText:
# The specified path couldn't be found.
# 1 matches found for "0x80070003"

The download for err is available at http://www.microsoft.com/downloads/details.aspx?familyid=be596899-7bb8-4208-b7fc-09e02a13696c&displaylang=en. Download it and extract it to somewhere in %PATH% so that it's only a command prompt away.

SQLInjectionFinder

neilcar — Tue, 27 May 2008 20:51:23 GMT

My colleague Greg, who has forgotten more about command line scripting than I will ever know, put together a sample on CodePlex that automates finding SQL injection attacks from the ongoing mass SQL injection attack ("SQL Storm", as I saw it dubbed today). This is a fairly convenient approach to searching logfiles on an IIS server.

Neil Carpenter's Blog : Tool

SQL Injection Hijinks

PASSGEN

Err

SQLInjectionFinder

SQLInjectionFinder -- http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=WSUS&ReleaseId=13436