Having recently seen our book SQL Injection Attacks and Defense come out, it is very timely indeed to see in the news of the recent indictment of Albert Gonzalez that SQL Injection played a key part in the Heartland Payment Systems, 7-Eleven, and Hannaford Brothers breaches, as well as for two other unnamed victim companies.

So how can SQL Injection, which is an application level problem, be used as a vector for attacking an organization? In a number of ways. SQL Injection gives an attacker the ability to interact with the database, and therefore if something is possible on the database server it may well be possible through SQL Injection. Modern database systems such as Oracle, SQL Server and others provide a rich variety of functionality for their users - all too often though, some of this functionality can be abused by malicious individuals.

Making some assumptions, its likely that something like the following occurred:

1. It was possible to interact with the underlying operating system in some way using SQL Injection. This could have been through the ability to execute operating system commands (such as through the well known xp cmdshell stored procedure on Microsoft SQL Server), or through the ability to stage content to the database server (or filesystem) and then have it compiled to executable content.
2. With the ability to execute content at the operating system layer, access was consolidated by providing some form of alternative control channel or remote access to the database server.
3. With consolidated access to the database server, the attacker uses the database server as a foothold to go further into the organization.

These types of hybrid attacks where one type of attack is dovetailed or launched over another are becoming increasingly common. Another SQL Injection hybrid attack of recent note was the SQL Injection mass attacks that started in early 2008. These used SQL Injection in another way - to inject links to JavaScript malware into thousands of unsuspecting vulnerable sites. It just goes to prove that even if a vulnerability is over 10 years old, it still has some new tricks to be seen.

Although there isn't a lot there at the moment, we're going to be putting up a lot of tools we've been working on as time permits.

Check out the blog for interesting technical content, including lessons learned and tips from our source code review/application vulnerability remediation work, as well as for some of the tools we'll be releasing in the coming weeks.

The reason for this is that in Windows XP Service Pack 2, Microsoft introduced a number of Network Protection Technologies for mitigating the spread of malware. One of these limits the number of simultaneous incomplete outbound TCP connection attempts to 10, with additional attempts being queued and potentially dropped. This impacts the reliability of at least port scanning, and possibly other security checks.

Unfortunately the scenario I was working with required me to be running Nessus through a VPN client (never ideal), in reality requiring me to be on XP. Tenable does, however, have some recommendations for running Nessus as reliably as possible on XP:

• Max number of hosts: 10
• Max number of security checks: 4
• Max number of packets per second for port scan: 50

The maximum hosts/security checks setting is standard in all of the Nessus clients I've used, however the packets per second setting seems to only be available within the client shipped with the Windows Nessus server. If you, like me, are using the new NessusClient 3.0 beta for Windows, you need to make the following change to the Nessus server's configuration to ensure that 50 is the default value:

• Go to the "config" directory in your Nessus server installation. By default this is C:\Program Files\Tenable\Nessus\config
• Open config.default.xml for editing - just use Notepad if you don't have an XML editor
• Find the SYN Scan:Max number of packets per second for port scan node, and edit the value (the CDATA bit) from 500 to 50

This value should now be the default for all new scans.

This worked well for me, however needless to say that running a Nessus scan in VMWare (slowdown factor one), over a VPN link (slowdown factor two), over a transatlantic Internet connection (slowdown factor three), the scan took quite a while to complete...

If setting the environment variable, on the Windows command line you can do this:

set http_proxy=myproxy:8080

Which should point it to your proxy. The same works for Unix/Linux with whatever export or set command is relevant for your shell.

The proxy support in urllib2 doesn't support authentication so if you have a proxy with authentication you might want to chain SQLBrute through your favourite local proxy (i.e. Burp, Paros etc) and have that handle the authentication for you. Enjoy!