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

[andy () PROMETAL BE (Andy Caus)]

You should ALWAYS use:

if exist <driveletter> net use <driveletter> /d 

before you use "net use" in such a script.

This will unmap the existing network drive (if any) from the
driveletter to be mapped.

Greetz,

Data

-----Original Message-----
From: Shawn Wright [mailto:<A
HREF="mailto:swright () sls bc ca">swright () sls bc ca</A>]
Sent: Tuesday, March 14, 2000 1:05 AM
To: <A
HREF="mailto:NTBUGTRAQ () LISTSERV NTBUGTRAQ COM">NTBUGTRAQ () LISTSERV NTBUGTRAQ COM</A>
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