I think I've been 0wn3d...

Hi all!

I'm pretty sure my linux box (RH7.1) has been compromised, and I'm writing this as I'm trying to pull down 1.1GB of data off of it before it gets smoked...

I logged on this weekend to check something or other, and noticed that someone was on the same time as me... 1st indication something was not right... Then my history was smoked, and my lastlogin info... D@mmit... Tried to run chkrootkit, and it would just hang at checking "aliens", and go no further... Nuther bad sign...

Then tonight I found a sh.zk.cgi in my cgi-bin while doing a:
find / -user root -perm -4000 -print
Don't know what the h*ll that is...
(Should I rm it, or leave it til I get my files off??? I don't want p!ss off whoever has as much control over my box as me... Doesn't that suck...)


Double d@mmit...

Okay, so now that I've told my sob story, and am preparing to have this box reloaded, what should I be looking for to find out what happened??? chkrootkit made it through all the file checks saying all the binaries were clean, and my logs appear clean (or maybe have been cleaned)... I know I'll not be able to hunt the guy who did this, but I sure would like to know where my vulnerablities are... Is there some other chrootkit type app that might run when chkrootkit wont???

I know, first time poster, tons of questions... Sorry... (But you guys know everything, right??? :) )

James...

best recommendation, yank whatever internet connection you have to that box. You can always retrieve the files via lan.

also, hopefully you used some sort of file checking application (such as tripwire) but chances are your data for that isnt updated... double check every file you decide to keep, burn the box down as quick as possible, and get on with life. You may look into some IDS systems with a more proactive approach in the future. but the fact is... sh*t happens eh.....

Thanks for the quick reply THEJRC!!!

If I could, I would pull the plug on it, but it is a dedicated box at a "major hosting" place, and when I called them RE: this, they said they would have their SAs look at it... Then when I called them back again, they were like "Didn't we just tell you that we'd have our SAs take a look at it? They should be in in the morning..."... I'm pretty sure that if I took it down myself, they'd react by rebooting it... The night crew isn't exactly on the ball...

Now I just noticed all my /bin files are now dated today... Great... ps, netstat, everything running cracked...

I guess I'm learning the hard way what preventative steps I _should_ have taken to reduce the chances of being in this position... Now I just have 5 bajillion PHP scripts to wade through looking for alterations...

Reminds me of when I got CIH virus a few years ago... Never really had need to be concerned about viruses... Your future actions are usually based upon what's happened in the past... I sure as hell am going to do everything I can to prevent this from happening again... There probably aren't too many people interested in intrusion prevention who didn't get into it by being cracked... Am I right??? Well, maybe not...

Lot to learn, lot to learn... TripWire=Good, FTP services=BAD... Much to go...

Thanks...

James...

pull the plug - you've found the evidence, now you need to analyze without interruption. look at time stamps for the entire system based on the ctime of the setuid cgi script. were the web logs tampered with? if not, then what is the relevance of the entries there (including timestamps for access to that cgi verses the responses from your find by date output)?

i wouldn't completely trust ps, ls, or netstat output. do a file hash comparison against a clean box with the same build and patch level (if available).

==========
edit...heh i was right on the rootkit...just a little late in the response.

also by all means do not delete the cgi.

What happens if I delete the CGI??? Other than they will be aware that I'm aware??? I googled the sh.zk.cgi and found nothing... Can't really tell what it is as it is a binary, and I have no desire to copy it to a clean box to see what it does... Maybe after I take it down, I'll copy it and take a look at it... Judging by the name, it provides a shell through a browser???

Thanks for your replies...


James...

I agree with the others. Get that machine off the net ASAP because it's a hazard to the rest of the Internet. You can make an image of the hard drive and study it later to find out what happened.

This won't help you with your current situation, but when you get your system reloaded you can make the system much more difficult to rootkit by using chattr to make your binaries like ps, netstat, ls, du, top, etc. immutable. Then you can remove the chattr command from the system by putting is on a floppy disk so an intruder can't reset the attributes.

Thanks for the tip on chattr... Any info to help prevent a recurrence is greatly appreciated...

This may be a stupid question, but if somebody had an exploit to gain root access to a box, could they copy chattr to the box and undo it??? Or will chattr-ing these files prevent the root access???

As you may be able to tell, my copy of "Counter Hack" is still in the mail... :) What timing, I gain an interest in security, and days later I'm pushed into the "accelerated program"...

Thanks problemchild!

P.S.: Does anyone know why not to delete the CGI???

Yes, a knowledgeable attacker can definitely replace the command, but the name of the game is to make it more trouble than it's worth. Most attackers are looking for easy targets and will move on if they hit something like that that's too much trouble.

But that's all for later. Right now you need to get the hard drive archived somehow for forensic analysis later. I think droby was saying not to delete the CGI because the timestamp on it will tell you roughly when your box was compromised and you can use that as a reference point for looking at timestamps on the rest of your system.

My advice: Pull the plug immediately and don't touch anything. Archive the drive exactly as it is right now so you can study it at your leisure later. Don't do anything that might alert the intruder that you're onto him, because he might decide to rm -rf / and delete any evidence on the drive. Then you can rebuild the box and get it back online quickly.

Still waiting for my host to pull the box to reload... I've called numerous times, and their attitude sucks... And they're only gonna charge me $175 to slap a new image on it... Grrr... I'm getting tempted to do the rm -rf / myself...

I tried to pull down the CGI, and NAV wouldn't let me, stating that it was infected with Linux.RST.A... SARC has no info on it though... Remote Shell Trojan???

So here's what I'm gonna do once I get reloaded... Please let me know if I'm missing something...

1. Disable Telnet
2. Disable FTP (will use sftp through ssh?)
3. Setup IPTABLES to block all ports but 22, 80, 443, 25, & 110 ???
4. Reinstall all IDs w/ new passwords
5. Reload all data & tables (checking PHPs for changes)
6. chattr my binaries

Should this be enough to keep kiddies out while I'm figuring out how to use Tripwire & LIDS???

Does mysql need to have a /bin/bash account?

Don't you like it when I cram 38 lame questions in 1 post?

Thanks everyone for your help...

James...

sorry for the delay...been away.

yes, i was saying not to delete it for two reasons both relating to maintaining the state of the system. 1) the timestamp as noted and 2) the contents of the file. seeing that you've already identified the contents if you are satisfied with knowing what it is instead of how it works then document the timestamp and delete...but if you find other changes to the system and wonder what part of the attack it was (pre-root, post-root, to-get-root) you'll be minus one element of evidence (there may be several features that can be traced back to this cgi).

your measures for restoration are fine...but they do they take into account how this attack occured? have you been able to locate the problem? without trustworthy logs, this will be difficult. if you could sandbox everything, set it back up exactly the way it was...then you could find out the next go around. if it's a new exploit, then it'll become more public and frequently used...if it's an old exploit, then i would focus on patching proceedures.