Re: Cheyenne Inoculan vulnerability on NT

From: Adam D. McKenna (adamat_private)
Date: Thu Jun 11 1998 - 15:38:19 PDT

  • Next message: Craig H. Rowland: "Silly patch to report version.bind requests"

    This is very interesting.  I have also noticed that Cheyenne ArcServe
    creates two shares, ArcServe$ (the ArcServe system directory) and CheyAlert$
    (if you install the Alert Manager) that also have Full Control permissions
    by default for the Everyone group.
    
    These directories do not serve as an auto-update, but a malicious user could
    easily replace any of the program files (asmgr.exe, asadmin.exe,
    arcbatch.exe, etc.) in these directories with whatever he or she desires,
    which would be run as soon someone ran the program (the links in the
    ArcServe user's Start Menu point to the same files.)
    
    This is in ArcServe 6.0 build 328.  (Without any service packs).  It looks
    like installing ArcServe Service Pack 3 fixes the permissions, but if you
    are running a new install (like I was... :)  then you are vulnerable..
    
    --Adam
    ---
    Adam D. McKenna
    Senior LAN Analyst
    IDT, Inc.
    adamat_private
    adamat_private
    
    -----Original Message-----
    From: p__boyerat_private <p__boyerat_private>
    To: BUGTRAQat_private <BUGTRAQat_private>
    Date: Thursday, June 11, 1998 6:15 PM
    Subject: Cheyenne Inoculan vulnerability on NT
    
    
    It is possible to run arbitrary code on any Intel machine running Cheyenne
    Inoculan version 4.0 for Windows NT(any version of NT) prior to SP2.
    Same kind of vulnerabilities might exist with other anti-virus product
    providing an auto-update mechanism. I have not the time needed to fully
    explore this issue. Feel free to contribute.
    
    Summary of the problem:
    * Cheyenne Inoculan version 4.0 prior to SP2 for Windows NT creates a shared
    directory called "CHEYUPD$" in which "EVERYONE" has "FULL CONTROL" access.
    * When Inoculan starts, it checks if a new versions of Inoculan has been
    written in that directory and, if so, replace itself with the new version.
    * It is trivial to create a fake "new version" and let Inoculan install this
    fake on all machines running inoculan
    
    To check if you are vulnerable :
    if you have the resource kit installed, run
    SRVCHECK.EXE \\<YourMachine>
    else run srvmgr.exe from a NT server on the same domain, select
    <YourMachine> and select "Computer|Shared Directories".
    
    If there is a shared directory called "CHEYUPD$" that allows "FULL CONTROL"
    to the "EVERYONE" group, this is bad news :(
    
    The solution:
    go to http://www.cheyenne.com/CheyTech/Download/patches/techptch.html and
    install their latest patch
      Nota: it took more than 3 weeks after I first reported the problem to
    cheyenne (a Computer Associates Company) before they provided us with such a
    patch. I had to wait the patch availability before to post here... Client
    rules ;)
    
    More details :
    
    Inoculan runs as a service, called "Cheyenne InocuLAN Anti-Virus Server".
    When it starts, it replaces any shared directory with the same name and
    shares "CHEYUPD$" with full control for the everyone group.
    
    When the service starts, it does an update check in this directory (usually
    "C:\Inoculan\Update\" ) using the files
    "<NtBox>\CHEYUPD$\English\NtIntel\Ready\filelist.txt" and
    [idem]...\avh32dll.dll
    
    simply "touching" or modifying  the file "filelist.txt" for it looks younger
    than real causes the update. Th update causes the service to stop, the
    avh32dll.dll DLL to replace the existing one (usually in
    c:\inoculan\avh32dll.dll) and then starts the service again.
    When the service starts, it loads the DLL into memory, and THEN does a lot
    of stuff (including checking if it is a valid DLL, I presume).
    
    The problem is you can write a DLL that execute arbitrary code at the time
    it is loaded in memory, at the precise time when DllMain is called by the
    image loader, before any other function have a chance to be called...
    
    
    Exemple :
    
    inoctroj.cpp:
    -------Cut here -----------
    #include "stdio.h"
    
    long  __stdcall DllMain (long, unsigned long, void*)
    {
    // Any code can goes here. This is an exemple
    // What it does is simply create a file on C: drive root directory
    // and writing "hello world !" inside of it
            FILE * demo;
    
    // create a file
        demo = fopen ( "C:\\I_can_write_a_file.txt", "w");
    
    // write to the file
        char * buf = "hello world !      ";
            fwrite (        buf,1, 15, demo);
            fclose ( demo );
    
    // This aborts the DLL loading. Anyway, we're done at that time ;))
            return 0;
    }
    
    -------Cut here -----------
    
    compile and link to make the target avh32dll.dll
    
    write it to <NtBox>\CHEYUPD$\English\NtIntel\Ready\
    touch <NtBox>\CHEYUPD$\English\NtIntel\Ready\filelist.txt in the same
    directory for it is more recent than initially.
    
    Stop the "Cheyenne InocuLAN Anti-Virus Server" on the <NtBox> machine and
    start it again (alternatively shutdown and restart the machine).
    Here you are : there is a file "I_can_write_a_file.txt" in "C:\" on <NtBox>.
    No good :(
    
    An interesting point is that Inoculan uses "domains". In one domain, a
    single server forwards the updates to all machines participating in that
    "domain" (nothing to do with NT domains).
    I didn't have the test environment to test it, but I would expect a much
    worse scenario if the trojan is written to the inoculan domain's server
    CHEYUPD$ shared directory. I'm afraid that the trojan would be copied to all
    machines of that domain.
    This is serious, because all machines would be running arbitrary code in
    place of the anti-virus program.
    
    
    Fortunately, this problem is now fixed by Cheyenne, but I think there are a
    lot of such security holes yet to be found in all anti-virus auto-update
    mechanisms.
    
    most run the same scenario :
    1) a update is issued by the anti-virus vendor on its FTP or Web server, or
    sent on a floppy disk or CD, or downloaded using a dedicated modem
    connection from the vendor's remote access server.
    2) the update is copied to a few servers within the client network
    3) all machines get the update from this or those servers
    4) all machines run the updated version.
    
    This present problem with Inoculan uses a vulnerability allowing a user on
    the internal network to fake step 2 and/or 3.
    If you imagine the vendor's ftp server is compromised, the attacker could
    fake step 1 with much more widespread impact.
    If you imagine the client connection to the Internet is compromised, an
    attacker could redirect to a fake ftp server. This would impact step 2.
    
    Paul Boyer
    p__boyerat_private
    
    
    ____________________________________________________________________
    Get free e-mail and a permanent address at http://www.netaddress.com/?N=1
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:57:43 PDT