Windows: Task Scheduler S4U Logon Elevation of Privilege

[GoogleCodeExporter]

Windows: Task Scheduler S4U Logon Elevation of Privilege
Platform: Windows 8.1 Update 32/64 bit (7 not tested)
Class: Elevation of Privilege

The windows task scheduler allows a split token administrator to register a 
task which runs as a batch job from a limited privilege context. This doesn't 
require a user's password to accomplish as the task will be run 
non-interactively and so doesn't need access to the password in order to access 
remote resources. Due to the way that batch logons work in the latest versions 
of Windows for a split token admin user this actually creates the fully 
privileged token to execute the task under.

This can be exploited by malicious code to bypass UAC prompts by registering 
one of these tasks then executing it. It will run arbitrary code with the 
user's full token leading to elevation of privilege. If you specify in the task 
a TaskLevel of HighestAvailable the registration will fail with an access 
denied error. However even though the RunLevel is LeastPrivilege the S4U logon 
still results in a full token. 

Note: this seems to be an issue with UAC and how the task scheduler handles 
batch logon tasks. Therefore it might not be considered bulletin class. This is 
being disclosed due to how trivial it is to exploit if a user is running as a 
split token administrator. It might also be symptomatic of a deeper issue.

Provided is a PoC which exploits the issue on Windows 8.1 update. There are two 
files, a powershell script and a template task XML file. To reproduce execute 
the following steps:

1) Login as a split token admin with UAC enabled (doesn't matter to what prompt 
level, this works will full prompting). Start powershell under the low 
privileged token.
2) Enable script support in powershell by executing the command: 
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Unrestricted. This has 
nothing to do with the exploit, it's only to allow the execution of the script. 
3) Execute elevate_task_scheduler.ps1
4) It should print "Successfully run as admin" which indicates the task was 
able to write hello.txt to the Windows folder.

Expected result: 
The registration of the task should fail or at least not execute with admin 
privileges.

Observed result:
The task executes with administrator privileges and writes a file to the 
windows directory. 

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.

Original issue reported on code.google.com by fors...@google.com on 5 Nov 2014 at 5:33

Attachments:

• scheduled_task.zip

[GoogleCodeExporter]

Original comment by fors...@google.com on 5 Nov 2014 at 10:05

• Added labels: MSRC-20968

[GoogleCodeExporter]

Additional information based on some further analysis. It seems in part to be 
the fault of the Unified Background Process Manager, I've tested on Windows 7 
and it doesn't exhibit the behaviour. On 8.1 it goes through the UBPM where as 
Win7 doesn't. Another thing is Metasploit have a working exploit for this issue 
ready to go 
(https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/win
dows/local/s4u_persistence.rb) they presumably don't know it has different 
behaviour on Windows 8.1. It looks to be a module to get persistence at the 
limited privileges. 

Original comment by fors...@google.com on 11 Nov 2014 at 2:38

[GoogleCodeExporter]

Original comment by fors...@google.com on 28 Nov 2014 at 9:23

[GoogleCodeExporter]

Correspondance Date: 16 Jan 2015

< Microsoft have indicates that they do not consider this issue meets the bar 
for a security bulletin. It is as expected a UAC bypass which isn't a security 
boundary. 

Original comment by fors...@google.com on 16 Jan 2015 at 8:02

[GoogleCodeExporter]

While this issue is indeed a UAC bypass it's a regression from Windows 7 and 
works even when UAC is set to the highest level. The only mitigation for this 
issue is to not run as a split token admin.

Therefore marking as WontFix and removing view restriction.

Original comment by fors...@google.com on 16 Jan 2015 at 8:05

• Changed state: WontFix
• Added labels: PublicOn-2015-Jan-16
• Removed labels: Restrict-View-Commit

[GoogleCodeExporter]

Is anyone able to clarify why 118 (CVE-2015-0002), a UAC bypass, was 
significant enough to get a CVSS score of 7.2, Microsoft to create a bulletin, 
and when full disclosure occurred - MS felt it endangered users enough to 
publicly complain.  Yet this vulnerability (156), also a UAC bypass, gets the 
complete opposite response.

Leaving aside the contentious issue of the disclosure process; I can't 
understand how this vulnerability is being treated so differently from 118, 
when the impact on users appears so similar.

If UAC isn't a security boundary (as Microsoft have long claimed), then I'd 
agree that UAC bypasses don't qualify as security vulnerabilities.  
Unfortunately, it's hard to see what UAC is; if not a security boundary; and 
MS's past response when presented with bypasses (118 included) makes a 
compelling case that it is.

Original comment by mountainstormuk on 17 Jan 2015 at 9:00

[GoogleCodeExporter]

@mountainstormuk, Well the difference is 118 was not a UAC bypass, it only used 
UAC as demonstration for the proof of concept. This saved time when developing 
a suitable PoC to give to Microsoft so that they can best assess the security 
implications. As I've noted in the bug report (and others also noted) it was a 
more serious EoP than that. I personally have developed a working exploit to 
escalate to system privileges from a non-admin user. Microsoft recognized the 
distinction between the PoC and the exploitability and fixed it as a security 
issue. 

In this case the bug is 100% UAC related, if you were not running as a split 
token administrator then this attack would not allow you to elevate privileges. 
Microsoft have effectively abandoned any hope of fixing UAC to make it a 
security boundary so any issue which is related to it (such as integrity 
levels, admin approval mode, secure desktop etc.) will only rarely be fixed if 
they have an obvious knock on effect or can be accessed from a normal user 
account. The fact that this is a regression from Windows 7 just means that it 
might be put in the general bug fix queue and _might_ make it in to the next 
major version of Windows. I've not tested Windows 10 TP to see if that's the 
case. That said if I find issues in UAC I still provide Microsoft a heads up on 
the issue in case they either determine it's more serious than I realize or 
feel it's easy enough to fix. 

As stated, the only mitigation is to not run as a split-token administrator 
ever. Perhaps Microsoft should be doing more to ensure people do this, through 
education or changes to the install defaults. With this bug split-token admin 
on Windows 8.1 Update has zero value from a security perspective. 

Thanks,

James.

Original comment by fors...@google.com on 17 Jan 2015 at 9:23

[GoogleCodeExporter]

FYI tested on Win10TP (build 9879) with UAC set to always notify.  Elevation of 
privlege was successful.

My 2c: You're already an admin, it's not letting you do anything you couldn't 
already do, it's just not giving you a heads up (UAC warning).

Good work guys!

Original comment by CraigI...@gmail.com on 19 Jan 2015 at 4:18

[GoogleCodeExporter]

On Win8.1, with "Always Notify" even Task Manager requires a UAC prompt!

Original comment by yuhongba...@hotmail.com on 18 Feb 2015 at 10:55