Forum Moderators: open
/links.php?\';DeCLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C
IP Address: 69.73.82.nn
User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; FunWebProducts; .NET CLR 1.1.4322)
[edited by: incrediBILL at 9:09 pm (utc) on Aug. 17, 2008]
[edit reason] Obscured IPs [/edit]
[isc.sans.org...]
So what does this do? It's actually a very common way that is used by hackers when they are exploiting blind SQL injection attacks. The idea is to create a condition that, if satisfied, will delay the execution of the script for a certain time period. So, the attacker watches the response time and if it was delayed, he knows that the SQL command was executed successfully.
Basically, they're probing your site to see if you're vulnerable and building a list of sites to infiltrate in the near future.
The intention is to replace page code with javascript code in any vulnerable SQL database it can get into. If your SQL code is properly crafted it's not likely to be vulnerable. Even so it's a good idea to trap and kill the attempts.
I assume the example querystring you give is a shortened version of the actual one. It's generally about 1300 bytes unless something has corrupted it.
Also, is the lower case E in DECLARE exactly as you received it? If so, that's new.
The User-Agent is not a usual one for these injections, in my experience. They tend to be bare-bones MSIE with no add-ins such as the FunWebProducts spyware. Typically they are...
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)
They can be differentiated from "real" MSIE using secondary header characteristics but the easiest method is on length of querystring - trap anything over, say, 600 bytes.
Having said the usual UA is as above (99.99% plus), I have occasionally trapped this injection attempt with a slightly different UA - today with InfoPath but mostly just a slight variation on a basic MS UA. It has been suggested that there is a copycat around and this may account for it. The bulk of hits are believed to come from a botnet, possibly Russian. Certainly almost all hits come from a broadband or similar IP range rather than from a server farm.
A few days ago a whole 24 hours went by without a single hit - very unusual. Today looks to be almost as hit-free, with only a dozen or so hits in the past 15 hours.
The subect is covered at...
[dynamoo.com...]
[edited by: incrediBILL at 10:33 pm (utc) on Aug. 17, 2008]
[edit reason] fixed link [/edit]
If your SQL code is properly crafted it's not likely to be vulnerable. Even so it's a good idea to trap and kill the attempts.
A more practical approach to securing the whole site is to install global front-end firewall that blocks SQL commands from being fed to your server using GET or POST in the first place. Additionally, filtering out embedded URL's used in file injection vulnerabilities clamps down on that issue as well. This allows you to install all sorts of Open Source software without worrying about the security of each component.
You can do some rudimentary filtration with .htaccess which will stop many of these SQL injection scripts dead in their tracks.
Unfortunately this isn't a good solution for technical forums that discuss SQL, or allow file uploads, but exceptions can be made for specific pages while denying the rest of the site.
/dir/file.asp ';DeCLARE%20@S%20CHAR(4000);SET%20@S= ......... etc
163.139.103.nnn JP
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 2.0.40607)
You can do some rudimentary filtration with .htaccess which will stop many of these SQL injection scripts dead in their tracks.
Could you please give an example?
UAs always different/spoofed --
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0)
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SIMBAR={1CD2D5BE-794B-4cd0-B172-24E0A70958F0}; .NET CLR 1.1.4322)
(Etc.)
FWIW (& Jim no doubt has a better way of doing this:) --
RewriteCond %{REQUEST_URI} ^(.*)CAST(.*) [OR]
RewriteCond %{REQUEST_URI} ^(.*)DECLARE(.*) [NC,OR]
(CAST intentionally uppercase because of site-specific file names.)
Staffa - got 15 with the lower-case E since 15th Aug to date. All of these were using a "non-standard" UA - ie not one of the two I mentioned above (which I nickname SV1 and 50727 for convenience). The volume of the new ones is low - compare 15 in a couple of days to the 1000 odd I've had since 08:30 this morning (writing at 19:30 so that's 11 hours). Seven of the 15 had InfoPath in the UA, the others various.
I would say the DeCLARE ones are copycats, possibly from solo players rather than the big botnet.
The moratorium lasted 25 hours and they came back with a vengeance at 08:30 this morning. This matches the one a few days ago.
Blend27 - wouldn't iframe be encoded in the string rather than plain text? Good idea for other purposes, though. Drop and srs not so good if the site is using querystrings for selecting products etc there is a possibility of them being a valid substring.
the Ideal situation would be to use numeric values for selecting products. As far as the IIS GOES, the technology is usually ASP or CF, so you could loop over a list I provided above and if value is found in cgi.query_string block the request the programmatic way.
here is the CF Way:
<cfset booList = "declare,delete,truncate,convert,insert,update,select,meta,script,exec,drop,iframe,srs,source">
<cfloop list="#booList#" index="i">
<cfif FindNoCase(cgi.query_string,i)>
<cfabort>
</cfif>
</cfloop>
dstiles, I use this list to filter many things not just GET or POST inputs. Just set your UA to < iframe src="http://yahoo.com" height="800" width="600" >< /iframe > in FireFox UA Switcher, then try viewing your useragents screen in some of the popular log viewing software.
IIS servers have very poor software offerings
When I said firewall I meant software firewall in this case.
The newer IIS servers are much better and even on the old ones you can create software that is run preceding all page views and work as an intermediary firewall, it's just not easy for everyone to do.
See this thread on SQL Injection in the databases forum [webmasterworld.com] for possible solutions to your problem.
[edited by: incrediBILL at 8:17 pm (utc) on Aug. 18, 2008]
I used to run a third-party software firewall that blocked whatever I decided before it hit the IIS server. Unfortunately I had cause to stop trusting it not to kill my own access to the server. In any case they usually seem to involve getting the datacentre involved.
I run a home-grown trap at the head of every ASP page I serve up - have done for several years. Originally it only needed to cope with bad bots and scrapers but this past year it's become really messy and I'm in the middle of rebuilding it - the test suite is the worst part! :(
The problem with this kind of system is: the bot/etc has to be let through before it can be tested and rejected. A decent firewall, hard or soft, should block before it got anywhere near the server.
The figures I gave for number of SI hits, by the way, is only what I see in logs and is lower than actuality. During the first few weeks of the blitz I blocked IP ranges in IIS's Security tab for the major sources - Vietnam, Thailand, some of China, Mexico, Brazil, Argentina. That knocked the hits back by about 70% at the time. Most of it now comes from Asia but with a high component of USA and (Eastern?) Europe. Unfortunately I can't block as much as I'd like because some of my customers won't let me - in fact one is asking about opening up a lot of countries. :(
One thing I've noticed, by the way: almost all hits seem to be coming from dynamic IP ranges. Makes sense, I suppose, given the general nature of the infection pattern.
A decent firewall, hard or soft, should block before it got anywhere near the server.
In this case it's a web page firewall and the purpose is to protect vulnerable web pages so IMO it's doing the job of a decent firewall since it's in advance of the page with the problem.
FYI, I don't typically block at the full server firewall unless I specifically specify it's for HTTP requests only since blocking data centers to cut them off from scraping your site can also cut your site off from getting order notification emails (SMTP) when you buy products, etc.
It's always a balancing game to protect the server and not shoot yourself in the foot.
[edited by: incrediBILL at 10:46 pm (utc) on Aug. 18, 2008]
I would prefer to block the SQL Injection junk as early as possible. I know I'm protected but it makes me nervous! I have even broached the subject of a pipe-wide block with my hosting company. They don't need to block the IP, just the hit. If they did block it that should make a very large datacentre much safer and reduce the impact of the attack. I doubt it'll come to anything.
[edited by: incrediBILL at 9:40 pm (utc) on Aug. 28, 2008]
[edit reason] removed specifics [/edit]
This is a pretty nasty multi-pronged attack from what I can gather and it seems Cold Fusion sites are possibly a target this time.
We are seeing tons of test injections in our error logs...
Details here: [microsoft.com...]
We had a hosting company install it, works like a charm!
Supported Operating Systems: Windows Server 2003; Windows Server 2008; Windows Vista; Windows XP
Will the following type of code from all incoming variables protect my site from these kind of attacks?
If I do the following with the incoming data will my programs be safe?
$v = stripslashes($_GET['v']); //get v and make sure they didn't add slashes
$v = addslashes($v); //add slashes to keep people from closing the quote in the search box and damaging the database
LifeinAsia, give my suggestion a try. Works on 2000
locks it down a bit too much and killed my site.
