Latest TweetsGreat post about the latest power grab: www.eff.org/deeplinks/2018/09/…
Perishable Press

What a Malicious Server Scan Looks Like

Like most sites on the Web, Perishable Press is scanned constantly by malicious scripts looking for vulnerabilities and exploit opportunities. There is no end to the type and variety of malicious URL requests. It all depends on the script, the target, and the goal of the attack. Malicious scripts generally seek one of two things:

  • A resource that can be used to gain access and/or compromise security
  • A process vulnerability triggered by malicious request and used to gain access

Here is an example of what I’m talking about, a series of requests from the ubiquitous “contac.php” scan:

http://example.com/contac.php
http://example.com/subdirectory/contac.php
http://example.com/subdirectory/2010/contac.php
http://example.com/subdirectory/2010/11/contac.php
http://example.com/subdirectory/2010/11/09/contac.php
http://example.com/subdirectory/2010/11/09/some-post/contac.php
.
.
.

Looking for my Contact Form? I don’t think so. The “contac” script requests series of URLs from the target site, apparently looking for some payload script named “contac.php”. Pretty sneaky naming of the file, which most likely “blends right in” with other similarly named PHP on the server. Fortunately the presence of countless, random requests for a misspelled file jump right out of the 404 error logs.

To stop this nonsense from chewing up your system resources, we lift a finger with the following HTAccess:

RedirectMatch 403 /contac\.php$

That slice simply returns a 403 Forbidden error to all requests for that stupid file. Will it ever interfere with normal URL requests? Only if you can’t spell “contact”.

Other examples of malicious server scans

Here is another example of a typical server scan, obviously looking for some process vulnerability, as the requested file is site-specific and changes form with each request (my domain changed to example.com):

http://example.com/08/02/the-5-minute-css-mobile-makeover
http://example.com/2009/08/02/the5-minutecssmobilemakeover.html
http://example.com/2009/08/02/the-5-minute-css-mobile-makeover.html
http://example.com/2009/08/02/02/the-5-minute-css-mobile-makeover.html
.
.
.

If you’re seeing this type of 404 request pattern in your access/error logs, check/verify that the file exists or doesn’t exist. These types of malicious scans are some of the most difficult to prevent, largely due to the randomness of the “character scrambling” of the request, but also because of the generality of the pattern. You could reduce the number of these types of requests by matching against the “.html” extension, but only if you’re certain that they aren’t used on your site. A typical WordPress blog might be a good example.

In my experience, the more general the request pattern (scan), the lower the threat. The most this particular sad scan is going to get from most servers is a series of 404 errors, which are easier to get and hardly useful for well-configured machines. Moving on..

Endless malicious requests

If you’re staying vigilant with your admin duties, you don’t need me to explain what malicious requests look like. They happen all the time, wasting resources and slowing things down for legitimate visitors.

To demonstrate the monotony and perpetuity of malicious scanning, consider my old Angry-Birds site, which features a complete map of the entire Angry-Birds game, something like 100+ pages online. Awesome for AB fanz, but sadly also a huge target for teh evil scripts. To get an idea of the impact, consider the following log excerpts (note: Angry-Birds site now offline, so replaced domain name with example.com in the following log entries).

