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

Message-ID: <15533237421C6E4296CC33A2090B224A54C92F@UTDEVS02.campus.ad.utdallas.edu>
From: pauls at utdallas.edu (Schmehl, Paul L)
Subject: Removing ShKit Root Kit

> -----Original Message-----
> From: full-disclosure-admin@...ts.netsys.com 
> [mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of 
> Brian Eckman
> Sent: Monday, December 22, 2003 4:24 PM
> To: Nathan Bates
> Cc: full-disclosure@...ts.netsys.com
> Subject: Re: [Full-Disclosure] Removing ShKit Root Kit
> 
> OK, so how does the attacker get the ADS to run? If you open 
> something.txt in notepad, it doesn't launch the ADS 
> 'trouble.exe' as an executable file. It's ignored.
> 
> Remember, the machine was formatted and reinstalled from clean media. 
> However that ADS was called is now long gone...

Until you restored it from backup.

Formatting and reinstalling the OS is only half the battle.  If you
restore the data that was on the compromised disk, you cannot possibly
guarantee its integrity unless you did checksums on every file prior to
the compromise, can you?

There's an assumption going on here - that it's not possible to
compromise "data" in ways that could endanger a machine.  Yet, some have
already suggested possibilities - ADS, accounts in databases and other
types of software that have their own account mechanisms, macros in
documents, etc., etc.  All an attacker needs is a way to begin the
process - something that the user would execute - like say an email
message?  Then the code can be hidden inside existing files and
reassembled by the stub that began the process.  Many "modern" viruses
begin with a small executable that then fetches the rest of the code,
"compiles" it and bam, you're compromised again.

Folks were asking these same questions before the first macro virus came
along, weren't they?  Didn't we, at one time, think it wasn't possible
to send a virus through email without using attachments that users had
to launch?  Yet all these have proven wrong.  Haven't we seen the use of
tftp and tunneled http to "get" those pieces needed to complete the
process of compromise?

As someone tasked with security in an organization, why should we make
assumptions about *anything* that existed on a compromised box?

Paul Schmehl (pauls@...allas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/~pauls/