COMMAND

    profile permissions

SYSTEMS AFFECTED

    WinNT

PROBLEM

    Mnemonix posted following.  NT users can cause other users of  the
    system to load a  "trojaned"  profile that could lead to a  system
    compromise.  This is like:

        http://oliver.efri.hr/~crv/security/bugs/NT/profile.html

    When a user  logs onto an  NT Workstation or  Server a new  subkey
    is written to the

        HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList

    registry key.   The name  of this  new key  is that  of the user's
    Security Identifier or SID.  One of the values of this key is  the
    ProfileImagePath  which  points  to  the  location  of  the user's
    profile  directory.    This  can  reference   a  local  path   (eg
    %systemroot%\profiles\acc_name)    or    a     UNC    path     (eg
    \\PDC\profiles\acc_name).   By  default,  the  permissions  on the
    ProfileList registry key grants  the Everybody group the  SetValue
    permission meaning  that any  user including  guests may  edit the
    information in this subkey and  all of its subkeys.   Consequently
    a  malicious  user  of  the  system  could  change  another user's
    ProfileImagePath  and  get  it  to  load  a  different profile (eg
    c:\trojaned-profile) that contains entries in the Start Up  folder
    that will run when that user next logs on to that system.

    Editing these Registry keys can  be done local or from  across the
    network.  Although remote access to the registry can be controlled
    by placing controls on the winreg key, the

        HKLM\Software\Microsoft\Windows NT\CurrentVersion

    path into  the Registry  is, by  default, an  AllowedPath, meaning
    that, irrespective  of the  ACLs set  on the  winreg key, a remote
    user may edit any subkey under the CurrentVersion key.  Note  that
    tools such as Regedit.exe and Regedt32.exe will not be able to  be
    used  to  to  this.   The  NT  Resource Kit's reg.exe could though
    because  it  opens  a  handle  straight  to  the  Registry  key in
    question.

    This weakness  of default  settings, could  allow a  normal domain
    user to gain domain Administrative rights: Assuming the  attackers
    machine is called \\DODGY and the  PDC is called \\PDC , the  user
    jsmith at \\DODGY creates a new directory on the root of their  C:
    drive and call it "profile" and copy into it the contents of their
    own profile and then make some changes like creating a batch  file
    called addme.bat with the following contents:

        net groups "Domain Admins" jsmith /add
        del "\\DODGY\C$\profile\start menu\programs\startup\addme.bat"

    Once they have logged onto the domain they use reg.exe to open the
    Administrator's ProfileList key.   This is easily  found as it  is
    the SID with a RID of 500. They then edit the ProfileImagePath  to
    point to \\DODGY\C$\profile.  Next time the Administrator logs  on
    at the  \\PDC console  their profile  will be  loaded from \\DODGY
    (because Domain  Admins are  members of  the local  Administrators
    group they  can map  to the  administrative share  on \\DODGY) and
    the self  deleteing batch  file in  the StartUp  wil be run adding
    jsmith to  the Domain  Admins group.   This whole  process can  be
    cleaned up somewhat  as in most  cases it would  be fairly obvious
    that something is  not as it  should be to  the Administrator when
    they log on.

    There  has  been  some  questions  over  whether it is possible to
    "trojan" a  profile and  get the  domain administrator  to pick it
    up.  Sometimes this works  over the network sometimes not.   Below
    is a  sure fire  way of  getting this  to succeed.   This has been
    tested  on  both   SP3  and  SP4   machines  and  it   has  worked
    consistently:

        - NT Server 4 (SP4) Primary Domain Controller for domain  TEST
          is called PDC.
        - NT  Workstation 4  (SP4) client  which is  part of  the TEST
          domain.  This machine is called CLIENT.

    The  Administrator  has  a  local  profile stored on PDC.All other
    domain users have a roaming profile - their profiles are stored in
    the %systemroot%\profiles  directory which  is shared  as Profiles
    (\\PDC\profiles) The share permissions give Everybody Full Control
    of the share but using NTFS permissions to tighten access to other
    peoples  profiles  meaning  that  only  the  user can access their
    profile in any way (with the exception of Administrators).  Domain
    User testacc logs onto CLIENT.   Using reg.exe or a tool of  their
    own making, they access  the Registry of PDC.   The winreg key  on
    PDC specifies  that only  Administrators may  access the  registry
    remotely but the AllowedPaths specify that

        HKLM\Software\Microsoft\Windows NT\CurrentVersion

    is  an  allowed  path.   This  is  default.   testacc  changes the
    Administrator's ProfileImagePath to point to

        %systemroot%\profiles\testacc

    and then places a self deleting batch file in the Start Up folder.
    This batch file, when run with enough privileges will add  testacc
    to the  Domain Admins  group.   The next  time Administrator  logs
    onto PDC they pick up testacc's profile and the batch file is  run
    making testacc a domain admin.

SOLUTION

    The winlogon.exe process  actually creates the  new subkey when  a
    user  logs  on  -  and  the  key  is _not_ created in the security
    context of  the user  currently logging  on but  rather the SYSTEM
    account.  Only the SYSTEM account, then, needs write access to the
    ProfileList  key  and  Everyone  else  should  be  given only Read
    Access.  Doing this will not prevent new users from logging on and
    they "SID" subkey is still created.

    The "Securing  Windows NT"  Whitepaper from  the www.microsoft.com
    (just use the search capabiltiy for exactly the phrase in  quotes)
    already notes that you must ACL the ProfileList key as suggested:

        http://www.microsoft.com/NTServer/security/exec/overview/Secure_NTInstall.asp

    Also, the SCE  templates included with  SP4 were designed  to help
    automate  the  application  of  the  recommendations  in the White
    Paper.  Also, the SCE  templates in SP4/SP5 included one  designed
    to  help  automate  the  recommendatiaons  in  the  whitepaper  --
    securws4.inf, IIRC.  However, MS  just examined  it and  it allows
    "Power Users" (abbreviated "PU") to write the key. It'll be  fixed
    in  SP6.   In  the  meantime,  one  can  hand  edit  the entry for
    ProfileList in the template. Find the line that looks like this:

        "MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList",2,"D:P(A;CI;GR;;;AU)(A;CI;GA;;;DA)(A;CI;GA;;;SY)(A;CI;GA;;;CO)(A;CI;GRGW;;;PU)"

    and get rid of the "(A;CI;GRGW;;;PU)" at the end.