As of December 10, 2009 over 132,000 websites have been compromised and are serving up the malicious content.  The attack loads up an Iframe onto the websites via the data returned from the database which eventually leads the user (without there knowledge) to download data from 318x.com which then installats a rootkit-enabled variant of the Buzus backdoor trojan.  The full path of what happens can be found on the link above.

We’ve talked about the securing your website from SQL Injection attacks here, here and here, apparently there are tons of sites out there which haven’t been listening.

Denny

Your database holds all of your data.  If someone was to great into your database server they would have access to view, and possibly delete all your data forcing you to restore your data from your backup.  In a perfect world there would be no database servers directly accessible from the Internet.  There is pretty much no reason for database servers to be directly accessible from the Internet.

If your servers are CoLo’d then setup a VPN between your office and the CoLo, or VPN directly into the CoLo.  There are some hosting providers which prefer to setup the servers on public IPs, however most of them will if requested use private IPs and configure a Site to Site VPN connection for you.

Pretty much the only times that a database needs to be on the Internet would be if you are replicating data between servers as this will typically require that at least one of the servers be on the public Internet.  SQL Service Broker can need to be on the public Internet as well.  However in both of these cases, you don’t need to give the server a public IP.  You can give the server a private IP, and NAT the server from the Internet to the private IP.  However make sure that only the correct port or ports are open through the firewall.

In Oracle this should be done by setting up a new listener.  In SQL Server this is done by setting up a new endpoint either for general connection, or in the case of Service Broker an Endpoint is used to connect to, which listens on a seperate TCP port.  When setting up these listeners or endpoints make sure that only the accounts which need to have access to them have access.  This way the minimal attack surface is avaialble from the Internet.  In addition you will want to setup your firewall or router ACLs to allow only the required public IP addresses to have access to the listener or endpoint.

With your database being publicly available attack scripts could attack for it, or people could manually try and break in.  With SQL Server running in mixed mode, and with Oracle there are accounts which can be brute forced which have well known usernames such as system and sa.  When SQL Server is running in Windows only mode breaking in is harder, but not impossible.

Denny

Don’t forget to log the requests and check them regularly so that you can block access to those IPs if needed.

This technique works well in other web servers as well, I’m just most farmilier with IIS.

Denny