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: http://www.microsoft.com/Security/Bulletins/ms99-051.asp They have also composed a FAQ for the bulletin: http://www.microsoft.com/security/bulletins/MS99-051faq.asp And you can find this posting in the advisory archive of ntsecurity.nu: http://ntsecurity.nu/advisories/a11.shtml Regards, /Arne Vidstrom & Svante Sennmark http://ntsecurity.nu
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:16:11 PDT