Subject: Windows NT Task Scheduler vulnerability allows user to administrator elevation
 Date: Thu Dec 02 1999 00:00:50
 Author: Arne Vidstrom

Hi all,

We've found a vulnerability that the installation of Internet Explorer 5
introduces in Windows NT through the Task Scheduler service. This
vulnerability makes it possible for a User to become a member of the
Administrators group if he/she can do an interactive logon.

The Task Scheduler service is an "improved" version of the usual Schedule
service - they are not the same thing. The Schedule service is replaced by
the Task Scheduler when Internet Explorer 5 is installed on Windows NT.


-- Our test setup was the following --

TARGET:
 * Windows NT 4.0 Server
 * SP 5
 * IE 5.00.2014.0216
 * Task Scheduler running
 * Default permissions on the disks and in the registry
 * The account "test" is a User and the attacker knows the password for this
account
 * There exists a file "file.txt", owned by Administrators and with Change
permissions for "test"
 * Hex Workshop or similar is installed (can be installed by the attacker)

ATTACKER:
 * Windows NT 4.0 Server
 * SP 5
 * IE 5.00.2014.0216
 * Task Scheduler running
 * The attacker knows the password for an administrator account on ATTACKER
 * The clock has been set fairly close to the clock in TARGET


-- The interactive attack scenario we used was the following --

1) The attacker creates a job at ATTACKER to be run at hh:mm, with the
command:

at hh:mm net localgroup administrators test /add

This results in a job file c:\winnt\tasks\At1.job being created.

2) The attacker copies the At1.job file to TARGET and opens it in Hex
Workshop.

3) The attacker opens file.txt in Hex Workshop, and deletes the contents of
the file.

4) The attacker copies the contents of At1.job to file.txt in Hex Workshop,
deletes At1.job and saves file.txt. He/she then closes Hex Workshop.

5) The attacker renames file.txt to At1.job.

6) The attacker *moves* At1.job into the c:\winnt\tasks directory.

7) At hh:mm, the Task Scheduler runs the job, which adds "test" to the
Administrators group.

8) The attacker logs out and logs back in again, now being an administrator.

Note: If the job file isn't owned by Administrators but by "test", the
attack will fail, thus the need for file.txt. The attacker must *move* the
file at step 6 instead of copying it, in order to maintain the
Administrators ownership of the file.


-- Why/how does this really work? --

If you create a job file with the GUI interface on ATTACKER, you have to
specify under which account the job is supposed to run. Even if you
construct a valid job file like this and get it into TARGET like we describe
above, the job will not run. This is because the access credentials are not
copied with the job file. However, if you use the "at" command, the Task
Scheduler will be backwards compatible with the Schedule service and run the
job under a preselected account, the so-called "AT Service Account". This
account can be changed to any account (but only by an administrator), but as
default it is SYSTEM (the same account as the Schedule service uses). This
special case job file doesn't have any real access credentials tied to it,
the only check that the Task Scheduler does for its validity is that of file
ownership. You have to be an administrator to use the "at" command, so the
check is if the file is owned by Administrators or not. The designers
probably relied on the fact that in Windows NT, there is no way to give away
ownership to another user. However, by changing the contents of a file that
is already owned by an administrator, and to which you have Change
permissions, you can circumvent that. This is why/how this attack works.


-- What about network attack? --

*Network attack is not possible on a default installed machine.* However, it
could be performed with slight modifications if the configuration is changed
from the default.

Except a default installation of Windows NT and Internet Explorer 5, there
must at least exist a shared directory on TARGET where "test" have Change
permissions, and a file there that is owned by Administrators and to which
"test" have Change permissions. Even if the attacker doesn't have access to
c:\winnt\tasks, he/she can change the tasks directory to the shared
directory by changing:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SchedulingAgent\TasksFolder

remotely and waiting for somebody to reboot TARGET for the change to take
effect. *But this can only be performed if the default permissions on the
winreg key have been changed so "test"  has network access to the registry.*
Also note that there is no need for anybody to be logged in for the job to
run.


-- The fix --

The fix for this vulnerability is to install Internet Explorer 5.01, since
Microsoft has rewritten the Task Scheduler in it to resolve the problem.


-- Additional information --

Microsoft has released a security bulletin which you can find at:

https://www.microsoft.com/Security/Bulletins/ms99-051.asp

They have also composed a FAQ for the bulletin:

https://www.microsoft.com/security/bulletins/MS99-051faq.asp

And you can find this posting in the advisory archive of ntsecurity.nu:

https://ntsecurity.nu/advisories/a11.shtml


Regards,

/Arne Vidstrom & Svante Sennmark

https://ntsecurity.nu