SQL injection attacks - banner82 script

May 24, 2008 23:30 by Ryan Garaygay

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. :D

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.

*/

IF EXISTS (
  SELECT * FROM dbo.sysobjects
    WHERE
      ID = OBJECT_ID(N'[dbo].[RemoveText]')
      AND type in (N'P', N'PC'))
DROP PROCEDURE [dbo].[RemoveText]

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)

*/

EXEC RemoveText '<script src=[x]></script>'
-- WHERE [x] is a URL/link to a .js and may vary depending on what hit your site  

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)

A more generic Search and Replace script

Digg It!DZone It!StumbleUponDel.icio.usReddit

Related posts

Comments

September 9. 2008 07:54

giorgio

thanks your post is very helpfull!!!!

giorgio

September 9. 2008 10:56

Ryan Garaygay

Giorgio,

Glad it helped. Smile

Ryan Garaygay

September 9. 2008 14:46

Sloan

I'm getting two errors - invalid 'sys.objects' and invalid column name 'object_id'. Guessing this is a SQL issue (I thought I was on a MSSQL 2005 sever, but maybe not?). Ideas?

Thanks for the code btw, I was taking the long route until I saw this!

Sloan

September 9. 2008 15:03

Ryan Garaygay

Hi Sloan,

The error is being caused by the script before the DROP PROCEDURE.

Apparently it will only work for SQL 2005 (sorry for that). Will see what is the equivalent that will work both SQL 2000/2005 (don't have SQL 2000 readily available) but since the script is only included to determine if a procedure with the name already exists, you can get rid of the check. Make sure though that a procedure with the same name doesn't exist (eg. drop it manually)

Ryan Garaygay

September 9. 2008 15:14

Ryan Garaygay

Just updated the script used to check if the procedure already exists. I believe it should now work with SQL 2000. If you're having an issue and using SQL 2005 though I'm not sure what could be wrong and please feel free to drop any question or additional info.

Ryan Garaygay

September 15. 2008 23:52

Sloan

Hi Ryan. Your updated code works on SQL 2000, saved an immense amount of time. For anyone scrolling through the backlog - a few tips.

* This exploit / injection attack is mostly happening on classic ASP scripts. The automated bots looks through google for pages ending in ASP.
* You need to change your code to make it stop. Use stored procedures instead of select statements, build a new site, go into hiding or something. Deleting the injections won't solve the problem.
* Check your logs to see what pages are causing the problems.

Don't want to totally recode an aging web app? Try putting this code in the header of your pages. It will look for long strings of code and error out if anything over the defined amount is entered.


if len(Request.Servervariables("Query_String")) > 40 then
response.clear
response.write "Invalid page access"
response.write
response.end
end if

Change the 40 to a higher number if you need. Credit is due to webmasterworld for that fix.

-S

Sloan

September 22. 2008 05:26

Jax

Thanks for all your help! That script worked like a champ.
We also found (if you're running IIS) download URLScan from Microsoft and change the QueryString length accepted to 200. Stopped all injections for us. Also you can go into the logs and see how many times URLScan is blocking this hack. We get pry 50 a day.

Thanks Again!
Jax

Jax

September 22. 2008 05:39

Ryan Garaygay

Great info on URLScan Jax. This is the 1st time I've come across such and very interesting.

For reference, here's a link to URLScan : technet.microsoft.com/en-us/security/cc242650.aspx

Read through the article as you might be able to achieve the same functionality using built-in IIS 6.0 features.

At least we have a reference that a 200 maxQueryLength value works fine, thanks to Jay. But it could differ from site to site as you might need/have longer query strings (a bad sign but who knows). There are also some available information about this from IIS or ASP.NET articles/blogs and will look into these default, reasonable and possibly optimized values too.

Thanks again Jax for the info and for dropping a comment.

Ryan Garaygay

December 21. 2008 06:34

Rob

Obviously good coding following guideline on parameter sanitisation and white listing rather than black listing user supplied content is the best approach however if you have lots of large old systems then rewriting them may not be feasible.

See

blog.strictly-software.com/.../...ection-hack.html

for a list of plasters that are quick to implement and work (reduced logged hacks by 95%)

-Deny webuser access to system views such as sysobjects,syscolumns if not required by site.

-Use a server wide ISAPI URL rewrite ini file to detect and bounce hackers before any application code is run.

-If you don't have ISAPI rewrite available then include a global include file that uses similar regular expressions to detect common fingerprints and bounce user to a banned page.


Thanks

Rob

Add comment


(Will show your Gravatar icon)  

  Country flag

[b][/b] - [i][/i] - [u][/u]- [quote][/quote]



Live preview

February 9. 2010 13:00