Damn Script Kiddies, Get Off My Lawn!

Jun 13 10

Damn Script Kiddies, Get Off My Lawn!

Paul Weinstein

This should be a post about how entertaining the Chicago edition of w00tstockwas1 or about Steve Jobs’ WWDC Keynote2 or about the Blackhawks winning the Stanley Cup3 or any number of other things. Instead this post it about cleaning up after some script kiddie who decided to try to use a server that does not belong to them for their own personal use.


See, on Monday last, I discovered, after an automated notice of high computing load, a process identifying itself as “/usr/sbin/apache/log” which had been running for some 30+ hours. Obviously, no Apache log rotation should take that long. Moreover, the log rotation program commonly found with the Apache Web Server is known as rotatelog. A quick directory listing confirmed that no such program or directory existed at “/usr/sbin/apache/log”

A Google search for that path resulted in a number of pages warning of a possible system compromise and suggested a review of files in the “/var/tmp” and “/tmp” directories for anything weird.

Alas, anything weird is a bit vague and considering that both temporary directories are common placeholders for random files of any number of system users or programs it took me a few passes to realize that in this case that “anything weird” would be any thing executable since any proper executable would reside elsewhere on a Unix-based filesystem.

An extended listing of contents resulted in the the identification of the culprit, a Perl script called, pxconfig residing in the root tmp directory.

Luckily no evidence indicated a greater incursion, such as a rootkit being installed, thus disabling the script was a simple matter of using root’s superuser status to kill the process and remove the privileges of script file from executing.

Another Google search, using some of the script’s code, resulted in the discovery of an analysis of a similar Perlbot, the main difference being that the script I had discovered looked to have been modified with the sole purpose of working in coordination with other compromised systems for overloading a server with resource requests (DDoS) and seemed to contain no code to propagate itself.

So after disabling the offending script, I set about trying to discover how it managed to get itself installed in the first place. This blog posting suggested a possible point of entry and indeed after trying a couple of different search patterns on the Apache access logs I located the point of entry:

access_log.5.gz:80.37.xxx.xx – –
[01/Jun/2009:00:01:54 -0500] “GET
HTTP/1.1” 200 434 “-” “Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.1;)”

Notice in the GET request a GIF file being uploaded and a series of shell commands. Well the GIF file is no doubt corrupt, designed to take advantage of any number of known security vulnerabilities with the GD library resulting in a buffer overflow that in turn allows the arbitrary execution of the commands. Those commands change access to the “/tmp” directory, use wget to download a perl file and then execute said perl file. That file no doubt downloads yet another script name pxconfig, executes that second script and removes itself.

Moral of the story? Keep the system up-to-date, restrict all points where files can be uploaded, keep a close eye on what’s running and Google is your friend.

Damn kids these days!

1 Quick Review: Very entertaining, would have liked a chance to get Bill Amend‘s autograph on a FoxTrot Collection.

2 Yes, I still plan on upgrading my iPhone from a “3G” to the new “4”, no I’m not surprised Apple has renamed their mobile OS.

3 Time to retake my picture with The Cup.