A walkthrough of the new Windows 0 day released on twitter

Recently, a new zero-day vulnerability was made public following a Tweet from @SandboxEscaper, who claimed to be frustrated with Microsoft and their bug submission process.

The tweet includes a Github link with a proof of concept of the process, where after some tries, we can see in the image below that it works like a charm, giving us SYSTEM privileges in any Windows machine. We tested it on an updated Windows 10 machine.

The vulnerability uses a process that writes job files and modifies their DACL’s into the “C:WindowsSystem32tasks” folder, but first checks if the job file already exists. The problem exists because this path is writable for many users, even Guest users, so a malicious user can use hard links to modify any system file into Windows, leading to a privilege escalation.

The proof of concept exploits this issue overwriting a DLL used by the XPS printer, so you can elevate to SYSTEM privileges when a print job starts. More specifically, it overwrites the 64bit version of the “PrintConfig.dll” DLL, hosted in “c:windowssystem32DriverStoreFileRepositoryAmd64PrintConfig.dll” folder. This means the code only works ”˜as is’ for 64bit systems. For x86 systems, you should change the path of the library, using the 32bit version, as well as change the payload used.

The proof of concept just executes a Notepad.exe process with SYSTEM privileges, but this scenario can be modified to execute other programs, such as having privileged remote access to a Windows System as shown below:

However, we should consider that the proof of concept just exploits one way to escalate privileges, but there should probably be other ways to do so.

When executed, the code creates the file “c:windowstasksUpdateTask.job”, so its presence could be useful as an Indicator of compromise.

During our investigation, we have seen that Cylance Protect detects the DLL injection process and puts the executable in quarantine.

As a workaround, we can avoid the exploitation of the vulnerability using the published code doing the actions listed below:

”¢ Removing the XPS driver to avoid the execution of the overwritten library. In powershell: Remove-Printer -Name “Microsoft XPS Document Writer”

Ӣ Restricting write privileges to non-administrative users in the system to C:WindowsTasks folder.

The following image shows how the second mitigation works. As write permissions are blocked for the Users group in Tasks folder, the exploit runs but can’t create task, so it does not spawn the elevated process under spoolsv.exe.

We should consider this kind of mitigations as something temporary until an official Windows patch is released. As an example, we could automatically distribute this workaround using a GPO and, when the patched is applied, remove it.

As a detection mechanism, we can enable the file system audit into the folder “C:WindowsTasks” and monitor the Windows event 4664, triggered every time a hard link is created, as shown in the following image.

For more information, follow the link.