Windows 0-day ALPC vulnerability in task scheduler

[German]Windows has an unpatched zero-day local privilege escalation vulnerability, which allows unprivileged users to extend rights to the SYSTEM level. Here is some information about the facts. Addendum: There seems to be a workaround to mitigate the vulnerability. And there is a first 0patch test candidate.

First notes on Twitter

The first messages reached me the night via Twitter (see here), whereby the Twitter channel of the person @sandboxescapter, who originally posted it, has been deleted in the meantime. The original tweet read as follows:

Here is the alpc bug as 0day: https://t.co/m1T3wDSvPX I don't fucking care about life anymore. Neither do I ever again want to submit to MSFT anyway. Fuck all of this shit.

— SandboxEscaper (@SandboxEscaper) August 27, 2018

Note: A German blog reader pointed to this reddit.com thread where some attempt was made, to sell 0-day-exploits. There the name SandboxEscaper also occurs on deleted posts.

Kevin Beaumont (@GossiTheDog) has shared later this information within the following Tweet:

The account got pulled, but the PoC is at https://t.co/JqX4ueHorZ

— Kevin Beaumont (@GossiTheDog) 28. August 2018

and linked to GitHub, where a Proof of Concept may be found. CERT/CC vulnerability analyst Will Dormann verified the error. In a Tweet, he confirmed the vulnerability.

I've confirmed that this works well in a fully-patched 64-bit Windows 10 system.
LPE right to SYSTEM! https://t.co/My1IevbWbz

— Will Dormann (@wdormann) 27. August 2018

It is a Local Privilege Escalation vulnerability that allows rights to be extended to SYSTEM. Will Dormann then issued a CERT warning (VU#906424 Microsoft Windows task scheduler contains a local privilege escalation vulnerability in the ALPC interface).

Vulnerability in Task-Scheduler

The zero-day vulnerability is in the Windows task scheduler in the ALPC interface. The abbreviation ALPC stands for Advanced Local Procedure Call. The Microsoft Windows Task Scheduler contains a vulnerability in ALPC call handling that allows a local user to gain SYSTEM privileges.

Limited usability?

Addendum: However, the vulnerability requires that the account has the permissions to create a hardlink (which, in my opinion, only works with administrator accounts). Quote from the description of the PoC (Proof of Concept).

Tasks created by the task scheduler will create a corresponding folder/file in c:\windows\system32\tasks. This function seems to be designed to write the DACL of tasks located there, and will do so while impersonating. However, for some reason it will also check if a .job file exists under c:\windows\tasks and try to set the DACL while not impersonating. Since a user, and even a user belonging to the guests group can create files in this folder, we can simply create a hardlink to another file (all we need is read access). Because of the hardlink, we can let the task scheduler write an arbitrary DACL (see second parameter of SchRpcSetSecurity) to a file of our choosing.

So any file that we have read access over as a user and that system has the write DACL permission for, we can pivot into full control and overwrite it.

Even read access to the folder c:\windows\system32\tasks is not possible for a standard users (just explicitly tested again). However, since some users work under administrator accounts, the hardlinks should be created. Then SYSTEM rights could be obtained. For a standard account with limited rights this does not works also (even because of the lack of rights to create hardlinks or to access the tasks folder).

The author of the PoC writes that the charm of the exploit is that you can now manipulate a lot of files that normally only the trusted installer has access to. In fact, this is (under normal circumstances) only possible under administrator accounts if you take over the file's ownership.

I tried to use the commands, the author of the PoC demonstrated within it's video. Maybe I made a fault, but I wasn't able to grant a process (notebook.exe for instance) SYSTEM rights under a standard user account. From a standard user account I'm also wasn't able to read the folder c:\windows\system32\tasks. But there are comments within my German blog, that this may be bypassed in certain scenarios (hardlink to a file in this folder for instance, that may be created w/o admin credentials). But at this point I stopped further investigations – hadn't the time for that.

Luckily this means that the previously unpatched vulnerability can only be exploited locally, but not remotely via the Internet, and only. However, this opens a familiar attack vector: If an attacker can trick a user (with admin rights) into downloading and running malware from the Internet, the malware can use the exploit to extend the rights (from the local administrator context) to system privileges.

Addendum: It seems there is a workaround

I startet a discussion at German site administrator.de. Another administrator has been able to use the PoC to grant System privileges to Windows notepad.exe from a standard user accound on one machine. On another machine he failed (like me, I tested it on a W7 machine). But the more interesting fact was, that this guy found a kind of workaround to mitigate the vulnerability. He changed the ACL to withdraw write privileges to:

c:\windows\system32\tasks

Afterward the PoC exploit won't work anymore. Currently there is another thread (also in German) where other administrators discusses possible side effects.

Addendum 21: 0patch test candidate

I've blogged about the people from 0patch several times within my German blog (here, here, here). The people at 0patch People are developing micro patches that close vulnerabilities that have not (yet) been closed by software vendors. To do this, a special patch agent must be installed, which then loads the micropatches when the application is started.

Okay people, 24 hours after the 0day was published we have a micropatch candidate for @SandboxEscaper's LPE in Task Scheduler. As you can see, scheduler's access to user-controlled hardlink is impersonating the user and gets ACCESS DENIED. pic.twitter.com/3kHcXdY42H

— 0patch (@0patch) 28. August 2018

The team from 0patch has announded within the above tweet, that a micropatch candidate for the vulnerability has been available. If it's rather important, it's possible to contact the team for further assistance (I haven't experiences with 0patch solutions).

Microsoft plans a fix for September patchday

The Register has asked Microsoft for a statement. A Microsoft spokesman replied it will "proactively update impacted advices as soon as possible". The spokesman referred to the schedule for the update on patch Tuesday. Let's see if there's a patch in September 2018. In the meantime, several articles have appeared here, here and here. Addendum: ZDnet.com has also an article with a statement from Microsoft.