IE 5.0 Task Scheduler Elevates Privs - 29 Nov 1999

Arne and Svante found a vulnerability introduced into Windows NT by the installation of Internet Explorer 5. The problem affects NT"s Task Scheduler service. According to their report,

"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.

VENDOR RESPONSE