FW: [NTBUGTRAQ] AT Jobs - Denial of serice/Privilege Elevation

[Carlos_DeAvillez () STERCOMM COM (DeAvillez, Carlos)]

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