UPDATE (6/19/2008) : For both IT people and end users please spend time reading through (if
not here then at least from other sites, just be sure you are aware
nevertheless) if you aren't that aware yet since this exploit has been
continually spreading despite numerous warnings already made in the
web. For developers, please feel free to comment, add or correct any information you think would further benefit others. For end users, I would still recommend knowing about more about this issue, how to protect yourself and stop yourself from being part of spreading it. Link to the following section might be of interest to you : browser and anti spy software
UPDATE (6/27/2008) : Came across Scrawlr an SQL Injection Detection Tool from HP that is available for free. There probably are other tools available (better) but this is the one I ran into so far. Also a tool named UrlScan from Microsoft TechNet was suggested by Jax (see comments). It can be used to screen/limit request information being sent to your site, the same way that http.sys does for IIS6 or later. You want to have a look.
There seems to be a number of SQL injection attacks happening lately involving adding of <script with banner82.org/b.js, adword71.com/b.js (and the likes ) to entries under string/text/varchar columns in the database targetting ASP (classic/3.0) sites and SQL Server. Note, they need not know your table or column names to mess up with you.
I definitely do not wish to play cops and robbers here but I wish to contribute a little on this. There are a number of articles on this (read along) and even more for preventing/cleaning
SQL injection and other related exploits such as cross-site scripting so help yourself. 😀 [more]
It generally works by appending a string/text (url-encoded SQL script) to the URL/query string, then when it gets to the server, such string/text will be url decoded (automatically) and if the target site/application is susceptible to SQL injection (generally by concatenating and dynamically building the SQL query) then the passed SQL script will unknowingly be executed against the database and will cause some text to be appended to string/text fields. This is not limited to insert/update operations made against the database but also for SELECT (ie. even if your site/application only involves SELECT queries but not coded to prevent this, it will still be vulnerable).
I'm almost sure other variants will popup here and there (those who did are IMHO brilliant doesn't change the fact of course that what they're doing is wrong) but I think being aware is more than a good start.
Here are more information on the issue and an SQL script to help cleanse the affected data. You can run it against your SQL Server database as it is but I would recommend you seek the help of at least a developer with SQL knowledge. Also please feel free to drop me a message/email if necessary. I'd be glad to help any way I can.
/*
NOTE: this is a patch created only by reversing the effect of the SQL script
in one known variant of the exploit. This is not tested as a generic RemoveText stored procedure.
Also use with caution as this procedure will remove the text specified without further checks
as to whether it is indeed an exploit or valid data. (eg. you are applying this to a forum
database which may contain valid entries with the <script string/text… they will be removed unconditionally)
Always backup up your database before any patches, and verify data after patch.
There is also no guarantee that this will completely remove the unwanted text if the variant
used for the exploit uses another approach (such as those involving NTEXT, TEXT columns).
Finally, this is only to cleanse already compromised data and doesn't prevent SQL injection.
There are many articles doing that already but to point out a few, please check these links
http://www.experts-exchange.com/Security/Vulnerabilities/Q_23411125.html
http://www.experts-exchange.com/Security/Vulnerabilities/Q_23408074.html
Short solutions could involve (short and long term):
1. changes in code to validate input (deny request variables with blacklisted keywords)
2. this (cleansing of data)
3. reduce access of the database user account to only those necessary to perform what's needed. See DENY keyword in SQL.
– generally DENY access to system tables, view, procedures et al and allow only
access to user defined objects. For this particular variant it DENY sysobjects and syscolumns table in SQL 2000 (views in SQL 2005) but if you can all system/unused/objects neet not be accessed directly the better
– this might take time to properly test which needs to be allowed and thus might require
testing the whole site again (regression testing) but in typical applications restricting access
to system would not be a problem good idea.
4. more input validation (length validation, data type validation etc)
5. use stored procedures or parameterized queries (if there is really a need to concatenate)
6. auditing, logging and maybe maintain a blacklist of IPs
7. just a reminder, make sure the web server and database server is secured ofcourse
8. subscribe to hacker safe or similar services
also don't fail to encrypt critical/sensitive information in the database
There is are more comprehensive articles in the web so please take some time to research and
don't just take my word for it.
Hope this helps.
*/
SELECT * FROM dbo.sysobjects
WHERE
ID = OBJECT_ID(N'[dbo].[RemoveText]')
AND type in (N'P', N'PC'))
GO
CREATE PROC RemoveText
(
@TextToRemove VARCHAR(4000)
)
AS
DECLARE @T VARCHAR(255),
@C VARCHAR(255)
DECLARE Table_Cursor CURSOR
FOR
SELECT a.name,b.name
FROM sysobjects a,syscolumns b
WHERE a.id=b.id
AND a.xtype='u'
AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167)
OPEN Table_Cursor
FETCH NEXT FROM Table_Cursor
INTO @T,@C WHILE(@@FETCH_STATUS=0)
BEGIN
EXEC(
'UPDATE ['+@T+']
SET ['+@C+']=REPLACE(CONVERT(VARCHAR(4000), ['+@C+']), ''' + @TextToRemove + ''', '''')')
FETCH NEXT FROM Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor
GO
/*
Sample USAGE (see below)
Also replace accordingly. There are exploits which involves a different
.js path (like banner82.com or adword71 et al)
*/
UPDATE (6/19/2008) I would highly recommend securing you browsers using javascript/java/flash etc blockers, adware and spybot protection in place. I had a recent post about Firefox and NoScript in the following link: Browsing Security with NoScript. The security of being able to block javascript is significant. There are only a number of domain/sites that the add-in recognizes in it's white list so even javascript from the site itself is blocked (you can allow it easily) so how much more hidden javascript from 3rd party sites (such as what is seen in this exploit).
Also look into antispy products like Spybot Search & Destroy which would prevent you from accessing known blacklisted domains among other things. It update automatically though but if you "immunize" very often, you're increasing the chances of not running into malicious site. Others include the free Windows Defender for genuine windows users, adaware which offers real time protection (though haven't been very succesful with this one) and it might also be time to look into getting a Personal Firewalls such as ZoneAlarm Personal Firewall or you might even want to get professional editions of that which you want for added protection.
Other References:
MUST READ: SQL Injection from Microsoft Security Vulnerability Research and Defense Blog
MUST READ: Security Development Lifecycle post on SQL injection (Michael Howard)
Information on these autmated attacks from SANS Internet Storm Center
ZDNet on Fast-Fluxing SQL injection attacks executed from the Asprox botnet (directly related to this exploit)
Filtering SQL injection from Classic ASP – (** restricting access to the objects being exploit such as sysobjects/syscolumns seems like the quickest solution but feel free to explore this too – note though that IMHO this will have a performance hit on your site)