Vulnerability

    Inoculan

Affected

    Inoculan Client

Description

    Glenn Corbett found following.  A problem has been discovered with
    the InocuLAN  client on  Windows NT  workstations.   If an account
    lockout policy is present on a Windows NT domain, large numbers of
    repeating account lockouts can occur.

    Incorrect password  events (event  id 529)  are being  logged from
    workstations  when  running  applications  from  UNC  paths.   The
    username that has  logged the incorrect  password is different  to
    that of the logged on user.  This was tested on Windows NT WKS SP3
    and  SP4,  with  InocuLAN  V4.0(373)  or  InocuLAN  V4.0(375).  To
    reproduce the problem:

    1. Install InocuLAN V4.0(373) or V4.0(375) onto an NT  workstation
       with SP3 or SP4 (SP5 not tested yet)
    2. Configure InocuLAN as described below:
       Options:
        Direction - Incoming and Outgoing files
        Action upon Virus detection - Cure File
        Cure Action for Macro Viruses - Remove Infected Macros
        Copy File before Cure
        Rename File when Cure Fails
        Rename Extension - AVB
        Move Directory - C:\Inoculan\VIRUS

        Protected Areas:
        Protect Floppy Drives
        Protect Network Drives
        Protect CD-ROM Drives

        Scan Type - Secure Scan

    3. Reboot the workstation
    4. Log into WorkstationA as Domain UserA, Logout Domain UserA
    5. From another workstation change the password of Domain UserA
    6. Log into WorkstationA as Domain UserB.
    7. From  WorkstationA run  an application  from a  remote share on
       WorkstationX where Logon and Logoff, Success/Failure, are being
       audited.  Run  an application from  the cmd window  using a UNC
       path  with  no  other  connections  to  the  WorkstationX.   Eg
       \\WorkstationX\shareX\notepad
    8. The application will take several seconds to run and there will
       be a failure security event (529) for UserA from Workstation A.
       From  server  manager  remotely  stop  the  Cheyenne   InocuLAN
       Anti-Virus Server on Workstation A and repeat step 7.  You will
       see that the application  will start immediately and  no errors
       will be recorded in the security event log.

    The above problem also causes problems when running logon scripts.
    If  an  application  is  called  from  the  logon  script and that
    application does not  exit on the  local workstation, the  version
    in the logon share will be run.  As soon as the application in the
    logon script  is called  there is  an event  529 error recorded on
    the logon server security event log.  Even if subsequent different
    users log into  Workstation A, these  problem will continue  until
    the workstation is rebooted.  This behaviour can also been seen if
    in Step 4, a local userA logs on. The subsequent error 529's  have
    the local userA account in the security event.

    It appears as though InocuLAN is storing the user credentials  for
    the first logged on user and using them to scan network drives for
    virus'  even  when  a  different  user  subsequently logs on until
    workstation reboot.   It is  not yet  apparent if  this username /
    password  is  being  stored  in  the  registry / temporary file or
    memory, and therefore open to exploit.

Solution

    That  assertion  is  inaccurate,  the username/password credential
    combination is NOT stored on  the client side by Inoculan,  (which
    is why the efforts to  locate these credentials in shared  memory,
    in a file or in the registry have been unsuccessful).  Clearly, in
    order for  the InocuLAN  real-time scanner  to access  files on  a
    remote server, the software  must have valid security  contexts in
    place  to  permit  the  requisite  access  to the file systems and
    files.  The techniques utilized by Inoculan (using low level,  but
    fully  documented  and  supported  standard  vendor  API's) do NOT
    require that traditional user credentials (user account/ password)
    be  presented  in  order  to  gain  the necessary access.  Rather,
    Inoculan  is  able  to  gain  the  required access in a completely
    secure  manner  without  prompting   for  username  and   password
    information.  In  addition, it is  important to point  out that NO
    attempt to  retrieve credential  data is  done without  the user's
    explicit advance knowledge and consent.  Computation/generation of
    the requisite  credential information  is done  at Inoculan driver
    initialization  time,  and  can  be  easily  refreshed  by  simply
    rebooting the  machine (which  of course  will in  turn result  in
    Inoculan initialization routines being  invoked as part of  system
    restart).

    The particular behaviour observed  and reported can be  attributed
    to the fact that AFTER Inoculan initialization was completed,  the
    user access credentials  for the user  in question were  modified,
    rendering the originally  computed credential that  Inoculan would
    otherwise utilize,  invalid.   An enhancement  is being  developed
    presently to  provide a  configuration setting  that will instruct
    the   Inoculan   real-time   scanner   to   recompute  credentials
    automatically  thus  eliminating  the  need  to  reboot the client
    machine.   The  enhancement  can  be  downloaded from our Computer
    Associates support web sites at

        http://support.cai.com/Download/patches/inocnt.html

    and the file is called LO49393.CAZ.