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.

About the Author

Jeff Starr = Web Developer. Security Specialist. WordPress Buff.