Bugtraq mailing list archives
FW: [NTBUGTRAQ] AT Jobs - Denial of serice/Privilege Elevation
From: Carlos_DeAvillez () STERCOMM COM (DeAvillez, Carlos)
Date: Tue, 14 Mar 2000 13:52:16 -0600
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
Current thread:
- FW: [NTBUGTRAQ] AT Jobs - Denial of serice/Privilege Elevation DeAvillez, Carlos (Mar 14)
- Malicious-HTML vulnerabilities at deja.com Niall Smart (Mar 15)
- Re: Malicious-HTML vulnerabilities at deja.com Geert Altena (Mar 17)
- Re: FW: [NTBUGTRAQ] AT Jobs - Denial of serice/Privilege Elevation Andy Caus (Mar 16)
- Re: FW: [NTBUGTRAQ] AT Jobs - Denial of serice/Privilege Elevation Daniel Harter (Mar 17)
- OfficeScan TrendMicro: admin for everybody ! Gregory Duchemin (Mar 16)
- Analysis of the Shaft distributed denial of service tool Sven Dietrich (Mar 16)
- Re: Analysis of the Shaft distributed denial of service tool Max Vision (Mar 17)
- Malicious-HTML vulnerabilities at deja.com Niall Smart (Mar 15)