This is a multi-part message in MIME format. ------=_NextPart_000_000A_01BE91B6.DCF80630 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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).=20 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.=20 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/ ------=_NextPart_000_000A_01BE91B6.DCF80630 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 = HTML//EN"> <META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>Problem : NT users can cause other = users of the=20 system to load a "trojaned" profile that could lead to a = system=20 compromise. This issue has been here for as long as NT 4 has, but I'm = not sure=20 if anybody has picked this particular issue up.</FONT></DIV> <DIV> </DIV> <DIV><FONT color=3D#000000 size=3D2>Details: When a user logs onto an NT = Workstation=20 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=20 the user's Security Identifier or SID. One of the values of this key is = the=20 ProfileImagePath which points to the location of the user's profile = directory.=20 This can reference a local path (eg %systemroot%\profiles\acc_name) or a = UNC=20 path (eg \\PDC\profiles\acc_name). </FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT size=3D2>By default, the permissions on the ProfileList = registry key=20 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.=20 Consequently a malicious user of the system could change another user's=20 ProfileImagePath and get it to load a different profile (eg = c:\trojaned-profile)=20 that contains entries in the Start Up folder that will run when that = user next=20 logs on to that system. </FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>Editing these Registry keys can be done local or = from across=20 the network. </FONT><FONT color=3D#000000 size=3D2>Although remote = access to the=20 registry can be controlled by placing controls on the winreg key, the=20 HKLM\Software\Microsoft\Windows NT\CurrentVersion path into the Registry = is, by=20 default, an AllowedPath, meaning that, irrespective of the ACLs set on = the=20 winreg key, a remote user may edit any subkey under the CurrentVersion = key. Note=20 that tools such as Regedit.exe and Regedt32.exe will not be able to be = used to=20 to this. The NT Resource Kit's reg.exe could though because it opens a = handle=20 straight to the Registry key in question.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2>Attack Scenario: This weakness of = default=20 settings, could allow a normal domain user to gain domain Administrative = rights:=20 Assuming the attackers machine is called <A = href=3D"file://\\DODGY">\\DODGY</A>=20 and the PDC is called <A href=3D"file://\\PDC">\\PDC</A> , the user = jsmith at <A=20 href=3D"file://\\DODGY">\\DODGY</A> creates a new directory on the root = of their=20 C: drive and call it "profile" and copy into it the contents = of their=20 own profile and then make some changes like creating a batch file called = addme.bat with the following contents:</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2>net groups "Domain Admins" = jsmith=20 /add</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>del "<A=20 href=3D"file://\\DODGY\C$\profile\start = menu\programs\startup\addme.bat">\\DODGY\C$\profile\start=20 menu\programs\startup\addme.bat</A>"</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2>Once they have logged onto the = domain they use=20 reg.exe to open the Administrator's ProfileList key. This is easily = found as it=20 is the SID with a RID of 500. They then edit the ProfileImagePath to = point to <A=20 href=3D"file://\\DODGY\C$\profile">\\DODGY\C$\profile</A> . Next time = the=20 Administrator logs on at the <A href=3D"file://\\PDC">\\PDC</A> console = their=20 profile will be loaded from <A href=3D"file://\\DODGY">\\DODGY</A> = (because Domain=20 Admins are members of the local Administrators group they can map to the = administrative share on <A href=3D"file://\\DODGY">\\DODGY</A> ) and the = self=20 deleteing batch file in the StartUp wil be run adding jsmith to the = Domain=20 Admins group.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2>This whole process can be cleaned up = somewhat as=20 in most cases it would be fairly obvious that something is not as it = should be=20 to the Administrator when they log on.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2>Resolution: The winlogon.exe process = actually=20 creates the new subkey when a user logs on - and the key is _not_ = created in the=20 security context of the user currently logging on but rather the SYSTEM = account.=20 Only the SYSTEM account, then, needs write access to the ProfileList key = and=20 Everyone else should be given only Read Access. Doing this will not = prevent new=20 users from logging on and they "SID" subkey is still=20 created.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT size=3D2>NB:- This issue can also allow users to bypass = mandatory=20 profiles etc, etc.</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>Cheers,</FONT></DIV> <DIV><FONT size=3D2>David Litchfield</FONT></DIV> <DIV><FONT size=3D2><A=20 href=3D"http://www.infowar.co.uk/mnemonix">http://www.infowar.co.uk/mnemo= nix</A></FONT></DIV> <DIV><FONT size=3D2></FONT><FONT color=3D#000000 size=3D2><A=20 href=3D"http://www.arca.com/">http://www.arca.com/></FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV></BODY></HTML> ------=_NextPart_000_000A_01BE91B6.DCF80630--
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:44:16 PDT