The revelations made by researcher SandboxEscaper regarding Microsoft 0Day vulnerability did turn out to be a little controversial given the fact that the disclosure was made public through twitter. However, it seems that a Micropatch has been released by 0Patch Team. What needs to be taken cognizance of is that the researchers provided a quick fix before Microsoft. Nevertheless, it is speculated that Microsoft might release its updates which will be used to mitigate this 0Day vulnerability.
A Close Look at the Proof of Concept Published by SandboxEscaper
The Proof-of-concept (POC) published by researcher SandboxEscaper points out towards the fact that the vulnerability allows an executable file to be replaced by a non-admin user further enabling privilege escalation. In the PoC, the researcher creates an UpdateTask.job
file in the folder %SystemRoot%\Tasks.
This file is hard linked to PrintConfig.dll
file which eventually becomes a file that can be modified by the user. Fundamentally the flaw exists in the Advanced Local Procedure Call (ALPC) which has the capability to externally access Task Scheduler’s SchRpcSetSecurity method.
Here in the SchRpcSetSecurity method a security descriptor file is setup that contains the security related information of the object that needs to be secured. The security descriptor has an in-built capability to allow or deny access control based on the configured discretionary access control list (DACL) and the Security Identifier (SIDs).
What Caught the Attention of Researcher Sandbox Escaper?
According to the researchers at 0Patch, “SandboxEscaper noticed that the SchRpcSetSecurity method fails to impersonate the requesting client when setting the security descriptor”.
In the above statement made by 0Patch, it is evident that the failure to impersonate the client leads to obtaining unauthorized access to information on the system.
Also Read: Researcher Publishes Windows Zero-day Vulnerability on Twitter Violating Disclosure Policy
Analyzing How did the Researcher’s Find a Quick Fix
In order to develop a quick fix the researchers viewed the behavior of the UpdateTask.job
file in a tool called ‘’process monitor’’. On having a close look at the call s tack, it was found that a call is made by schedsvc.dll to taskcomp.dll
and it finally ends up with a call to kernel’s NtSetSecurityObject
(See figure below).
In the figure below, the orange block in the middle shows a call from schedsvc.dll
that happens in function to
taskcomp.dll
RpcServer::SetSecurity
What the researchers noticed is that impersonation (which prevents a client from obtaining unauthorized access to the system) happens after the call that sets file permissions (see the lowest block in figure 2).
A Work Around Formulated that Failed
A work around was formulated to ensure that the impersonation happens before the call that sets file permission. While implementing this process it was observed that there are two calls that sets file permission and both were in function RpcServer::SetSecurity
This is seen as a possible fallback mechanism meant to make sure that if the first file permission call fails then the second one comes to the rescue. It was finally concluded that the second call does happen but still without impersonation – now this was a problem that needed to be dealt with. .
Finally a Work Around Deemed Successful!
It was pretty evident from the failed implementation that the two calls – the first one identified as RpcRevertToSelf
and the second one the offending call happened after the impersonation.
This prompted the researchers to take away the RpcRevertToSelf
call and then put it right back to the framework after the offending call. After initiating this subtle tweak in the calls that sets file permission, the micro patch did work!
Interested readers may view the source code here and the micropatch can be downloaded here.
Find the loopholes in your security. Contact us for Vulnerability Assessment and Penetration Testing.