Since August 2018, the expert already revealed other four Windows
The new zero-day was disclosed a week after Microsoft as released its monthly Patch Tuesday Security updates.
Like the Windows zero-day disclosed in August, this new issue affects Microsoft Windows Task Scheduler.
SandboxEscaper demonstrated that is possible to trigger the Windows zero-day by using malformed legacy tasks (.JOB format) and importing them in the Task Scheduler utility. and they can still be added to newer versions of the operating system.
Every JOB file is imported by the Task Scheduler with arbitrary DACL (discretionary access control list) control rights.
The experts pointed out that in the absence of the DACL, the system grants any user full access to the file.
There are two folders for tasks,
In the old days (i.e windows xp) tasks would be placed in c:\windows\tasks in the “.job” fileformat.
The researcher explains that in order to trigger the flaw it is necessary to import legacy task files into the Task Scheduler on Windows 10. This is possible copying old .job files into c:\windows\tasks running a command using executables ‘schtasks.exe’ and ‘schedsvc.dll’ copied from the old system, it leads to a remote procedure call (RPC) to “_SchRpcRegisterTask.” This function allows registering a task with the server exposed by the Task Scheduler service.
“If on windows 10 you want to import a .job file into the task scheduler you have to copy your old .job files into c:\windows\tasks and run the following command using “schtasks.exe and schedsvc.dll” copied from the old system: “schtasks /change /TN “taskname” /RU username /RP password”
This will result in a call to the following RPC “_SchRpcRegisterTask”, which is exposed by the task scheduler service. (I assume that to trigger this bug you can just call into this function directly without using that schtasks.exe copied from windows xp.. but I am not great at reversing 🙁 )” wrote the expert.
“It starts out by impersonating the current user. But when it hits the following function:
int __stdcall tsched::SetJobFileSecurityByName(LPCWSTR StringSecurityDescriptor, const unsigned __int16 *, int, const unsigned __int16 *)
It starts impersonating itself (NT AUTHORITY\SYSTEM)! And then calls SetSecurityInfo on a
Summarizing, the expert discovered that even starting with limited privileges it is possible to get SYSTEM rights by invoking a specific function.
Dormann was able to reproduce the issue Recompiling the code on 64-bit Windows 10 and Windows Server 2016 and 2019, only on Windows 8 and 7 it was not possible reproduce it.
Unfortunately for Microsoft, the problems are not ended here, SandboxEscaper announced at least another four Windows zero-day vulnerabilities, Three local privilege escalation (LPE) issues leading to code execution and a sandbox escape.
SandboxEscaoer wants to sell the exploits for the above issue to non-western buyers and asks the Local Privilege Escalation bugs for at least 60,000 each.
3 LPEs (all gaining code exec as
“If any non-western people want to buy LPEs, let me know. (Windows LPE only, not doing any other research nor interested in doing so). Won’t sell for less then 60k for an LPE.”
“I don’t owe society a single thing. Just want to get rich and give you *** in the west the middlefinger.”
Since August, SandboxEscaper has publicly dropped exploits for two Windows zero-day vulnerabilities forcing Microsoft to quickly address them to avoid its users being targeted by hackers.
In October, SandboxEscaper released the proof-of-concept exploit code for Microsoft Data Sharing that allowed a low privileged user to delete critical system files from Windows systems.
In December, she published a proof-of-concept (PoC) code for a new Windows zero-day, it is the fourth she released this year.
Stay tuned …
(SecurityAffairs – SandboxEscaper, hacking)