Interesting...
I got this message from SANS lat night around 6:00 PM....
As they mention, data streams in NTFS have been around awhile. However, only now are the possible consequences of data stream viruses coming out...
---------------
-----Original Message-----
From: The SANS Institute [mailto:sans@sans.org]
Sent: September 5, 2000 5:30 PM
To: <<<name and id blocked out>>>
Subject: SANS Flash Alert - Virus scanner inadequacies with NTFS
To: <<<name and id blocked out>>>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Advisory: Virus scanner inadequacies with NTFS
Released By: Dartmouth's Institute for Security Technology
Studies(ISTS)
Contact Info: Chris Brenton <cbrenton@ists.dartmouth.edu>
Date: 09/01/00
Systems effected: Windows NT and 2000 running NTFS
Products tested: Virus scanners from the top three major vendors
Executive Summary
- -----------------
While the existence of data streams within the NT file system (NTFS)
has been known for many years (Microsoft has released quite a bit of
info on alternate streams), virus vendors have not taken steps to
adequately check this area of the file system. This deficiency can be
leveraged in order to hide malicious code or even cause the virus
scanner itself to destroy critical system files.
Current fixes
- -------------
No known fixes at this time. This advisory was released to the vendors
of the three tested products over three months ago. To date, no
corrective action has been performed.
Current Workarounds
- -------------------
Possible workarounds for protecting against this problem are included
at the end of this advisory.
Background Information
- ----------------------
The data streams portion of NTFS is a sub file system that allows
additional data to be linked with a particular file. Note that FAT does
not support data streams. The easiest way to understand data streams is
by working through a few examples.
On a Windows system utilizing an NTFS file system, create a test
directory in which all of the following example files can be created.
Now, let's get started by creating a simple text file:
echo "this is the main file" > file1.txt
The above command will create a text file named file1.txt and place the
text string 'this is the main file' within the file. You can verify this
has been successful by running any of the following commands:
type file1.txt
edit file1.txt
notepad file1.txt
In all cases you should be able to verify that the file was created and
that it contains the listed text string. Running the dir command should
report that the file is using approximately 26 bytes. All of the above
works because you have saved the file to the named stream portion of
the file system (the portion of NTFS you commonly use to read and write
files). Now it's time to create your first alternate data stream. Run
the following command at the command prompt:
echo "this is the stream" > file1.txt:stream1.txt
The command should complete without error. The ?:? notation is how you
specify an associated stream file.
Now try running each of the following commands:
type file1.txt:stream1.txt
edit file1.txt:stream1.txt
notepad file1.txt:stream1.txt
With the exception of Notepad, you should find that all of the above
commands exit with some form of an error. This is because many of the
stock Windows tools are incapable of correctly dealing with associated
data streams. At the time of this writing Microsoft has not yet updated
many of its own tools to be able to deal with information stored in the
data streams portion of the NTFS file system. Needless to say this can
make finding files stored as alternate data streams difficult at best.
Now let's try associating a large stream with file1.txt to see if dir is
capable
of reporting the difference in file size:
dir c:\winnt\* > file1.txt:stream2.txt
The command should execute successfully. While we have just created an
alternate data stream file of approximately 6,500 bytes, dir will
continue to report that file1.txt is only 26 bytes in size. If we check
the file through Windows Explorer we will experience the same problem
of incorrect file size reporting.
To confirm that you did in fact add approximately 6,500 bytes of
information, execute the following command:
notepad file1.txt:stream2.txt
You should see a text file that contains a directory listing of the
WinNT directory. Now try selecting Fileà Save As from the Notepad main
menu. You will receive a command dialog error message. This is because
even though Notepad is capable of opening and creating stream files, it
is not capable of browsing this area of the NTFS file system. Again we
are bumping our heads against limitations in the existing NT tools.
It's interesting to note that you can also create stream files that do not
have
an association with a file in the main portion of the file system. Try the
following command:
echo "this is a stream file" > :file3.txt
This will create a stream that is completely invisible using dir or
Explorer. Now it's time to try cleaning up some of our test data stream
files. Try executing the following commands:
del file1.txt:stream2.txt
del :stream3.txt
In both cases the delete command will fail. This is because del is yet
another utility that has not been updated to handle streams. The only
way to delete the attached stream is to delete the main file. This will
automatically remove any stream associations. In the case of
:stream3.txt, you must delete the entire directory in order to remove
it from the system.
One of the biggest problems with streams is that it is difficult to
identify when they exist. A programmer can use the API function
CreateFile() to see if an alternate data stream is present, but this
assumes that the programmer knows the name of the data stream ahead of
time. For example, in the exercise above we were able to open data
stream files because we specifically gave Notepad the name of the file.
You may remember that when we did a 'Save As' which required the
ability to browse the data stream portion of the file system the command
failed. CreateFile() only works when you give it specific information.
This raises an interesting question, 'Is there a way to identify the
existence of a data stream when you do not know what file names to look
for?'. In the course of our research, the only API function we have
found that is capable of blindly finding data streams is BackupRead().
Unfortunately, very few tools or utilities use this function, thus they
are incapable of working with data streams when the name of the file is
not specifically known.
The existence of Streams within the NTFS file system is nothing new.
Information on Streams and its potential abuse was released to Bugtraq
on 3/20/98. Reference URL is:
securityfocus.com
sg=Pine.SUN.3.94.980320114349.19659S-100000@dfw.dfw.net
Microsoft also has some good information on streams and how to work with
them located at the following URL's:
support.microsoft.com
microsoft.com
msdn.microsoft.com
For additional reading on data streams, refer to page 164 of 'Hacking
Exposed' by Stuart McClure, Joel Scambray and George Kurtz.
Advisory Details
- ----------------
We tested the latest version of virus scanners from the three major
virus scanning vendors. In all cases we found that the scanners were
incapable of identifying viruses stored within an alternate data stream.
For example if you create the file MyResume.doc:ILOVEYOU.vbs and store
the contents of the I Love You virus within the alternate data stream
file, none of the tested virus scanner where capable of finding the
virus during a complete disk scan, even when 'check all files' was
selected. This means that an evil programmer can use the alternate data
streams portion of the file system in order to hide malicious code from
all major virus scanning products.
There are a couple of caveats here. First, if the memory resident virus
scanner is set to check all files, the virus code must be new and have
an unknown signature. When the contents of the named stream is read into
memory, the alternate data stream is read into memory as well. At this
point in the copy process the memory resident virus scanner is capable
of detecting viruses with a known signature. So in order to sneak virus
code past a memory resident scanner set to check all files, the virus
signature must be unknown to the scanner.
It should be noted however that many memory resident virus scanners are
not set to check all files. In order to increase system performance,
the memory resident virus scanner will only check files where the named
stream has a specific extension (such as .com, .exe, .vbs, etc.). When
a scanner is configured in this manner, a malicious programmer can sneak
their virus code onto the system by associating the alternate data
stream with a named stream that is not normally checked. For example,
most scanners do not include .ini files in their list of named data
stream files that should be checked. A programmer could associate legacy
virus code with one of these unchecked file types and have it be
successfully written to disk. As mentioned earlier in this document,
the virus would also be missed during any subsequent disk scans as the
alternate data stream portion of the file system does not get checked.
So the vulnerability lies with being infected by new viruses or viruses
that are stored in an alternate data stream of a file that is not
normally checked by the memory resident scanner.
So why have virus scan vendors not addressed data streams? The reason
given to us when reporting this problem was 'Data streams are inert.
You can not directly execute data stream files'. This statement is in
fact correct. If I open a command prompt and type the command
resume.doc:NastyEvilVirus.com the attached virus will not be executed.
There are however ways around this problem. First, it is trivial to
deploy the virus as two separate parts. The bulk of the virus code could
be stored as an alternate data stream while the 'executor' is a minimal
amount of code that simply calls and processes the commands within the
alternate data stream.
Remember that virus scanners are signature based. This means that a
virus scanner will try to identify a unique pattern within the virus
code in order to distinguish the virus from other files. If the virus
scanner is incapable of checking information within the alternate data
streams portion of the file system, the only thing the virus scanner
can lock on to is the executor portion of the virus that is stored as
a named stream file. If the executor does little more than make a
ReadFile() call to the alternate stream file, there is insufficient code
available to create a proper signature without generating multiple false
positives.
So while the data stream portion of the file system is in fact inert,
a savvy programmer can still utilize this area to stealth their
executable virus code.
There is also a more insidious method of leveraging the inadequacies of
modern day virus scanners in order to cause harm to a system. Let's
assume a malevolent attacker writes a new virus program capable of
performing some destructive task. Rather than immediately releasing it,
they wrap it in a worm or some other delivery code. Initially, the worm
simply writes the virus code to the NTFS file system as an alternate
data stream of critical files (say cmd.exe, Poledit.exe, Regedt32.exe,
or even worse).
After a few weeks, the attacker releases the virus code into the wild
as a regular virus that gets written to the named stream portion of the
file system. Virus vendors respond by generating a signature file for
the code and users in turn download this signature file and begin using
it.
The first time one of the files with an infected data stream is
executed, the memory resident virus scanner will detect the malicious
code pattern when it is loaded into memory along with the named stream
file. Unfortunately, since the scanner does not understand alternate
data streams, the scanner assumes the code is actually part of the named
data file. What happens next depends on how the user has their scanner
configured. If the 'delete infected files' option is selected, the
critical system files will be purged from the system. If 'move infected
files' is selected, the critical system files would be moved from their
default location and the system may be left in an inoperable state. If
'prompt for user intervention' is selected, the end user must be savvy
enough to halt execution and attempt a manual cleaning (assuming they
know for a fact that the virus code is located in an alternate data
stream).
So even though virus code located in an alternate data stream would be
harmless without some form of executor, the virus scanner can be turned
against the system it is supposed to be protecting, potentially leaving
the system in an unusable state.
Note that this is a virus scanner problem, not a Microsoft problem as
alternate data streams have been very well documented for quite some
time.
What Should Virus Scanner Vendors Do
- ------------------------------------
Include support for alternate data streams in all products that claim
to support Windows NT or Windows 2000. Implement the BackupRead() API
function so that streams are checked during full disk scans.
What Can End Users Do Today
- -----------------------------
1.Start performing regular checks of your NTFS file system for alternate
data streams. Run the check as an AT process so that the file system is
verified on a regular basis. NTOBJECTives has an excellent tool called
Sfind.exe which is capable of finding alternate data streams. The tool
is included as part of their free Forensic ToolKit. Reference URL is:
ntobjectives.com
2.Follow step #1 to baseline your existing NTFS partitions. If during
later checks you find a new alternate data stream, be suspicious. During
our testing we found that stock installations of Windows NT and Windows
2000 did not create any data stream files. It is possible however that
some third part vendors may use them. Streams are used to save fork file
information when a Macintosh volume is created so you may see alternate
data streams if your NT system stores Macintosh files in their native
format.
3.If you find a suspicious data stream and want to clean it from the
system, first perform a backup of the named stream file as well as all
associated data streams. Verify that your backup software did in fact
save the alternate stream file as well (some backup software is
incapable of processing data streams but that's a topic for another
advisory). If the alternate data stream was not backed up, you can map
a drive to a remote NTFS partition and copy the file to the remote
system. Stream files are maintained when you copy from one NTFS
partition to another. To clean the alternate data stream from the named
file, simply map a drive to a non-NTFS partition (for example NT using
FAT, Windows 98 or Linux running SAMBA). You can then move the file to
the remote system and then move it back. When the file gets written to
disk on the remote system the alternate data stream files will not be
saved. Note that this also removes any specific file permissions you
may have set so make sure you document the settings using FileStat (also
part of the Forensic ToolKit) or a similar utility prior to moving the
file.
4.Call your virus scanner vendor and request that they add proper
support for data streams.
Acknowledgments
- ---------------
Special thanks goes out to Alan Paller, Stephen Northcutt and the whole
SANS crew for providing a conduit for releasing this type of
information.
Thanks as well to JD Glaser of NTOBJECTives and Foundstone for creating
some of the best NT tools available and providing support during this
research. Thanks as well to Eric Schultze of Microsoft for reviewing
this advisory and providing additional tips.
Thanks to Rain Forest Puppy (RFP) and Marcus Ranum for defining a
conscience for the white hat community.
Finally, thanks to the National Institute of Justice (NIJ) for funding
this research.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (BSD/OS)
Comment: For info see gnupg.org
iD8DBQE5tT2o+LUG5KFpTkYRAhYMAJ9C6p/YV5Un9Rf01OPjjwrEeKG69QCeI0lp
Nu1iqtAjYdIydDsr+pfe+bo=
=IdRE
-----END PGP SIGNATURE----- |
