New issue
Advanced search Search tips
Starred by 2 users
Status: Fixed
Owner:
Closed: Sep 2015
Cc:



Sign in to add a comment
Windows: Task Scheduler DeleteExpiredTaskAfter File Deletion Elevation of Privilege
Project Member Reported by forshaw@google.com, Jun 12 2015 Back to list
Windows: Task Scheduler DeleteExpiredTaskAfter File Deletion Elevation of Privilege
Platform: Windows 8.1 Update, looks like it should work on 7 and 10 as well
Class: Elevation of Privilege

Summary:
The Task Scheduler can be made to delete a task after it’s trigger has expired. No check is made to ensure the task file is not a junction which allows arbitrary files to be deleted by the system user leading to EoP.

Description:

If a scheduled task is configured with DeleteExpiredTaskAfter setting the service will delete the task including its task file after the triggers have expired. It does the deletion in a timer callback thread but doesn’t call DeleteFile with the privileges of the task, instead running at local system. While the scheduler now seems to do some checking on the path for junction attacks this only seems to be at creation time not when it’s deleting the task file. Therefore you can mount a junction attack against the deletion process which allows you to delete any file or directory on the system which local system can delete. To delete directories you’d have to use a more advanced trick than just a directory junction as you’d need to the point the task file to name::$INDEX_ALLOCATION but it will work. 

The ability to deletes files is sufficient in some cases to elevate privileges because of the behaviour of other system processes and default permissions. For example system files created in ProgramData generally have privileges which prevent a user from modifying or replacing files, but not from creating new ones. You could use the attack to delete existing files then replace with hardlinks to overwrite system files.

Proof of Concept:

The PoC demonstrates the vulnerability deleting an arbitrary file from the system. You need to modify the $filetodelete variable to select a different file to test other than c:\protected\test

1) Copy the PoC to a location on a local hard disk and rename the file’s extension to .ps1.
2) Enable powershell scripting for the current user, this doesn’t affect the actual exploit, it’s just to get powershell to execute the script. 
2) As a normal user execute the powershell PoC
3) The PoC should complete execution.

Expected Result:
The service should detect the directory junction and not delete the target file

Observed Result:
The target file is deleted

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.
 
poc.ps1
945 bytes Download
Project Member Comment 1 by forshaw@google.com, Jun 12 2015
Labels: Id-30431
Assigned MSRC case 30431
Project Member Comment 2 by forshaw@google.com, Sep 3 2015
Labels: -Id-30431 MSRC-30431
Project Member Comment 3 by forshaw@google.com, Sep 9 2015
Labels: Fixed-2015-Sep-08 CVE-2015-2525
Status: Fixed
Fixed in https://technet.microsoft.com/library/security/ms15-102
Project Member Comment 4 by forshaw@google.com, Sep 15 2015
Labels: -Restrict-View-Commit
Sign in to add a comment