NT Security Advisory: Domain user to Domain Admin - Profiles and

[mnemonix () GLOBALNET CO UK (Mnemonix)]

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/</A></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--