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] [day] [month] [year] [list]

From: ggilliss at netpublishing.com (Gregory A. Gilliss)
Subject: Removing ShKit Root Kit

Sorry, I really hoped that this thread would die but ...

This is an excellent solution to the "restore" problem, as is Jumpstart
scripts and packages for Slowaris and (perhaps - I haven't tried using it)
portupgrade and some scripts for *BSD). Separating the "system" and the
"data" definitely contributes to making a faster recover. However the data
remains tainted, so the issue of trusting the backup does not go away.

Suppose you use ssh. Suppose you plow your box and reinstall as described.
Do your host keys get replaced. If you formatted the disk they do, but 
if you restore them from your data backups are they trusted? Yes, yes,
I know no one would restore host keys from backups, but it make s the point.

Data can be tainted. My earlier point stands also - if you have custom
scripts or even non-executable files, and you restore from your old cron-
tab entries, there might be some non-executable that gets changed to 
executable and bammo! you're screwed. So saying that backing up the data 
separately from the system is not a panacea because that data may be
compromised. In fact it's probably *more* dangerous because after hours of
restoring a production system under pressure there is a serious temptation 
to grab that saved data and throw it back up on the new 'clean' server 
to get things running as fast as possible.

While I agree that separating the system and the data for restore purposes
is a good solid plan, I do not agree that such a plan obviates the need to
do forensics on the untrusted data to ensure that you do not repeat the
hack on the restored machine.

G

On or about 2003.12.23 15:27:00 +0000, John.Airey@...b.org.uk (John.Airey@...b.org.uk) said:

> An even better solution is to have a method of installing a machine where
> the latest program packages can be installed and the configuration can be
> repeated. Red Hat comes with this ability, by combining the "genhdlist"
> program (comes with the anaconda-runtime package) with a script run via NFS.
> Once you have that, you only need to backup the actual data, not the
> configuration (so the issue of trusting the backup goes away).

-- 
Gregory A. Gilliss, CISSP                              E-mail: greg@...liss.com
Computer Security                             WWW: http://www.gilliss.com/greg/
PGP Key fingerprint 2F 0B 70 AE 5F 8E 71 7A 2D 86 52 BA B7 83 D9 B4 14 0E 8C A3