COMMAND

    kernel

SYSTEMS AFFECTED

    Windows NT/2000

PROBLEM

    Tony Thai found following.  He reported a vulnerability in Windows
    NT/2000  which  allows  a  user  with  local admin privileges on a
    member server/workstation to elevate their privileges in a Windows
    NT/2000 domain.   This problem is  related to Windows  NT services
    and is only exists if the an service exists on the local  computer
    which uses a privileged domain account to logon.

    A user  with local  administrator privileges  to a  workstation or
    server which is a member of a domain can elevate their  privileges
    if a service exists on the local computer with higher rights  than
    the user.   Eg. if  the service  is configured  to start  with  an
    account which has domain administrator privileges.

    To take advantage to this, a user modifies the parameters for  the
    service  which  starts   with  higher  privileges   to  start   an
    application or run  a command of  their choice.   After restarting
    the service,  the command/application  is executed  in the context
    of the account used to start the service.

    To replicate this do the following:
    1. Find  a service  on the  local computer  which has  the Startup
       Account as a Domain Administrator account.
    2. Using  the regedt32.exe,  in the  registry search  for the  key
       corresponding to the service under HKLM\System\CCS\Services\
    3. In the key corresponding to the service, replace the  ImagePath
       value with the following

        <path to ntreskit folder>\srvany.exe eg. c:\ntreskit\srvany.exe

    4. Replace the Type with 0x110.
    5. Create  a  subkey  called  Parameters  and  add a value  called
       Application with the following value

        c:\winnt\system32\cmd.exe /k net user user123 password /add /domain

    6. In the  services application in  Control Panel, start  and stop
       the service which was modified in steps 3 and 4.
    7. An account user123 will be created in the domain.
    8. Modify the Application value in step 5 with the following value

        c:\winnt\system32\cmd.exe /k net localgroup administrators user123 /add /domain

    9. In the  services application in  Control Panel, start  and stop
       the service which was modified in steps 3 and 4.
   10. The user123 account is added to the administrators local  group
       on the domain controllers.

    Note: If  all services  on the  local computer  do not  use domain
    accounts then the  computer is not  vulnerable.  To  reproduce the
    problem  on  a  computer  without  services running using a domain
    account,  configure  an  existing  service  to start with a domain
    account with membership to the domain administrators group.   This
    service should be of type 0x10 or 0x110.  Then continue with  step
    2.

    Similar  steps  can  be  used  to  add  the  user  to  the  domain
    administrators group using different utilities.  Other  variations
    are possible.   This was  tested on  a Windows  NT 4.0 workstation
    running in a Windows NT 4.0 domain. Service Pack 4.  This was also
    reproduced on a  Windows 2000 computer  running in a  Windows 2000
    domain Service Pack 1.

    Possible attacks  include exploiting  a buffer  overflow on  a Web
    Server which is a member  of a domain giving local  system access.
    Privileges may be  then be elvevated  from local system  to domain
    admin in the appropriate environment.

    It should be pointed out  that anyone with local Admin  privileges
    on  a  box  that  has  a  Domain Account-based service running can
    easily run  l0phtcrack, or  some similar  tool, against  their own
    SAM and determine  the password of  the service account  that way.
    They can, then,  use that account  information to do  other things
    (like  not  having  to  use  Srvany  to  launch a service of their
    choice).

    It reminds us of  a story someone once  told Russ Cooper of  how a
    machine  he  had  kept  getting  compromised by fellow co-workers,
    they all had  the same Backup  agent software using  the identical
    userID on all  machines within a  domain...  That  story is almost
    3 years old now.

    The technique Tony describes is a little more interesting, but  is
    just another  manifestation of  the problems  blindly giving Local
    Admin access create.

SOLUTION

    Restrict  service  accounts  to  run  without  domain adminstrator
    privileges.  It is prudent to ensure that all service accounts are
    configure with the minimal level of privileges required.