Checking the locks

Had a worm scan from an elementary school in Korea (at least, that's what the whois appeared to indicate). It's always nice to be able to contact a small group like that. The large ISPs are pretty much worthless when it comes to investigating abuse reports.

Update 2004-12-08: I found an attack vector I hadn't seen before. I got lucky, though, because the attack showed up in the usage reports. Since I don't parse the server logs I wouldn't have caught it otherwise. Luckily it appeared to come from a relatively small block of addresses. Maybe I'll see some action on it.

The attack appeared to be automated, otherwise I would have expected a more concerted effort. The attack appears to crawl sites looking for ASP pages that use querystrings. I guess the assumption being that one of these sites will use the querystring as input for a SQL statement intended for a MS SQL Server backend. Not a wholly unlikely scenario. Once it finds one of these ASP pages the script requests the page again with a nasty little addition that creates a VBS file using a MSSQL built-in extended stored procedure. The additional querystring data uses pretty traditional SQL injection code that is URL-encoded. The encoded is only done once, though, and so is not caught by URLScan. A follow-up request attempts to execute the VBS, which downloads an executable (http.exe) from the same machine running the exploit scan to windows\system32. Finally, a third request deletes the VBS file. I didn't see any follow-up requests that attempted to execute the downloaded file. Most likely this is only done if the file is actually downloaded (the download request include the domain of the attacked machine).

The attack didn't work in my case for a number of reasons. One, access to the SQL server is established using an account that is fairly limited (and definitely does not have access to the master database where the built-in stored procedures can be found). Two, I'm as likely to use MS Access as I am SQL server. Three, a number of the scripts utilize the recordset object for data access, which I do not believe susceptible to SQL injection. Four, a number of scripts use an INSERT statement that, while not invulnerable to attack, requires more intelligent attack code that is likely to be found in an automated script.

One thing the attack has shown me is that I need to perform better sanitation of the incoming data. Though I doubt any automated script will ever cause any problems, a concerted effort on the part of a hacker would lead to a number of pages that could be used for SQL injection. This won't cause much of a problem with regard to stored procedure access for the reason mentioned above. However, stored procedure access is not the only means by which SQL injection can cause problems.

I'm tempted to give the script-kiddie the appearance that my personal server has been compromised so I can see what happens. I'm just not sure I really want to spend the time on it. Perhaps it'll be more fun to give the appearance that the FBI has been hacked.