Full Disclosure mailing list archives
RE: Removing ShKit Root Kit
From: "Chris Carlson" <chris () compucounts com>
Date: Tue, 23 Dec 2003 10:25:23 -0500
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 () lists netsys com [mailto:full-disclosure-admin () lists netsys com] On Behalf Of Jason Sent: Monday, December 22, 2003 22:24 To: Schmehl, Paul L Cc: full-disclosure () lists 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 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- Re: Removing ShKit Root Kit, (continued)
- Re: Removing ShKit Root Kit Ron DuFresne (Dec 22)
- Re: Removing ShKit Root Kit Paul J. Morris (Dec 22)
- RE: Removing ShKit Root Kit Nick FitzGerald (Dec 22)
- Re: Removing ShKit Root Kit Alexander Schreiber (Dec 22)
- RE: Removing ShKit Root Kit Schmehl, Paul L (Dec 22)
- Re: Removing ShKit Root Kit Jason (Dec 22)
- Re: Removing ShKit Root Kit Cael Abal (Dec 23)
- Re: Removing ShKit Root Kit Brian Eckman (Dec 23)
- Re: Removing ShKit Root Kit Jason (Dec 22)
- RE: Removing ShKit Root Kit John . Airey (Dec 23)
- Re: Removing ShKit Root Kit Gregory A. Gilliss (Dec 23)
- RE: Removing ShKit Root Kit Chris Carlson (Dec 23)
- Re: Removing ShKit Root Kit Jason (Dec 23)