http://example.com/maps/chapter-4/theme-9/level-9-8/).css(
http://example.com/maps/chapter-4/theme-9/level-9-8/);f=e.css(
http://example.com/maps/chapter-4/theme-9/level-9-8/,c.css(this[a],
http://example.com/maps/chapter-4/theme-9/level-9-8/;if(c.css(this[a],
http://example.com/maps/chapter-4/theme-9/level-9-8/)&&this.style){j.display=c.css(this,
http://example.com/maps/chapter-4/theme-9/level-9-8/);this.elem.style.display=a?a:this.options.display;if(c.css(this.elem,
http://example.com/maps/chapter-4/theme-9/level-9-8/],rb=s.defaultView&&s.defaultView.getComputedStyle,Pa=c.support.cssFloat?
http://example.com/maps/chapter-4/theme-9/level-9-8/},cur:function(a){if(this.elem[this.prop]!=null&&(!this.elem.style||this.elem.style[this.prop]==null))return%20this.elem[this.prop];return(a=parseFloat(c.css(this.elem,this.prop,a)))&&a>-10000?a:parseFloat(c.curCSS(this.elem,this.prop))||0},custom:function(a,b,d){function%20f(j){return%20e.step(j)}this.startTime=J();this.start=a;this.end=b;this.unit=d||this.unit||
.
.
.
http://example.com/maps/chapter-4/theme-9/level-9-10/).css(
http://example.com/maps/chapter-4/theme-9/level-9-10/);f=e.css(
http://example.com/maps/chapter-4/theme-9/level-9-10/,c.css(this[a],
http://example.com/maps/chapter-4/theme-9/level-9-10/;if(c.css(this[a],
http://example.com/maps/chapter-4/theme-9/level-9-10/)&&this.style){j.display=c.css(this,
http://example.com/maps/chapter-4/theme-9/level-9-10/);this.elem.style.display=a?a:this.options.display;if(c.css(this.elem,
http://example.com/maps/chapter-4/theme-9/level-9-10/],rb=s.defaultView&&s.defaultView.getComputedStyle,Pa=c.support.cssFloat?
http://example.com/maps/chapter-4/theme-9/level-9-10/},cur:function(a){if(this.elem[this.prop]!=null&&(!this.elem.style||this.elem.style[this.prop]==null))return%20this.elem[this.prop];return(a=parseFloat(c.css(this.elem,this.prop,a)))&&a>-10000?a:parseFloat(c.curCSS(this.elem,this.prop))||0},custom:function(a,b,d){function%20f(j){return%20e.step(j)}this.startTime=J();this.start=a;this.end=b;this.unit=d||this.unit||
.
.
.
http://example.com/maps/chapter-4/theme-9/level-9-11/).css(
http://example.com/maps/chapter-4/theme-9/level-9-11/);f=e.css(
http://example.com/maps/chapter-4/theme-9/level-9-11/,c.css(this[a],
http://example.com/maps/chapter-4/theme-9/level-9-11/;if(c.css(this[a],
http://example.com/maps/chapter-4/theme-9/level-9-11/)&&this.style){j.display=c.css(this,
http://example.com/maps/chapter-4/theme-9/level-9-11/);this.elem.style.display=a?a:this.options.display;if(c.css(this.elem,
http://example.com/maps/chapter-4/theme-9/level-9-11/],rb=s.defaultView&&s.defaultView.getComputedStyle,Pa=c.support.cssFloat?
http://example.com/maps/chapter-4/theme-9/level-9-11/},cur:function(a){if(this.elem[this.prop]!=null&&(!this.elem.style||this.elem.style[this.prop]==null))return%20this.elem[this.prop];return(a=parseFloat(c.css(this.elem,this.prop,a)))&&a>-10000?a:parseFloat(c.curCSS(this.elem,this.prop))||0},custom:function(a,b,d){function%20f(j){return%20e.step(j)}this.startTime=J();this.start=a;this.end=b;this.unit=d||this.unit||

See the pattern? And it just goes on and on, without end. And this is just one of many different types of malicious scans. Fortunately you’ve got geeks like me who study this garbage and provide security tools like the 4G Blacklist to help protect your site. And speaking of the 4G..

Update

