Latest TweetsWordPress and the Blank Target Vulnerability (aka rel noopener + noreferrer): perishablepress.com/wordpress-… #WordPress #security #html
Perishable Press

Blacklist Candidate Number 2008-02-10

Welcome to the Perishable Press “Blacklist Candidate” series. In this post, we continue our new tradition of exposing, humiliating and banishing spammers, crackers and other worthless scumbags..

[ Photo: Bob Barker points a finger ] Like many bloggers, I like to spend a little quality time each week examining my site’s error logs. The data contained in Apache, 404, and even PHP error logs is always enlightening. In addition to suspicious behavior, spam nonsense, and cracker mischief, this site frequently endures automated and even manual attacks targeting various XSS exploits, WordPress vulnerabilities, and other potential security holes. Although the number of successful attacks remains relatively small, the very nature of some of the attacks serves to threaten site performance, security and stability. Such is the case of blacklist candidate number 2008-02-10: IP address 128.111.48.138. This hapless turd just heard Rod Roddy’s eminent voice boom:

Scumbag number 2008-02-10, “COME ON DOWN!!” — you’re the next baboon to get banished from the site!

Synopsis

On January 31st, 2008, IP address 128.111.48.138 attempted to access an apparently random array of legitimate URLs, each appended with either of the following cryptic character strings:

[permalink]/x%7b.//000Ooz,m4//000____::um,qymuxH%3bmJ.5G+D//001F00Dox%7b1rF9DrEtxmn7unwp%7dqDr/

[permalink]/1x2n6l6bx6nt//001mAFC(-~l-xAou6.oCqAjB4ukkmrntoz1A//0011C/uikqijg4InjxGu.k

Alternating these two appended strings, the attacker hit my site over 200 times, beginning at 06:33 and ending at 08:14. Around half of the requests referred from a matching-URL query-string, while the others were targeted via matching URL without a query string (see log below for details). To secure the site, the associated IP and offending character strings were blocked on February 3rd to prevent further attacks. No similar attacks have occurred since the blacklisting.

Identification

According to the reverse-lookup results returned via kloth.net’s free DNS utility, the identity of IP address 128.111.48.138 is as follows:

Host   48.111.128.in-addr.arpa
Type   NS
Value  ns1.ucsb.edu, ns2.ucsb.edu, funnies.cs.ucsb.edu

IP Address Contact Information

OrgName:    University of California, Santa Barbara 
OrgID:      UCSB
Address:    Office of Information Technology
Address:    North Hall 2124
City:       Santa Barbara
StateProv:  CA
PostalCode: 93106-3201
Country:    US

NetRange:   128.111.0.0 - 128.111.255.255 
CIDR:       128.111.0.0/16 
NetName:    UCSB
NetHandle:  NET-128-111-0-0-1
Parent:     NET-128-0-0-0-0
NetType:    Direct Assignment
NameServer: NS1.UCSB.EDU
NameServer: NS2.UCSB.EDU
NameServer: KNOT.BROWN.EDU

# ARIN WHOIS database, last updated 2008-02-09 19:10

Further, here is the user agent recorded for every entry in the access log:

