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: <A16F9DC0E61ACF43AF708AC2D3BE2B063AEE@gracey.internal.compucounts.com>
From: chris at compucounts.com (Chris Carlson)
Subject: Removing ShKit Root Kit

> IIRC the host file can be deleted and even overwritten 
> without having an impact on the ADS. 

Actually, deleting the host file deletes all associated data streams.
If a file of the same name is created on the system, the ADS' will not
remain:

\> echo this is a test > notepad.txt
\> echo testing again > notepad.txt:ads
\> more < notepad.txt
this is a test
\> more < notepad.txt:ads
testing again
\> del notepad.txt
\> more < notepad.txt:ads
The system cannot find the file specified.
\> touch notepad.txt
\> more < notepad.txt:ads
The system cannot find the file specified.

Just my two cents; carry on.

- Chris

-----Original Message-----
From: full-disclosure-admin@...ts.netsys.com
[mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of Jason
Sent: Monday, December 22, 2003 22:24
To: Schmehl, Paul L
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.

The easy answer is start a command prompt and type

start something.txt:trouble.exe

it does not even have to be tagged .exe or .com or whatever. As an
exercise, copy notepad.exe to calc.exe:notepad and then launch a command
prompt and type "start calc.exe:notepad" You should be looking at
notepad. I no longer have a handy M$ system to verify the steps on so if
it does not work play with it for a few minutes.

a shortcut, email, service... are all entry points for this and you
still have that rotten code on the system.

even removing the troubled txt file may not solve the problem. IIRC the
host file can be deleted and even overwritten without having an impact
on the ADS.

so you pull out the trusty CD and reinstall over the old image and you
could be in the same position.

>>
>>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?
> 

Depending on the nature of the system it may be critical to evaluate all
transactions real or otherwise since the known good backup, this would
not be possible without the backup of the data. If it requires a hand
audit of each transaction compared to a known good image then the only
way is with this data.

A larger problem lies in identifying the last known good backup, how
exactly are you going to know this without at least a rudimentary manual
audit of the system as it is now and as it was for the backups until the
differences are found and source identified?

what about repeated compromise? competing rootkits? How do you identify
the critical point of change? Even supposedly known good backups can be
considered suspect in this situation and this cannot be resolved without
doing the analysis.

> 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.
> 

or a simple nibble over text channels in an existing unpatched custom
application that only allows us to write one byte at a time to an
arbitrary file and then execute it.

just in case someone wants to say that text only executables can not be
made and used, several tools for this can be found online. Bookmarks
from an old system provides these direct links to some.

http://groups.google.com/groups?selm=3nolav%248ir%40gagme.wwa.com&output
=gplain
http://www.simtel.net/product.php?url_fb_product_page=43214
http://www.simtel.net/product.php?url_fb_product_page=43215

A little bit later after doing a steno decrypt of the content hidden in
the images on that web server and the compromise is back on a fully
patched fresh system with known good/safe restored data. OMG WTF?

> 
> As someone tasked with security in an organization, why should we make

> assumptions about *anything* that existed on a compromised box?
> 

We finally agree on something Paul. I knew the day would come :-)


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