My server has been hacked, how to remove SUCKIT?
Hi guys, my server has been hacked and installed SUCKIT rootkit.
When i tried to reboot my server using; shutdown -r now i got following errors.
The system is going down for reboot NOW!
RK_Init: idt=0xc033e000, sct=0xc033ec40, kmalloc()=0xc0139df0, gfp=0x3
Z_Init: Allocating kernel-code memory...Done, 12836 bytes, base=0xfffffff2
BD_Init: Starting backdoor daemon...Done, pid=31175
Then i searched little bit and found this is a SUCKIT issue. I found SUCKIT rootkit on /dev/sdhu0/tehdrakg directory. And here is the files on it:
[root@server1 tehdrakg]# ls -la
drwxr-xr-x 3 root root 4096 Apr 26 08:08 .
drwxr-xr-x 3 root root 4096 Jan 3 04:54 ..
-rw-r--r-- 1 root root 6705 Oct 25 2002 mig-logcleaner11.tar.gz
-rwxr-xr-x 1 root root 25273 Jan 3 05:07 m.tehdrakg
-rwxr-xr-x 1 root root 29764 Jan 3 04:54 sk
drwxr-xr-x 5 500 500 4096 Jan 3 04:54 skrh9
-rw--w--w- 1 root root 85711 May 13 05:14 .sniffer
-rwxr-xr-x 1 root root 1089 Feb 26 2001 udp.pl
it seems i had been hacked since 3th of January :( This scricpt kiddie knows his job i use chrootkit almost everyday but it always show nothing infected. Also I found /sbin/inittehdrakg and /sbin/init were created on 3th January.
Now what i want to know is how to remove this s*ckin' SUCKIT. Is there any chance to secure my system since now ? Without OS-Reload. And is there any chance to trace this script kiddie back?
Firstly, you need to isolate the box - get it iff the network, make sure it can't connect to the network or any other box.
Then, go here: http://www.linuxquestions.org/questi...threadid=45261 Unspawn has listed a huge number of security references for us all.
Sorry. Removing a rootkit is *NOT* the solution.
Then, go here:
(Damn, it takes too much time to write these replies :-[ )
From now on, regard this system as UNTRUSTED. DO NOT USE IT, AND DO NOT ALLOW OTHERS TO USE IT.
Here's what you do:
Precaution 0: read Steps for Recovering from a UNIX or NT System Compromise before doing anything else.
Precaution 1: For any operations on the server boot your distro's rescue cd, any cd-based distro (Trinux, Knoppix, Finnix, FIRE, PSK) or a one-floppy distro like tomsrtbt, LOAF. DO NOT BOOT the kernel from the harddisk or let it automatically mount the disks. If you need to mount the disks, mount them readonly.
1. Power down the server. This will render the system useless to the cracker and protect you from doing stuff on the box. Running any system diagnostics wouldn't make sense because you can't trust your system to not lie to you. Forget about making backups, forget about saving files, just drop it.
Notify local and remote admins and users about the compromise. : if this box is used to access remote boxen, other boxen on the network, etc, etc alert network admins. Also alert users of the box their authentication is void and ask them to change any auth they share with other boxen. Alerting is best done from a box that doesn't reside on the same subnet as the compromised one. Initiate checking other boxen on your network. Inform your ISP if you want to.
2. This step depends on what you want to do:
2a. If you want to spend time trying to find out what exactly happened, prepare another box on the network, else skip to 3b. This means combing over that box and make sure it is SAFE to use. If unsure it's your choice to either not use the box, or use the 3 R's: repartition, reformat and re-install from scratch. Make sure the box has enough diskspace (minimally 2x the disks to duplicate). Make copies using "dd" over the network or physically mount the disk on the other box. For dd'ing out you don't need to mount the partitions, just "dd if=/dev/<partitionname> of=/somedir/somefile_<partitionname>" and don't forget the swapfile. What does this yield? Absolutely nothing. Now you've got a copy of the disks you can perform basic forensics on them and try to work out what happened. I'd be glad to help you, but remember this is tedious and time consuming work, and the result is not guaranteed.
2b. OK. You decided not to "play" with forensics. Copy the /etc and /var dir off the server. These include most system config files and logfiles. Comes in handy if you want to see if you can get to know something w/o doing full-fledged forensics.
Precaution 2: read
Starting from Scratch: Formatting and Reinstalling after a Security Incident first.
3. Make sure you copy out any config files you forgot under 3b. DO NOT COPY BINARY DATA. Copy only verifiable, human readable data out. Exceptions are /var files like utmp, wtmp, lastlog and any other accounting files. Grab all updates from a local ftp mirror. Now use the 3 R's: Repartition, reformat and reinstall from scratch. Install only what you need NOW. Finish by applying the updates. Make sure you render any backups inaccessable and change all users passwords.
Don't connect the box back to the network, but first head over to the Linux - Security forum and read the "FAQ: Security references" thread, especially post 1. At least read these:
UNIX Security Checklist v2.0: http://www.cert.org/tech_tips/unix_s...cklist2.0.html
SANS, The Twenty Most Critical Internet Security Vulnerabilities: http://www.sans.org/top20/
Linux Administrator's Security Guide (LASG): http://www.seifried.org/lasg/
Securing Optimizing Linux RH Edition (older): http://tldp.org/LDP/solrhe/Securing-...-Edition-v1.3/
Intruder Detection Checklist (CERT): http://www.cert.org/tech_tips/intrud...checklist.html
Intrusion Detection Primer: http://www.linuxsecurity.com/feature...e_story-8.html
Add checking any distro specific stuff like mailinglists and hardening.
...and finally to answer your questions:
This scricpt kiddie knows his job i use chrootkit almost everyday but it always show nothing infected.
First of all you shouldn't trust just one tool. Second, SuckIT file hiding and skdet checks where added recently to a tool similar to Chkrootkit: Rootkit Hunter. Third point I'd like to make is that tools in that category suffer from using default locations and default binary names for checks. Once you change your location or binary name you're safe from any "find" ops, unless someone runs "strings" for identification or uses specific (skdet, kern_check, ip) or more tools to find anomalies. That's why you should install a filesystem integrity checker (Aide, Samhain, tripwire) once the OS is installed.
Now what i want to know is how to remove this s*ckin' SUCKIT.
SuckIT installs default built binary called "sk" as /sbin/init. SuckIT (if unmodified) will uninstall itself when you call the "sk" binary with argument "u". So "/sbin/init u" should unload SuckIT. This by no means means you're in the safe zone.
Is there any chance to secure my system since now ? Without OS-Reload.
In short, no. One would be insane to suggest it.
A slightly longer explanation: Yes, rebuild it. You have no idea what the cracker knows about your system, what it was used for, what backdoors are in place and what service she used to get in. Thinking you can get your box up to the point where it's more or less secure without rebuilding it from scratch is a fallacy.
And is there any chance to trace this script kiddie back?
In short, since the box has been found compromised for that long a period, chances are low.
A slightly longer explanation: when an intruder enters the system she will introduce methods to stay as much invisible as possible for as long as she can manage it. Removal or hiding of suspect files and logcleaning are the first things. Undelete could yield results (ls_hidden, an_check, mc VFS undelete, TCT), be partially undone, but only when it was discovered real soon after, and provided the server doesn't do much writes to the places where unlinked data lives.
// Out of sheer selfinterest, if you could secure me a copy of the contents of /dev/sdhu0/tehdrakg and whatever files changed on the system (no system auth stuff) and make it available for download I'd be happy. if you do, please *email* the download location.
Thanks unspawn. I didn't have any important data on that server, to avoid OS-Reload fee I changed my ISP :D I'm more serious about system security since my last box compromised. I'm using fedora core 1 and grsecurity patched kernel which is 2.4.26 and i followed steps you suggested. I also sent you an email that contains files link of that atacker left behind. Thank you very much.
Thanks. sk.* contained a modified SuckIT rootkit archive for RedHat 9, the other one was a login record logcleaner. Shame you didn't ship the (/dev/sdhu0/) tehdrakg stuff.
Great read, as spectators is useful to know about this kinda stuff if and when it happens to us.
Or have I missed something obvious :/?
One question, why do you use 'she' in regards to the intruder? Any reason in particular or are you suggesting that you have absolutely no idea who the intruder is so the gender is irrelevant?
In essence gender is irrelevant because you'll look at someone's skills and not his/her gender and also because the amount of crackers (I'm not saying hackers, OK) of the opposite sex is thought to be way low. Calling an intruder "she" is a somewhat default in security circles, and I just used it w/o finding out what it really stands for (which is bad ofcourse).
Okay, cheers for explaining that mate :)
|All times are GMT -5. The time now is 05:49 AM.|