For those of you who didn’t catch my turbo talk at Black Hat in Las Vegas, and especially those of you who looked at the slides and demo in my previous blog post and had no idea what the talk was about, I thought I’d put together a short summary of what was covered, and what I demonstrated.

I began my presentation by discussing the mass SQL Injection attacks that started earlier this year (see Internet Storm Center coverage from the start of the year), originally out of China, but now out of Eastern Europe as well. The profit motivation for these attacks is fairly obvious - inject JavaScript malware into a site’s HTML. The attacks exploit SQL Injection vulnerabilities to insert JavaScript into the database that is then rendered back into web pages. Botnets are often used to randomly attack website pages on the Internet (chosen using Google, for example) with a generic SQL Injection attack. The attacks have one shot at success - it either works or it doesn’t. The major upside of using a botnet is that even a low success rate can be devastating as they can still compromise hundreds of thousands of pages. Even worse, the indiscriminate nature of botnet attacks make it so potential victims no longer have to wander off to the deep dark corners of the Internet to face the possibility of some malicious content being installed on their machines, because any site could potentially be infected.

There are some other profit motivations that to date we haven’t seen exploited. Namely, unlike the more common botnet attacks that seem to largely target home users for their personal information and details, the mass SQL Injection attacks have a different target - websites developed by organizations and businesses, large and small. Some of which may have some very interesting information, such as customer data and (regardless of whether it is supposed to be there according to the PCI DSS) credit card information. Another target are websites that are on DMZ’s behind outer perimeter controls (e.g. firewalls), and therefore may provide a useful pathway into an organization’s network, and all of the interesting information and data residing there.

Building on these attack scenarios, I then speculated on aspects of the current mass SQL Injection attacks that could lead to more serious exploitation. What I came up with was a self replicating SQL Injection worm, and this is what was demonstrated on stage at Black Hat.

How does the Proof of Concept SQL Injection Worm Work?

For the moment it is Microsoft SQL Server specific, largely because the functionality leveraging the underlying operating system is straight forward to access in SQL Server. The worm looks at the IP address it is on, and if it is an RFC 1918 private IP range it will scan the subnet looking for other web servers on port 80. When it finds a website, it does a fairly simple crawl of the entire site, and then parses through the HTML code to identify query strings with parameters, as well as forms in the HTML. The worm then tests each parameter in succession for trivially identified SQL Injection vulnerabilities. If a parameter is vulnerable, the worm will then run through the following tests:

• is the back end Microsoft SQL Server?
• are stored procedures executable?
• is the xp_cmdshell extended stored procedure executable?

If those tests succeed, the worm uses the xp_cmdshell functionality to upload a copy of itself (i.e. the payload) onto the database server. It does this by encoding the payload as a text file, echoing it up line by line, and unpacking it on the destination server using the debugger that ships with every Windows installation by default - debug.exe. Then, presuming it all worked, the reassembled worm is executed, and the spread continues. And that is all this proof of concept worm does - spread. All of this worked quite well live on stage, with the exploit to upload process taking about 2-3 minutes for my test network, enabling me to show a number of the worms executing in memory (as the worm doesn’t have any facility to detect whether a machine is already infected).

Yes, this particular worm does rely on an insecure configuration being present - namely that xp_cmdshell is executable. By default this is not available on SQL Server 2005, and won’t be executable unless the website has been explicitly granted privileged access to the database server, so not all vulnerable sites will be exploited by the worm. However, there are plenty of sites that are configured insecurely, running previous versions of SQL Server (that are much easier to misconfigure), and let’s not forget xp_cmdshell is also available and potentially exploitable on sites running a Sybase backend. After all, even if only one in ten sites are in this configuration, we will still have tens of thousands of vulnerable sites.

To wrap it all up, my Black Hat presentation demonstrated one particular way that things could get much worse with SQL Injection worms. Leveraging operating system access (if present) is only one potential way to wreak havoc on the Internet. There are lots of others - I for one will be very interested to see where those clever folks in China and Eastern Europe take the mass SQL Injection attacks in the near future.

Well, I’m offstage now having just presented my talk on “SQL Injection for Fun & Profit” at Blackhat in Las Vegas. One of the main aims of the talk was to provide more coverage on the mass SQL injection attacks that started earlier this year (and are still going on). The Internet Storm Center has some good discussion and coverage on this topic from earlier this year. The other aim was to point out some of the ways it could have, and probably will be in the near future, much much worse.

You can find a copy of the slides that were presented here, as well as a flash video of the demo that was done of the self replicating SQL Injection worm I wrote for this talk.

I’ve just uploaded an update to AntiXSS, based on feedback we’ve received from developers looking at the library. This can be found at the GDS Tools page. I have also updated the original AntiXSS announcement post to point to the new release.

Since the release of the library, the two main areas of feedback we got from users of the library were:

• Why is it only Java 5 and above? We have a lot of Java 1.4 code.
• Why are the methods all named with UpperCamelCase? We use lowerCamelCase for all of our method names.

In brief, we’ve addressed the first issue but not the second in this release. You should find that AntiXSS will work with your Java 1.4 code as we’ve changed the underlying functionality to remove the dependency on Java 5. As for the method names, those are the names used in the Microsoft Anti-Cross Site Scripting (AntiXSS) v1.5 library for .NET applications of which this library is a port. As such, we’ve preserved the API as is, and think it would be counter productive to rename the methods, have duplicate methods with different capitalisation, or to ship an adapter interface with lowerCamelCase names.

Any feedback, bug reports, or reports of usage appreciated.