Blacklist Candidate 2012-11-13: Evil Scanner Edition

It’s been awhile since I’ve posted one of my Blacklist Candidate series articles. It’s always fun for me to talk (or write) about security related issues, especially when a quick slab of .htaccess can be used to take care of business. And that’s exactly what we have in this edition of the series, where I’m pleased to bring you Blacklist Candidate Number 2012-11-13: the “evil” scanner. Instead of scanning your site, collecting data, and moving on, Mr. 2012-11-13 continues to scan the same sites for the exact same set of files. And by “continues” I mean over and over and over and over again..

It went from, “hmm, what have we here” to “alright dude, you’ve already tried those requests,” and then eventually to “sheesh, what an douche bag,” and finally to “come on down, you’re the next knuckle-dragging buffoon to get blacklisted from the site.” And so, in classic Blacklist-candidate style, let’s snuff this latest wave of evil server scanning asap.

Synopsis

It’s pretty basic really, something out there is looking for open doors on an unknown set of websites. They’re hitting some of my larger WordPress sites and that’s really all I know. Hopefully others reading can confirm or deny presence of this activity in their access logs. One reason to suspect it’s more widespread is that the requested URLs target a variety of different CMSs, as we’ll see here in moment.

The scan itself is always the same, probing for registration forms, signup forms, join forms, and similar with URLs including these:

http://example.com/register.php
http://example.com/user/register
http://example.com/signup.php
http://example.com/signup

http://example.com/member/join.php
http://example.com/tiki-register.php
http://example.com/ucp.php?mode=register
http://example.com/tools/quicklogin.one

http://example.com/join.php
http://example.com/YaBB.cgi/
http://example.com//WHMCS
http://example.com/{$itemURL}

These are just a handful of examples from the scan, but should give you a good idea of what to look for in your logs. They’re actually quite benign-looking on the surface, but something out there wants IN to your site, and apparently has a reason to check for these particular types of files.

Discussion

It is sad that Mr. 2012-11-13 doesn’t know how to collect data and then use it to save time and resources by eliminating redundancy and optimizing results. Nope. Instead you’ve got some greasy man-back crawling around with his $199 bargain scanner script and just letting it rip. Over and over and over and over, the same script hitting the same sites looking for the same files that didn’t exist last time, or the time before that or that or that ad nauseam. I could go on myself, but I think you get the picture.

On a different note, most the URLs being requested in this scan qualify initially as legitimate 404 errors. That is, there is every likelihood that I could have a join.php file somewhere or that someone could have linked to such a file, even though it doesn’t actually exist. And each scan seems to use a different set of IP addresses, so if let run only once per site would be a very stealth scan. But no, sadly that’s not the case. Someone’s hoping really hard that I decide to add some of those files to my site.

Identification

So who is this evil-scanning scumbag? Probably some sweet little white-haired old lady like my grandma who turned at once to a life of cybercrime after watching the 1,000th rerun of the Price is Right. As mentioned, the IPs associated with the requests suggest a clear pattern, but seem otherwise dynamic enough that blocking by IP is not gonna be worthwhile in this case.

The most recent user-agent to be reported with the scan is Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;), which to me is too similar to legit browsers to serve as a reliably detectable pattern. So to block this scanning moron we need something a little more consistent, like the URL-requests themselves. And they’re reliable too, even now bouncing off my newly placed mini firewall, which happens to work great with the 5G Blacklist.

Blacklist the fool

Alright, so I’ve had enough of this relentless scanner and it’s time to roll out the red carpet.. straight to the CURB. Here is the tasty slab of .htaccess goodness that works great with the 5G:

# mini firewall 2012-11-13
<IfModule mod_alias.c>
	RedirectMatch 403 /(\{\$itemURL\}|administrator|blogs/load/recent|default|register|signup|tools/quicklogin\.one|undefined|WHMCS|YaBB\.cgi|YaBB\.pl)/?$
	RedirectMatch 403 /(curltest|join|join_form|member/join|mobiquo|register|signup|tiki-register|ucp)\.php$
</IfModule>

Note that if registration is open on your site, run a test registration to verify that everything works. If not, please report with a comment so modifications can be made. Thanks.

So to implement this mini-firewall, just add that slice of code to your site’s root .htaccess file (or server config file) and say goodbye to this edition’s Blacklist Candidate and his relentless scanning. Thanks Mr. 2012-11-13, we couldn’t have done it without you!

About the Author

Jeff Starr = Creative thinker. Passionate about free and open Web.