Mozilla/5.0 (compatible; heritrix/1.12.1 +http://www.cs.ucsb.edu/)

Discussion

What on earth was the attacker trying to achieve using these alternating character strings? I honestly have no idea. Frankly, I don’t have the time to research every cryptic cracker technique that crosses my logs. One thing is certain, however, the attack was deliberate, automated, and hostile. Fortunately, my server endured the onslaught and infiltration was prevented. If you have information regarding the nature or purpose of this increasingly common type of attack, please share your insights with the community. I would love to know more about the mysterious character strings.

Details

Here are the first and last log entries for attack. The entire set of excluded entries1 is very similar to either of the following:

Note: in the following log entries, each instance of perishablepress.com was replaced with example.com. This was required to prevent endless 404 errors from googlebot constantly crawling plain-text URLs.
TIME: January 31st 2008, 06:33am
404: *https://example.com/press/tag/poetry/1x2n6l6bx6nt//001mAFC(-~l-xAou6.oCqAjB4ukkmrntoz1A//0011C/uikqijg4InjxGu.k
SITE: https://example.com/
SOURCE: Perishable/Perishable
REFERRER: https://example.com/press/tag/poetry/
QUERY STRING: 
REMOTE ADDRESS: 128.111.48.138
USER AGENT: Mozilla/5.0 (compatible; heritrix/1.12.1 +http://www.cs.ucsb.edu/)
REMOTE IDENTITY:
.
.
.
[~200 similar records omitted for clarity]
.
.
.
TIME: January 31st 2008, 08:12am
404: *https://example.com/press/tag/metadata/x%7b.//000Ooz,m4//000____::um,qymuxH%3bmJ.5G+D//001F00Dox%7b1rF9DrEtxmn7unwp%7dqDr/
SITE: https://example.com/
SOURCE: Perishable/Perishable
REFERRER: https://example.com/press/tag/metadata/x%7B.//000Ooz,m4//000____::um,qymuxH;mJ.5G%20D//001F00Dox%7B1rF9DrEtxmn7unwp%7DqDr
QUERY STRING: 
REMOTE ADDRESS: 128.111.48.138
USER AGENT: Mozilla/5.0 (compatible; heritrix/1.12.1 +http://www.cs.ucsb.edu/)
REMOTE IDENTITY:

Let’s kill this noise..

Blacklist

Candidate #2008-02-10, come on down — you’re the next contestant on the htaccess blacklist! Blocking via .htaccess is best for performance, but if that is not an option, you can always block this month’s Blacklist Candidate via PHP. Let’s look at each technique.

Block via .htaccess

Here are two easy ways to blacklist this scumbag. The first method (and my preferred choice) is to block select portions of the URL character-string appendages:

# blacklist candidate 2008-02-10: block cryptic character string attacks
<IfModule mod_alias.c>
 RedirectMatch 403 xAou6
 RedirectMatch 403 qymux
</IfModule>

And of course, the second blocking method is to simply deny the attacker’s unique IP address:

# blacklist candidate 2008-02-10: cryptic character strings
Deny from 128.111.48.138

Block via PHP

Or, if .htaccess is not an option, you can do the job with a small slice of PHP:

<?php // blacklist candidate 2008-02-10: cryptic character strings
$deny = array("128.111.48.138");
if (in_array ($_SERVER['REMOTE_ADDR'], $deny)) {
   header("location: http://www.google.com/");
   exit();
} ?>

Thanks for playing, #2008-02-10 — we wouldn’t have done it without you!

Download

1 For the purists among us, here is a copy of the logged activity recorded for this month’s Blacklist Candidate.

Download log file »

Jeff Starr
About the Author Jeff Starr = Web Developer. Book Author. Secretly Important.
Archives
5 responses
  1. Thanks for the heads up! IP added to my .htaccess :)

    By the way, I have a question:
    Which one is better in terms of server load/usage…blocking via PHP or .htaccess?

  2. Hi, I was wondering what script do you use to detect bad robots? I searched in Google but they were all old scripts.

  3. Jeff Starr

    @Lisa: As far as I know, blocking directly via Apache conserves system resources that would otherwise be needed to finance PHP. I believe the same is true for URL rewriting, redirection, etc. All of my blocking and rewrites are executed at the Apache level (via htaccess).

    @Ibnu: Actually, I hand-check my error logs once a week (or more) for nefarious behavior. Thus far, I have not found a script that is able to provide the precision and accuracy inherent via manual examinations. When crunched for time, I focus on my site’s 404 error logs. They are perhaps the most revealing where crackers and spammers are concerned.

  4. I have had similar issues with all my web sites with little or no help from my web hosting company.

    I ultimately created a PHP script that detects strange requests that do not match what I offer on my web site; and then it promptly blocks the offending IP address to the .htaccess file. As an added bonus; the script emails a copy of the offense to myself, writes the entire offense to a mySQL database, and finally displays a fantastic (KMA!) message to the user in case they are at the computer.

    All this happens from a little script no more than 50 lines of code and some extra lines added to my .htaccess files. The huge plus is that the entire process takes only 1 second to block the idiots, bans them permanently, stops their scanning immediately, and it is 99% automatic!

    The only headache is to actually scan your logs for anything that was missed and add the offending access string to your .htaccess files. Easy work – look for my script to debut in a few!

  5. Jeff Starr

    Inque187,

    That sounds incredibly useful! I was so inspired by reading your comment that I was ready to drop everything and install the script then and there.. until I realized that your idea isn’t yet available! I almost cried :(   By all means, please be so kind as to share your project with the community as soon as it is available! Until then, I guess I’ll just have to find something else to do.. ;)

[ Comments are closed for this post ]