|
|
Windows: Task Scheduler S4U Logon Elevation of Privilege | |||||
| Project Member Reported by forshaw@google.com, Nov 5 2014 | Back to list | |||||
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.
Project Member
Comment 1
by
forshaw@google.com,
Nov 5 2014
,
Nov 11 2014
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/windows/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.
,
Nov 28 2014
,
Jan 16 2015
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.
,
Jan 16 2015
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.
,
Jan 17 2015
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.
,
Jan 17 2015
@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.
,
Jan 19 2015
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!
,
Feb 18 2015
On Win8.1, with "Always Notify" even Task Manager requires a UAC prompt! |
||||||
| ► Sign in to add a comment | ||||||
