Those nasty SQL Injection attacks have not stopped. They’ve probably just started!

If you’re still in the process of going through your SQL code and making sure it’s not susceptible to SQL injection attacks that means your websites are still wide open to the attack.

However not to worry, the Microsoft IIS team has come to the rescue with the announcing of the shiny new Microsoft Urlscan Filter v3.0 Beta release. It includes a GoLive license, so you can deploy it on your production servers.

Here are some of the cool new features:

• Support for query string scanning, including an option to scan an un-escaped version of the query string.
• Change notification for configuration (no more restarts for most settings.)
• UrlScan can be installed as a site filter.  Different sites can have their own copy, with their own configuration.
• Escape sequences can be used in the configuration file to express CRLF, a semicolon (normally a comment delimiter) or unprintable characters in rules.
• Custom rules can be created to scan the URL, query string, a particular header, all headers or combination of these.  The rules can be applied based on the type of file requested.

One thing important to remember is although this will protect websites against this latest form of SQL injection attack, any poorly written code still needs to be fixed. No escaping on that.

The month of May seems to be a time for many SQL injection attacks around the world. Unfortunately one of the sites affected by these attacks happens to be one that is administrated by a friend of mine. As it so happens the site was also developed by a friend and I'm sure we can have a good time reminding him to give SQL injections the respect it deserves for a long time to come.

Anyway, getting back to the attack, I was able to get a few logs to see what was happening first had. Here is a (modified) extract of the IIS logs that show what had happened:

This particular attack carried out from within China (WHOIS - 58.215.76.181) is pretty interesting, most of the SQL is obfuscated behind a very long hex string (CAST(0x HEX string)). I've removed the original string and replaced it with something harmless and much shorter in the above log entries.

The attacker has tried 2 slight variations of a SQL injection attack in the form of

1) /page.asp?pageID=2;SQLStatement;--   

2) /page.asp?pageID=2';SQLStatement;--

the attacker keeps trying the above 2 combinations on different pages of the website till he gets status 200 result; then leaves.

So what has the attacker done in his SQL statement?  To figure this out we can fire up SQL Server Management Studio and pretty much use the same code that the attacker used except that we substitute the EXEC with a PRINT to view the query.

DECLARE @S NVARCHAR(4000);
SET @S = CAST(0xuseTheActualHexString AS NVARCHAR(4000))
PRINT(@S)

The attacker had queried all the all the user tables, found column names in each of these tables that are used to store string values such as text, nvarchar, or varchar etc. then it adds a <script> tag with a URL pointing to  a malicious .js file into each of  the column values. The SQL had also been "nice" not to replace the original values and only append to it, and also even properly deallocate and close cursors they used in their attack query!

The result of all that meant that all the websites configured to use that database will start to display its pages as shown in the following Google search result. Innocent visitors of the site would in some cases be executing that .js file in their browser which could cause all kinds of havoc depending on what is in the specified .js file.

Recovering from the attack is straight forward; use a clean backup of the database, or if you really wanted you could just remove the appended <script .. > portion from all the column data using the same script that was used to insert it.

But do we prevent this from happening again? well that's another post. Just remember to give SQL injections the respect it deserves.

Here is a little command that I came across when I was looking for a quick and easy way to delete some old log files from my system.

C:\>forfiles /?

FORFILES [/P pathname] [/M searchmask] [/S]
         [/C command] [/D [+ | -] {MM/dd/yyyy | dd}]

Description:
    Selects a file (or set of files) and executes a
    command on that file. This is helpful for batch jobs.

As the command descriptions suggests, its great for using in a .bat file, so I put following line in a cleanLogs.bat file, and scheduled a task to run the batch job every weekend to clean up my system of old and unwanted logs.

forfiles /p E:\Logs\ /s /m *.log /d -60 /c "cmd /c del @path"

forfiles.exe is a tool that has existed in old res kits and has been moved to the standard installation of the newer Microsoft operating systems like Windows Vista and Windows 2003.

Recently a friend needed to pass a value from a vbscript to a batch file which called the vbscript.

I've never had to do this before so after a little bit of head scratching, googling and few rounds of trial/error we managed to solve the problem.

In the process we came across three ways to get a return value of the vbscript into the batch file.

1. Using the "Wscript.Quit" and "%errorlevel%" environment variable
In our script we could use the Quit method to return a integer value when exiting and read that value in our batch file using the %errorlevel% environment variable of the command shell.

   
    Script file myScript.vbs:
    'Do something.
    '
    'Exit with a purpose!
    Wscript.Quit(65)

    Batch file myBatch.bat:
    REM Run the script.
    myScript.vbs
    REM Do something with the return value.
    echo %errorlevel%

   
This may not look to be interesting at first, but it is possible to get a little creative and use it to pass a drive letter from a script to the command shell.


2. Using a third file to store the result
This somehow seemed uninteresting. But it could do the trick. First we write the our return value from the script to a file, and then in the batch file we read the contents of the file.

    Script file myScript.vbs:
    Dim oFilesys, oFiletxt, sFilename, returnValue
    'Do something, and return something
    returnValue="cool Result!"
    'Write a return value to a file
    Set oFilesys = CreateObject("Scripting.FileSystemObject")
    Set oFiletxt = oFilesys.CreateTextFile("returnValue.txt", True)
    oFiletxt.WriteLine(returnValue)
    oFiletxt.Close
    'Exit
    WScript.Quit(0)


    Batch file myBatch.bat:
    REM Run the script
    myScript.vbs
    REM Read the return value
    FOR /F %%i in (returnValue.txt) do echo %%i


3. Using "WScript.Echo" with "FOR /F"
Here is what we ended up with, instead of writing anything to a fille, we can just use WScript.Echo to tell the script to spit out the result and then use the For command to read it. Nice and easy!

    Script file myScript.vbs:
    'Do something, and return something
    WScript.Echo "cool Result!"
    'Exit
    WScript.Quit(0)

    Batch file myBatch.bat:
    REM Run the script and read the return value
    For /F "delims=#" %%i  in ('cscript //nologo c:\myScript.vbs') do echo %%i

Here the For will execute the 'cscript //nologo c:\myScript.vbs' and read the output. Make sure to add the //nologo unless you want to  banner from cscript to also appear as the result. Also if the result contains spaces or tabs, you will need to set the "delims=" because the default delimiter set is space and tab. If we had omitted this in the above example, the retVal would have only contained "cool".

Any other interesting ways of doing this?