Compromised Slackware 9.1

rsleventhal · 08-01-2007, 08:52 AM

Hi folks,

I found (using rkhunter) that the SuckIT rootkit had been applied to one of my older machines, running Slackware 9.1. I've removed all traces that I can find, but it seems that:

/sbin/init
/sbin/file

are not from the original distro. Hashes don't match and I'm thinking that they need to be restored to their original install state.

Does anyone know where I can obtain these?

Thanks in advance for any/all comments.

Regards,
~Ray

achu · 08-01-2007, 10:25 AM

Look at http://packages.slackware.it/browse.....1/slackware/a . Init program should be in sysvinit-2.84-i486-36.tgz package. But /sbin/file is more interesting - you can find File program in bin-8.5.0-i386-1.tgz package, but it is commonly installed in /usr/bin directory, not in /sbin ...

rsleventhal · 08-01-2007, 10:29 AM

achu,

Thank you! Thank you!

This is exactly what I was hoping to find.

Best regards,
~Ray

rsleventhal · 08-01-2007, 10:40 AM

Quote:

Originally Posted by achu

Look at http://packages.slackware.it/browse.....1/slackware/a . Init program should be in sysvinit-2.84-i486-36.tgz package. But /sbin/file is more interesting - you can find File program in bin-8.5.0-i386-1.tgz package, but it is commonly installed in /usr/bin directory, not in /sbin ...

I'm making the (hopefully right) assumption that in the sysvinit-2.84.i486.tgz package, I'll be using the file called init.new as init on my system. Does that sound right?

~R

rsleventhal · 08-01-2007, 10:43 AM

Quote:

Originally Posted by achu

<snipped>But /sbin/file is more interesting - you can find File program in bin-8.5.0-i386-1.tgz package, but it is commonly installed in /usr/bin directory, not in /sbin ...

my bad...'file' was in /usr/bin/

~R

achu · 08-01-2007, 10:49 AM

Yes, installation script will move /sbin/init.new to /sbin/init.

unSpawn · 08-01-2007, 11:14 AM

Achu, that's some seriously ill advice. If you never handled incidents like this please let somebody who does know handle it. If both of you would have searched this forum you would have found more than enough threads handling incidents. None of them talk about overwriting binaries with sane copies.

There's simple procedures for determining and recovering from a compromise. Thoroughly verifying the integrity of your system should be your first task, followed by finding out how the box got compromised. Restoring packages before doing any of that can and will destroy "evidence". Read these, act on them and then ask:
- Intruder Detection Checklist (CERT): http://www.cert.org/tech_tips/intrud...checklist.html
- Steps for Recovering from a UNIX or NT System Compromise (CERT): http://www.cert.org/tech_tips/root_compromise.html

rsleventhal · 08-01-2007, 11:23 AM

Thank you for the links. I have not overwritten anything and won't until I've a full understanding of what's happened. I do appreciate all the input!

Regards,
~Ray