SQL Injection Attack Part 2
My partner and I worked all day to fix open queries throughout all of our code with cfqueryparam tags. We restored the DB and after only a short while they were able to infiltrate it again. So we double checked the site and added of code that intercepts injection attacks and restored the DB again.
This time it took longer, but they eventually hit us again! Finally, after nearly 24 hours of messing with code I think we are holding them off... but they are continually hammering pages on the site attempting the injection.
Their constant page requests from random IPs is killing our site response time. Is there any way to stop all the mal-traffic? I friggin hate jerks that do this crap and I wish there was a way to just punch them directly in the face.
The general idea is that they are trying to insert a string of code that serves a javascript file on our site from some remote site. It's horrible because it immediately prompts a visitor to our site to download a nasty ActiveX control.
Then just abort the page. It should take the bulk of the load off the server since at that point you don't have to process the rest of the page. At that point you know who they are so you could do anything - even redirect them to the same site they're trying to send your users to =P.
Other than that, you'd need a way to scan the url before CF processes it. Depending if you're running on *nix or windows you could create an .htaccess file to do the same thing. I did a quick search and Microsoft has a tool called URLScan that can do some of this as well, and apparently IIS 6 has some built in functionality also. So to replace a CF hack, I would start there and see if you can utilize some built-in functionality of the web server to filter the requests.
I've never known anyone being victim to a SQL attack...I know the basics but I'm interested in learning more.. I was somewhat aware of the dangers when I wrote a particular site, but I'm not sure I knew enough to close ever hole.
You see you can separate sql statements with a semi-color so the attackers are appending data to the url so that they can execute some sql code. In this case though the SQL code is very cleverly written. It uses an ascii string which contains the payload of the attack. Take a look at this:
DECLARE @S CHAR(4000) //declares a new variable
SET @S=CAST(0x4445434C41524520 ... 736F7220 AS CHAR(4000)) //sets the variable to a string of executable code which is written to deliver some harmful payload, like append a malicious external javascript at the end of all of your text fields in every table of your database(done with a cursor).
EXEC(@S) //execute the code.
This is all sent through the URL like so: page.cfm?pageid=7;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x44004500 ... 06F007200%20AS%20NVARCHAR(4000));EXEC(@S);
So in your SQL if you don't make sure that PageID is in fact an integer and has a reasonable length for an integer, then this will get executed as written. Thats why you need to your CFQueryParam to lock down the variables that you use inside CFQuery tags.
So it isn't just a form that can cause the damage, any time you use the url or open a query to a variable which isn't verified you could be setting the stage for an attack.
And yeah, if it got through it would append the javascript string to virtually every text field in the database... or at least in key tables. I didn't check every table.
This works like a charm.
If you don't have access to your server I would request your hosting company to install this tool.
http://portcullis.riaforge.org/