Date: Wed, 28 Apr 1999 20:36:58 +0100 From: Mnemonix To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM 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" profile that could lead to a system compromise. This issue has been here for as long 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 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. Attack Scenario: 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. Resolution: 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. NB:- This issue can also allow users to bypass mandatory profiles etc, etc. Cheers, David Litchfield http://www.infowar.co.uk/mnemonix http://www.arca.com/ ------------------------------------------------------------------------------------------- Date: Thu, 29 Apr 1999 09:58:35 -0700 From: Paul Leach To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry > -----Original Message----- > From: Mnemonix [mailto:mnemonix@GLOBALNET.CO.UK] > Sent: Wednesday, April 28, 1999 12:37 PM > To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM > 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" profile that could lead to a system > compromise. This issue has been here for as long as NT 4 has, > but I'm not sure if anybody has picked this particular issue up. Yes, they have. 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 you suggest. Paul ------------------------------------------------------------------------------------------- Date: Thu, 29 Apr 1999 11:44:18 -0700 From: Paul Leach To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry > -----Original Message----- > From: Paul Leach [mailto:paulle@MICROSOFT.COM] > Sent: Thursday, April 29, 1999 9:59 AM > To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM > Subject: Re: NT Security Advisory: Domain user to Domain Admin - > Profiles and the Registry > > > > -----Original Message----- > > From: Mnemonix [mailto:mnemonix@GLOBALNET.CO.UK] > > Sent: Wednesday, April 28, 1999 12:37 PM > > To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM > > 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" profile that could lead to a system > > compromise. This issue has been here for as long as NT 4 has, > > but I'm not sure if anybody has picked this particular issue up. > > Yes, they have. > > 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 you suggest. I had mistemembered that the above search got exactly one hit -- instead, it was the first hit on the list. The precise URL is http://www.microsoft.com/NTServer/security/exec/overview/Secure_NTInstall.as p Also, the SCE templates included with SP4 were designed to help automate the application of the recommendations in the White Paper. So if you want to make the fix to the ACL on Profile list, I'd suggest looking into them. Paul ------------------------------------------------------------------------------------------- Date: Thu, 29 Apr 1999 11:31:23 -0700 From: David LeBlanc To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry > From: Mnemonix [mailto:mnemonix@GLOBALNET.CO.UK] > Problem : NT users can cause other users of the system to > load a "trojaned" profile that could lead to a system > compromise. This issue has been here for as long as NT 4 has, > but I'm not sure if anybody has picked this particular issue up. I think you should search the archives on my name with ProfileList as a key, and that you will find a number of references. Dominique, Paul Leach and I had an extended discussion on that topic in this list nearly a year ago. > By default, the permissions on the ProfileList registry key > grants the Everybody group the SetValue permission If I'm not mistaken, only the system account ever accesses this key. At least that's what I found when auditing this tree several months ago. > 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. If we're going to start worrying about this one, this is just one of many modifications that need to be made. The best collection of resources in this area remains (IMHO) Steve Sutton's NSA paper at www.trustedsystems.com > Editing these Registry keys can be done local or from across > the network. This is only true of the server. A currently patched workstation requires admin access to open this portion of the registry across the network. However, to actually _trojan_ someone, you also must have the ability to insert new profiles under %systemroot%\Profiles, which is typically NOT available on a server. A good solution for a server would be to make the permissions on the parent key admins, system, and server ops. If the group of users who you expect to be logging on at the console of a server were more diverse, then I would recommend creating a group for just that purpose and setting the permissions to admins, system, and the group you established. So unless you're worried about a workstation with serial users, it turns out that the complete requirements to really carry out an attack are seldom met. > 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 . I would suggest that you actually try your scenarios. I have tried this, and it doesn't work. The admin will get the profile for the default user. The same is true if you try to point the profile anywhere else than %systemroot%profiles. > Resolution: 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. I recommended doing this some months ago. It is still not completely clear that this won't break something somewhere. As always, people should try this in their own systems and be sure something doesn't break. Another way to go at this one would be to put an app or script in the default user's startup group that would set the permissions to admins, system and that user. I believe supercacls (also from Steve Sutton) could be used to do this. ------------------------------------------------------------------------------------------- Date: Thu, 29 Apr 1999 12:31:21 -0700 From: Paul Leach To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry > -----Original Message----- > From: dan koons [mailto:dkoons@secured.net] > Sent: Thursday, April 29, 1999 11:52 AM > To: Paul Leach > Cc: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM > Subject: Re: NT Security Advisory: Domain user to Domain Admin - > Profiles and the Registry > > strange. i just followed your explicit instructions, grabbed > the first > file that turned up (which was called "securing windows nt > installation" > and was dated october 23, 1997) and searched it for the string > 'ProfileList' and was unable to find any matches. Here's a relevant section of the text, cut and paste from the doc: Protecting the Registry In addition to the considerations for standard security, the administrator of a high-security installation might want to set protections on certain keys in the registry. By default, protections are set on the various components of the registry that allow work to be done while providing standard-level security. For high-level security, you might want to assign access rights to specific registry keys. This should be done with caution, because programs that the users require to do their jobs often need to access certain keys on the users' behalf. For more information, see Chapter 24, "Registry Editor and Registry Administration." For each of the keys listed below, make the following change: Access allowed Everyone Group QueryValue, Enumerate Subkeys, Notify and Read Control In the HKEY_LOCAL_MACHINE on Local Machine dialog: \Software This change is recommended. It locks the system in terms of who can install software. Note that it is not recommended that the entire subtree be locked using this setting because that can render certain software unusable. \Software\Microsoft\RPC (and its subkeys) This locks the RPC services. \Software\Microsoft\Windows NT\ CurrentVersion \Software\Microsoft\Windows NT\ CurrentVersion\Profile List \Software\Microsoft\Windows NT\ CurrentVersion\AeDebug \Software\Microsoft\Windows NT\ CurrentVersion\Compatibility So it appears that there's a space in the spelling in the document. In the registry, there's no space. I'll report the bug. Perhaps all the clones of the document you cited also copied the spelling error :-) Paul ------------------------------------------------------------------------------------------- Date: Thu, 29 Apr 1999 12:00:56 -0700 From: dan koons To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry On Thu, 29 Apr 1999, dan koons wrote: > further, in the "windows nt security guidelines" developed for nsa > research (found at http://www.trustedsystems.com/NSAGuide.htm), the united > states department of energy's "windows nt security advisor" (at > http://doe-is.llnl.gov/SecRes/CustomTools/secadvisor.pdf), the united > states navy's "navy secure windows nt 4.0 installation and configuration > guide" (at http://infosec.navy.mil/COMPUSEC/ntsecure.html), and the > "hardening of windows nt 4.0" (at > http://pw2.netcom.com/~honeyluv/index.html), a search for the string > 'ProfileList' also does not yield any results. oops; my mistake. the navy guide DOES recommend setting the 'ProfileList' key to 'read' for 'Authenticated Users'. but i could not find any reference to the key in any of the other documents. dan _____________________________________________________________________ daniel e koons dkoons@secured.net _____________________________________________________________________ ------------------------------------------------------------------------------------------- Date: Thu, 29 Apr 1999 13:35:36 -0700 From: Paul Leach To: BUGTRAQ@netspace.org Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry -----Original Message----- >From: Mnemonix [mailto:mnemonix@GLOBALNET.CO.UK] Sent: Wednesday, April 28, 1999 12:37 PM To: BUGTRAQ@NETSPACE.ORG 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" profile that could lead to a system compromise. This issue has been here for as long 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 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). This is indeed an issue. It is documented in the "Securing Windows NT" whitepaper, http://www.microsoft.com/NTServer/security/exec/overview/Secure_NTInstall.as p and anyone who has implemented those recommendations will be safe against this vulnerability. (NB: The registry key is misspelled "Profile List" in the document.) Also, the SCE templates in SP4/SP5 included one designed to help automate the recommendatiaons in the whitepaper -- securws4.inf, IIRC. However, we 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\Windows NT\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. Paul ------------------------------------------------------------------------------------------- Date: Thu, 29 Apr 1999 13:53:05 -0700 From: Paul Leach To: BUGTRAQ@netspace.org Subject: Security Configuration Editor info Since I said that SCE could be used to fix the ProfileList bug that Mnemonix reported, I got a private request asking where more information about SCE (Security Configuration Editor) could be found -- they'd tried the usual places. I think they changed the name since SP4 to "Security Configuration Manager", but I called it SCE becaue most people know it by the old name, since that's what it was called in SP4. I did a search on that exact phrase at www.microsoft.com and got a lot of hits, the first one was http://www.microsoft.com/NTServer/security/techdetails/prodarch/securconfig. asp which looks pretty good. In general, a good place to look for security info on MS products is http://www.microsoft.com/security/Resources/whitepapers.as p Paul ------------------------------------------------------------------------------------------- Date: Fri, 30 Apr 1999 11:40:08 +0100 From: Paddy Duncan To: BUGTRAQ@netspace.org Subject: Re: Security Configuration Editor info It was here:- http://www.microsoft.com/support/winnt/sp4_central_40.htm I'm not sure whether registration is required to get in to this page or not. Alternatively, it's on the service pack 4 disk supplied with Technet 12/84 and later. It's a separate item, not included with the service pack itself. Paddy Duncan MCSE Intralan (UK) Ltd. ------------------------------------------------------------------------------------------- Date: Mon, 3 May 1999 10:15:40 -0700 From: Gary Kalbfleisch To: BUGTRAQ@netspace.org Subject: FW: NT Security: Domain user adding self to Domain Admin group. Does anyone have an additional information on this? We couldn't get it to work. -----Original Message----- To: 'Gary K' Subject: NT Security: Domain user adding self to Domain Admin group. Gary, Regarding the BUGTRAQ advisory you forwarded to me on the subject of an ordinary Domain user promoting self same to a Domain Admin, I was not able to confirm that this exploit will work. My research did turn up a security breach using "reg.exe" form the NT Resource Kit Which I will document later in this report. For now I would like to document my methodology and have you possibly forward it on to BUGTRAQ to see if anyone can enlighten us on where I went wrong. First I verified the various rights I thought would be involved. On the PDC the group Everyone has "Access this computer from Network". Rights to the Registry Key in question ( HKLM\SoftWare\Microsoft\Windows nt\CurrentVersion\ProfileList) are as follows; Administrators Full, System Full, and the problem child Everyone; Special Access = Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify & Read Control. Next I created a couple of batch files to test the results or using Reg.exe. One batch file using Reg Query to extract the current information in the ProfileList Subkey and another batch file with Reg Update to write changes to the value in that Subkey. To test that this would work I first ran these batch file logged in with Admin Rights. They both work fine I was able to extract data from the Subkey and write the value I wanted to it. The problem occurred when I logged in as an ordinary Domain user. Using the exact same batch files I was able to read the data in the ProfileList Subkey and all its Subkeys but was not able to write the new values to that Key or any Subkeys. When I would run the Reg Update batch file the error message "access denied" was returned. The security breach I mentioned in the first paragraph is that any Domain user could use Reg Query to access information on any one including System Admins that have logged in locally on the PDC or possibly other domain computers. John ------------------------------------------------------------------------------------------- Date: Tue, 4 May 1999 23:47:11 +0100 From: Mnemonix To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry >I think you should search the archives on my name with ProfileList as a key, >and that you will find a number of references. Dominique, Paul Leach and I >had an extended discussion on that topic in this list nearly a year ago. My search revealed nothing - but then that's not to say I looked in the right places. >> By default, the permissions on the ProfileList registry key >> grants the Everybody group the SetValue permission > >If I'm not mistaken, only the system account ever accesses this key. At >least that's what I found when auditing this tree several months ago. Agreed, as was stated in my original mail. >This is only true of the server. A currently patched workstation requires >admin access to open this portion of the registry across the network. >However, to actually _trojan_ someone, you also must have the ability to >insert new profiles under %systemroot%\Profiles, which is typically NOT >available on a server. Sorry but this is not true - you can pick a profile up from anywhere. Well so my and my colleagues testing has shown. Are you using roving or local profiling? >I would suggest that you actually try your scenarios. I have tried this, >and it doesn't work. The admin will get the profile for the default user. >The same is true if you try to point the profile anywhere else than >%systemroot%profiles. As it was with the SLMail issue where you stated I should try my scenarios out first (the fix in the SLMail issue) you err - this was tested and yes it worked. As to why you cannot reproduce this - I don't know but I know of at least five people now who have successfully done this. A number of people have spoken of not being able to use reg.exe to access this key - they get an access denied, even when HKLM\Software\Microsoft\Windows Nt\CurrentVersion\ is allowed path. I have written a program that accesses the profile list key directly, and a user supplied subkey (the SID) and change the profileimagepath to what the user specifies. For testing purposes I will give this program to people at my disgression - I won't make it publicly available. Cheers, David Litchfield ------------------------------------------------------------------------------------------- Date: Tue, 4 May 1999 11:02:46 CDT From: McKay To: BUGTRAQ@netspace.org Subject: Re: [FW: NT Security: Domain user adding self to Domain Admin group.] Gary, I also had problems with getting this to work.... Here is my setup I tested against. * NT 4.0 Server w/SP3 patch only applied. * Various NT 4.0 Workstations with only SP3 or SP4 applied. These were also all installed with Default Configurations. I changed nothing >from how it was installed. Gary Kalbfleisch wrote: > First I verified the various rights I thought would be involved. On the PDC > the group Everyone has "Access this computer from Network". Rights to the > Registry Key in question ( HKLM\SoftWare\Microsoft\Windows > nt\CurrentVersion\ProfileList) are as follows; Administrators Full, System > Full, and the problem child Everyone; Special Access = Query Value, Set > Value, Create Subkey, Enumerate Subkeys, Notify & Read Control. > I verified the same type of permissions on the registry keys in particular. > The problem occurred when I logged in as an ordinary Domain user. Using the > exact same batch files I was able to read the data in the ProfileList Subkey > and all its Subkeys but was not able to write the new values to that Key or > any Subkeys. When I would run the Reg Update batch file the error message > "access denied" was returned. That is strange, when I ran reg.exe as a Domain User on the key in question, I just got the "access denied" on both the query and the update :( > The security breach I mentioned in the first paragraph is that any Domain > user could use Reg Query to access information on any one including System > Admins that have logged in locally on the PDC or possibly other domain > computers. I wasn't able to query any info from the registry in question as just a Domain User :( I did find one interesting "Feature" of reg.exe and regedt32.exe. Apparently if you are logged in remotely to the PDC using a local account on a machine on the Windows NT network and your local account happens to have the same username and password as a domain account on the PDC, then you get the domain account's rights regardless of your local rights. So if your local group has User permissions only and the corresponding domain group has Administrators rights, then you get to access the registry as if you were an Administrator. McKay ------------------------------------------------------------------------------------------- Date: Wed, 5 May 1999 18:00:06 +0100 From: Mnemonix To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Follow up - Domain user to Domain Admin - Profiles and the Registry 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 - thanks to all who have tried. Below is a sure fire way of getting this to succeed. I have tested this on both SP3 and SP4 machines and it has worked consistently: Network setup: 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. If anyone can still not repro this with this setup, then please let me know Cheers, David Litchfield http://www.infowar.co.uk/mnemonix http://www.arca.com