Knowledgebase
Home » Item #997
Automated SQL injection attack
Question
I have heard about a damaging SQL injection attack that has compromised many database driven web sites. My logs show what appear to be attempts by this to break into my site. Is CactuShop vulnerable? What can I do to protect myself?
Answer
The specific attack we've seen is detailed here:
TechNewsWorld: Mass SQL Attack a Wake-Up Call for Developers
At present it only affects MS SQL sites, but could in future be modified to attack MySQL. Attacking Access would be harder.
The purpose of the attack seems to be to inject javascript code into every text, ntext, varchar and nvarchar field, in the hope that the site serves this javascript to users along with its normal page content. The javascript code attempts to download a trojan to the vistor's computer or exploit unpatched browsers.
Is CactuShop vulnerable?
Security vendors routinely review code for web applications to find SQL injection and other vulnerabilities. We are not aware of any SQL injection vulnerabilities in any CactuShop above v5.121 (June 2004), including all v6 and v6.1 versions. Versions prior to this could be vulnerable.
We did recently have an incident reported where the database of a v6.1 CactuShop was affected, but examination of the logs revealed that the flaw was in an unrelated (non-CactuShop) script that connected to the same database. The malicious code did not enter through CactuShop.
The attack itself was not particularly sophisticated in terms of the entry method, so all CactuShops above 5.121 should be safe. Versions for some time before that release may be vulnerable in theory, although in practice the vulnerabilities identified were more obscure and would be harder for an automated attack like this to find. The biggest risk is to very old CactuShops such as v4 or earlier (2003), or to CactuShops that have been modified or had new scripts added by third parties that may not employ measures to defend against SQL injection.
Safety precautions
We would prefer not to be complacent. Expert members on the IIS.net web site have come up with some measures for MS SQL databases that can act as a good safeguard against this particular attack.
We would recommend these even for the latest CactuShop installs, as an extra safeguard which has no negative impact on the store performance.
The following query, run as a user with admin privileges for your site database, will remove select permissions on MS SQL 2005+ system tables that the attack needs access to, thereby preventing the database from being hacked by this particular attack even if an SQL vulnerability were found:
use [databasename]
GO
deny select on sysobjects to [useraccount]
GO
deny select on syscomments to [useraccount]
GO
deny select on syscolumns to [useraccount]
GO
deny select on systypes to [useraccount]
GO
(you must replace the 'databasename' and 'useraccount' with the appropriate values)
We would urge all developers who are adding functionality to CactuShop to familiarize themselves with the issue of SQL injection and ensure that scripts they write or modify are not susceptible to it. This code to tighten up security at the database should not be considered a replacement for removing SQL vulnerabilities, but is a recommended additional safety measure for all MS SQL web site databases.
If you are installing multiple applications on your web site (for example, CactuShop plus a CMS, forum or banner management system, or your own custom application) then it is highly advisable to separate the databases for each, and create a separate DB user for each. This will help prevent a vulnerability in one disrupting the other applications and affecting their data. It also helps pin down which application is vulnerable in the case of an attack.
Fixing an affected site
If the database was attacked successfully, then most fields holding text will systematically have some javascript code added into them. This will typically break the site as config settings would be affected.
The injected data would either have to be removed manually, or you could restore a backup of the data before the breach occurred. In theory it may be possible to replace the injected code with a query run on each affected table.
However, it is not enough to just remove the data as it will likely be re-inserted if the flaws that let it in remain.
For this reason, you should analyze your site's logs to find which script(s) the code was injected through. Searching for something like 'CAST' or 'VARCHAR' might help speed up the process, as these are part of the queries that are known to be injected.
On affected pages, ensure all input to the script is sanitized. This means that all numerical values passed in (such as ID values) should be checked, and if not numerical, set to zero. All string inputs should be sanitized by ensuring any single quotes are escaped by replacing each occurrence with two single quotes.
To avoid repeats of the breach, all front end scripts should be reviewed and tested for further injection vulnerabilities. Doing this for a very old CactuShop or one that has been heavily modified is time consuming and requires a very systematic approach. In most cases, upgrading to a newer CactuShop would be a simpler alternative.