full-disclosure - Removing ShKit Root Kit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3FE824CC.31455.23BE32C4@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Removing ShKit Root Kit

"Schmehl, Paul L" to Alexander Schreiber:

> > There is exactly one way to properly clean up a rooted box: 
> > backup the system (for later analysis and for keeping any 
> > data that might be needed), wipe the disks and reinstall from 
> > known clean install media, update the system to get all 
> > current security updates und properly secure the box.
> >
> This advice is common, and it's always mystified me.  ...

Me too...

> ...  Why would you want
> backups of the "data"?  If the box is compromised, you can't trust
> *anything* on it, can you?  How can you know for certain that "data"
> isn't a cleverly concealed backdoor?

...though for a slightly different reason.

> I can understand backing up the disk for offline analysis, ...

I can't.

These days drives are really cheap -- ludicrously cheap.  You'll get a 
fifty to several hundred percent drive size increase for the same 
outlay as the initial drive cost depending on how long it is since the 
box was first built (unless it was brand new or you are talking about 
truly monster arrays where pricing is somewhat less mobile).

If you _imagine_ that you might engage the labour/time/expertise 
expense of any kind of forensic activity, clone the drive or backup the 
data (for whatever your reasons, but I agree with Paul's comments about 
the sanity of trusting any data off the compromised box as a backup 
source for restoring a new live system), keep the original drive 
physically separated from any machine (except for any future needs to 
make further image copies, etc or to prove such a copy is a true 
likeness), install a new drive in the formerly compromised box, rebuild 
the system on the new drive, harden, etc, etc reconnect to the network.

This is overkill if you do not have true forensic requirements, but 
often you will not know that for sure until you are part way through 
the analysis (for example, it turns out there is evidence that the 
compromise was likely done by a competitor to steal something valuable 
that was then "covered up" to look like a typical skiddie web server 
defacement).

> ... but I would
> think you'd want to restore your data from known good copies, wouldn't
> you?  And if you don't have known good data backups, well, then consider
> it a lesson learned and do it right the next time.

Yep...

Regards,

Nick FitzGerald