[14290] in bugtraq
FW: [NTBUGTRAQ] AT Jobs - Denial of serice/Privilege Elevation
daemon@ATHENA.MIT.EDU (DeAvillez, Carlos)
Wed Mar 15 01:05:29 2000
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01BF8DEE.D1315ACE"
Message-ID: <F91320BA2EA7D311B01400A0C9DF88FB42446C@csgexmail1.csg.stercomm.com>
Date: Tue, 14 Mar 2000 13:52:16 -0600
Reply-To: "DeAvillez, Carlos" <Carlos_DeAvillez@STERCOMM.COM>
From: "DeAvillez, Carlos" <Carlos_DeAvillez@STERCOMM.COM>
X-To: "bugtraq@securityfocus.com" <bugtraq@securityfocus.com>
To: BUGTRAQ@SECURITYFOCUS.COM
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BF8DEE.D1315ACE
Content-Type: text/plain;
charset="iso-8859-1"
sounds nice...
-----Original Message-----
From: Shawn Wright [mailto:swright@sls.bc.ca]
Sent: Tuesday, March 14, 2000 1:05 AM
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: [NTBUGTRAQ] AT Jobs - Denial of serice/Privilege Elevation
Russ,
Here is my previous post edited for clarity, and now includes tests with SP5
and SP6a.
============
Issue: Drive Mappings in Interactive Login affect Processes running in
context of Schedule User.
Points indicating this is a bug/security exploit and not by design (as
somehave indicated to me)
1. Drive mappings are individual to each user, as seen by their location in
the
registry under HKCU\Network. This point alone indicates a bug. Why should
the *personal* drive mappings of an interactive login session have *any*
affect on a service running in a different user context, in a supposedly
secure
environment? They shouldn't, plain and simple.
2. KB Article Q130668 is the only article I could find which has any
relationship to this issue, but it deals with a "bug" when the drives are
mapped to Netware Volumes using GSNW. However, reading between the
lines, one can see that the behavior described (which is identical in both
Netware and NT drive mappings) is not by design, otherwise, why would they
state this: Microsoft has confirmed this to be a problem in Windows NT
Workstation and Server versions 3.5, 3.51, and 4.0... They do offer up a
solution to one half of the problem - that is when the scheduled process
leaves a mapped drive, which then affects any interactive processes by
preventing the use of this drive (unless appropriate permissions exist for
the
interactive user). But they make no mention of the other half - that a non-
privileged user can affect the environment of the scheduled process, which
is
often in a priviliged account context.
Take the following scenario:
A "secure" NT workstation is configured with scheduler running in a user
context that has specific elevated rights in order to perform unattended
administrative functions based on scripts that are stored on a server. But
one
of the tasks performed in these scripts requires a mapped drive letter; UNC
paths won't work. So to be sure, the scripts begins by mapping a drive
letter
to the shared network resource containing the patches and updates placed
there when required. Often these patches are security fixes and the like,
and
the scheduler dutifully applies them to some large number of machines as
directed in the script.
Here comes the exploit. If an interactive login is present, and the same
drive
letter is already mapped by a user, the net use in the scheduled script will
fail,
as will the required hotfix or update. Not a pretty picture in a large LAN
whose
security and stability may rely on timely installation of these updates.
This is
the simplest "exploit".
Next we extend this a bit further: the user maps a drive letter in an
interactive
login, and places in it a script with the same filename as that called by
the
scheduled update, and makes sure the schedule user has permissions to
this file and network resource. All of this could be performed by a non-
privileged user. The schedule service will now execute this script in the
elevated user context, and the script could be instructed to install a
trojan,
add the user to the local Admin group, or whatever. The bottom line is that
this design flaw can be easily exploited to allow any user with interactive
login
rights to a workstation to elevate himself to the rights of the schedule
user,
which is often Administrator of the workstation.
I have tested this on NT4 SP5 and 6a. (Note this is without IE5 installed,
just
the built in AT scheduler). I have also tested this with all combinations of
Local and Domain accounts for both the scheduler and the interactive user. I
have tested it with and without persistent drive mappings present for either
user - in each case, whoever gets the login first gets the drive letter.
Comments?
========================
Shawn Wright
Computer Systems Manager
Shawnigan Lake School
http://www.sls.bc.ca
swright@sls.bc.ca
------_=_NextPart_001_01BF8DEE.D1315ACE
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>FW: [NTBUGTRAQ] AT Jobs - Denial of serice/Privilege Elevation</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>sounds nice...</FONT>
</P>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Shawn Wright [<A HREF="mailto:swright@sls.bc.ca">mailto:swright@sls.bc.ca</A>]</FONT>
<BR><FONT SIZE=2>Sent: Tuesday, March 14, 2000 1:05 AM</FONT>
<BR><FONT SIZE=2>To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM</FONT>
<BR><FONT SIZE=2>Subject: [NTBUGTRAQ] AT Jobs - Denial of serice/Privilege Elevation</FONT>
</P>
<BR>
<P><FONT SIZE=2>Russ,</FONT>
</P>
<P><FONT SIZE=2>Here is my previous post edited for clarity, and now includes tests with SP5</FONT>
<BR><FONT SIZE=2>and SP6a.</FONT>
<BR><FONT SIZE=2>============</FONT>
<BR><FONT SIZE=2>Issue: Drive Mappings in Interactive Login affect Processes running in</FONT>
<BR><FONT SIZE=2>context of Schedule User.</FONT>
</P>
<P><FONT SIZE=2>Points indicating this is a bug/security exploit and not by design (as</FONT>
<BR><FONT SIZE=2>somehave indicated to me)</FONT>
</P>
<P><FONT SIZE=2>1. Drive mappings are individual to each user, as seen by their location in the</FONT>
<BR><FONT SIZE=2>registry under HKCU\Network. This point alone indicates a bug. Why should</FONT>
<BR><FONT SIZE=2>the *personal* drive mappings of an interactive login session have *any*</FONT>
<BR><FONT SIZE=2>affect on a service running in a different user context, in a supposedly secure</FONT>
<BR><FONT SIZE=2>environment? They shouldn't, plain and simple.</FONT>
</P>
<P><FONT SIZE=2>2. KB Article Q130668 is the only article I could find which has any</FONT>
<BR><FONT SIZE=2>relationship to this issue, but it deals with a "bug" when the drives are</FONT>
<BR><FONT SIZE=2>mapped to Netware Volumes using GSNW. However, reading between the</FONT>
<BR><FONT SIZE=2>lines, one can see that the behavior described (which is identical in both</FONT>
<BR><FONT SIZE=2>Netware and NT drive mappings) is not by design, otherwise, why would they</FONT>
<BR><FONT SIZE=2>state this: Microsoft has confirmed this to be a problem in Windows NT</FONT>
<BR><FONT SIZE=2>Workstation and Server versions 3.5, 3.51, and 4.0... They do offer up a</FONT>
<BR><FONT SIZE=2>solution to one half of the problem - that is when the scheduled process</FONT>
<BR><FONT SIZE=2>leaves a mapped drive, which then affects any interactive processes by</FONT>
<BR><FONT SIZE=2>preventing the use of this drive (unless appropriate permissions exist for the</FONT>
<BR><FONT SIZE=2>interactive user). But they make no mention of the other half - that a non-</FONT>
<BR><FONT SIZE=2>privileged user can affect the environment of the scheduled process, which is</FONT>
<BR><FONT SIZE=2>often in a priviliged account context.</FONT>
</P>
<P><FONT SIZE=2>Take the following scenario:</FONT>
</P>
<P><FONT SIZE=2>A "secure" NT workstation is configured with scheduler running in a user</FONT>
<BR><FONT SIZE=2>context that has specific elevated rights in order to perform unattended</FONT>
<BR><FONT SIZE=2>administrative functions based on scripts that are stored on a server. But one</FONT>
<BR><FONT SIZE=2>of the tasks performed in these scripts requires a mapped drive letter; UNC</FONT>
<BR><FONT SIZE=2>paths won't work. So to be sure, the scripts begins by mapping a drive letter</FONT>
<BR><FONT SIZE=2>to the shared network resource containing the patches and updates placed</FONT>
<BR><FONT SIZE=2>there when required. Often these patches are security fixes and the like, and</FONT>
<BR><FONT SIZE=2>the scheduler dutifully applies them to some large number of machines as</FONT>
<BR><FONT SIZE=2>directed in the script.</FONT>
</P>
<P><FONT SIZE=2>Here comes the exploit. If an interactive login is present, and the same drive</FONT>
<BR><FONT SIZE=2>letter is already mapped by a user, the net use in the scheduled script will fail,</FONT>
<BR><FONT SIZE=2>as will the required hotfix or update. Not a pretty picture in a large LAN whose</FONT>
<BR><FONT SIZE=2>security and stability may rely on timely installation of these updates. This is</FONT>
<BR><FONT SIZE=2>the simplest "exploit".</FONT>
</P>
<P><FONT SIZE=2>Next we extend this a bit further: the user maps a drive letter in an interactive</FONT>
<BR><FONT SIZE=2>login, and places in it a script with the same filename as that called by the</FONT>
<BR><FONT SIZE=2>scheduled update, and makes sure the schedule user has permissions to</FONT>
<BR><FONT SIZE=2>this file and network resource. All of this could be performed by a non-</FONT>
<BR><FONT SIZE=2>privileged user. The schedule service will now execute this script in the</FONT>
<BR><FONT SIZE=2>elevated user context, and the script could be instructed to install a trojan,</FONT>
<BR><FONT SIZE=2>add the user to the local Admin group, or whatever. The bottom line is that</FONT>
<BR><FONT SIZE=2>this design flaw can be easily exploited to allow any user with interactive login</FONT>
<BR><FONT SIZE=2>rights to a workstation to elevate himself to the rights of the schedule user,</FONT>
<BR><FONT SIZE=2>which is often Administrator of the workstation.</FONT>
</P>
<P><FONT SIZE=2>I have tested this on NT4 SP5 and 6a. (Note this is without IE5 installed, just</FONT>
<BR><FONT SIZE=2>the built in AT scheduler). I have also tested this with all combinations of</FONT>
<BR><FONT SIZE=2>Local and Domain accounts for both the scheduler and the interactive user. I</FONT>
<BR><FONT SIZE=2>have tested it with and without persistent drive mappings present for either</FONT>
<BR><FONT SIZE=2>user - in each case, whoever gets the login first gets the drive letter.</FONT>
</P>
<P><FONT SIZE=2>Comments?</FONT>
</P>
<P><FONT SIZE=2>========================</FONT>
<BR><FONT SIZE=2>Shawn Wright</FONT>
<BR><FONT SIZE=2>Computer Systems Manager</FONT>
<BR><FONT SIZE=2>Shawnigan Lake School</FONT>
<BR><FONT SIZE=2><A HREF="http://www.sls.bc.ca" TARGET="_blank">http://www.sls.bc.ca</A></FONT>
<BR><FONT SIZE=2>swright@sls.bc.ca</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01BF8DEE.D1315ACE--