I originally intended to post an .htaccess snippet along with this last example, but somehow managed to forget until now. Here is a simple line of .htaccess that will, remarkably, stop this type of relentless scan dead in its tracks:

 RedirectMatch 403 \)\.css\(

That simple rule will prevent malicious scans of the type described above, which is literally any request containing the character sequence “).css(” anywhere in the URL (excluding the query string).

The 5G Blacklist

After many months of careful analyses and testing, the 5G Blacklist is ready for beta testing. Leave a comment if you want to help out. I’m running the script now here at Perishable Press, which runs both older and current versions of WordPress, amongst other things. I have also had much success with the 5G at the Angry-Birds site, which runs quite a few popular WordPress plugins (including Simple Forum). So far so good, but it would be great to fine-tune even further before public release.

Jeff Starr
About the Author Jeff Starr = Web Developer. Book Author. Secretly Important.
Archives
13 responses
  1. Michael Clark February 8, 2011 @ 2:52 pm

    I’ll test the 5G list on a couple of my sites.

  2. I’m game for bug testing your 5g blacklist… have been relying on a skewed version of the 4g on my own sites + they’ve yet to fail me…

  3. Peter Bockenhauer February 8, 2011 @ 3:43 pm

    Would be good to add how you access and parse your logs. We know you are not using a WP plugin, do you just parse the Plesk error logs?

    • Jeff Starr

      I’ll analyze any access/error log I can get my hands on, but mostly I just use the default (Plesk) server logs. For the actual analysis, I don’t use anything other than a good text/code editor such as Dreamweaver, Textmate, Coda, etc.

      I’ve tried some of the automated methods, but wasn’t satisfied with the results. I’ve always done it manually, and these days do it almost subconsciously in the background.

      It really doesn’t matter how you keep an eye on things, as long as you take the time to do it.

  4. Jeff Starr

    @Brent, @Michael: Thanks, I’ll post a link to the 5G beta here soon. I appreciate your help!

  5. Dan Zappone February 8, 2011 @ 5:57 pm

    I’m game. I’ve seem to get a fair amount of funky traffic to the ten or so sites I run with WordPress.

  6. Scott Cariss February 9, 2011 @ 2:06 am

    I would like to beta test the 5G blacklist. I’m using the 4G on one of our big clients sites now and is working well. Only had to remove one bit as one of the plugins they use, use the word config in the url.

  7. Thanks for the upcoming 5G list.

    I must admit to being pretty lax with site security, mainly because I’m unsure how to go about finding these types of attacks.

    I’ve noticed on my AWstats, when looking through the logged 403 errors, many requests were for completely non-existent pages. The requested URLs used correct page and subfolder names from my site but were randomly put together into senseless file paths that went nowhere.

    Very strange.

    Cheers
    I

  8. Jeff Starr

    Here it is!

    https://perishablepress.com/5g-firewall-beta/

    Beta testers please comment on that post instead of this one. Thanks!

  9. I’m not so sure stuff like ).css( is malicious.

    I’ve been seeing a lot of those lately too. When I look up the IP addresses with something like http://maxmind.com they seem to always be coming from Hughes Network Systems or DirectWay, which I believe are the same satellite Internet provider.

    Hughes runs everyone’s traffic through some sort of proxy that rewrites the page content, I assume to try to squeeze the appearance of speed out of their relatively slow connection. The problem is it frequently breaks pages, links, css, and javascripts resulting in some of the urls you’ve logged. It has been doing this for many years.

    I’ve had this sort of problem with several legitimate customers on one of my sites. They were subscribing to my web app but it failed to work as long as they were connected through their satellite service.

    I tracked down the problem in detail at one time, boiled it down to a repeatable set of tests, and tried to contact Hughes. They have no means to deal with such reports and no obvious way to contact them unless you are a customer of their service.The best I ever got was a response saying I might be able to send a snail mail letter to their general headquarters address.

    It got so frustrating that I finally did end up blocking some URLs with a 403. When those few customers complained I provided an e-mail with the details and told them to contact Hughes support and tell them to stop breaking the Internet. Some of the problems eventually went away but they always get replaced with new ones.

    • Jeff Starr

      Look again at the series of requests posted in the article.. that is just a snapshot of a larger, perpetual scan pattern that doesn’t look anything like typical/random proxy traffic.

      Either way, as requested the ).css( patterns demonstrate premeditation, malice, and should be blocked, which is what the 5G Blacklist is designed to accomplish – without interfering with regular, legitimate traffic.

      What you say about Hughes page-content proxy-rewrite script is just absolutely scary. Why would they do that? Crazy.

  10. can we analyze the malicious queries using Google Analytics or other third party ?

  11. Alexandre Giesbrecht February 21, 2011 @ 11:14 am

    A couple times what I found on my logs were something like domain.com/wp-login.php. Lots and lots of times in a small time span. But theye were apparently harmless, since my wp-login.php is inside a folder, which is not visible from the URL (site URL is just domain.com, without the folder, even though it’s visible through FTP).

[ Comments are closed for this post ]