by Mitja Kolsek, the 0patch Team
Update 12/21/2021: Microsoft provided an official fix for this issue on December 14. Our associated micropatches thus ceased being free and now require a PRO license.
Update 3/21/2022: Microsoft's fix for this issue turned out to be flawed. We ported our micropatches to all affected Windows versions and made them all FREE for everyone again.
In June 2021, security researcher Abdelhamid Naceri published a blog post about an "unpatched information disclosure" vulnerability in Windows. The post details the mechanics of the issue and its exploitation, allowing a non-admin Windows user to read arbitrary files even if they do not have permissions to do so. The exploit namely copies file(s) from a chosen location into a CAB archive that the user can then open and read.
Abdelhamid's blog post also provides the timeline of reporting the vulnerability to Microsoft through ZDI in October 2020, Microsoft assigning a CVE ID to the issue and allegedly planning to fix it in April 2021, and the latter not happening in April. Or June. Or July or August or September or October.
While we had noticed Abdelhamid's June disclosure, it didn't seem to be a critical enough issue for micropatching, as we generally don't patch information disclosure bugs.
In November, however, Abdelhamid pointed out that this - still unpatched - bug may not be just an information disclosure issue, but a local privilege escalation vulnerability. Namely, as HiveNightmare/SeriousSAM has taught us, an arbitrary file disclosure can* be upgraded to local privilege escalation if you know which files to take and what to do with them. We confirmed this by using the procedure described in this blog post by Raj Chandel in conjunction with Abdelhamid's bug - and being able to run code as local administrator.
(*) Two conditions need to be met in order for the local privilege escalation to work:
- System protection must be enabled on drive C, and at least one restore point created. Whether system protection is enabled or disabled by default depends on various parameters.
- At least one local administrator account must be enabled on the computer, or at least one "Administrators" group member's credentials cached
The vulnerable functionality resides under the "Access work or school" settings and can be triggered by clicking on "Export your management log files" and confirming by pressing "Export". At that point, the Device Management Enrollment Service is triggered, running as Local System. This service first copies some log files to the C:\ProgramData\Microsoft\MDMDiagnostics folder, and then packages them into a CAB file whereby they're temporarily copied to C:\Windows\Temp folder. The resulting CAB file is then stored in the C:\Users\Public\Public Documents\MDMDiagnostics folder, where the user can freely access it.
It is the copying to C:\Windows\Temp folder that is vulnerable. Namely, a local attacker can create a soft link (junction) there with a predictable file name that will be used in the above-described process, pointing to some file or folder they want to have copied to the CAB file. Since the Device Management Enrollment Service runs as Local System, it can read any system file that the attacker can't.
Abdelhamid's POC targets the kernel dump files in folder C:\Windows\LiveKernelReports to demonstrate the issue, while we used SAM, SECURITY and SYSTEM files from a restore point folder to achieve local privilege escalation.
The vulnerability has CVE-2021-24084 assigned, but we still consider it a "0day" as no official vendor fix is available.
Abdelhamid's blog post suggested that user impersonation during CAB file creation would resolve the issue. While we agree with that, we were concerned that might break some use cases and rather decided to check for the presence of junctions during CAB file creation.
The function we patched is CollectFileEntry inside mdmdiagnostics.dll. This is the function that copies files from C:\Windows\Temp folder into the CAB file, and can be tricked into reading some other files instead.
Our patch is placed immediately before the call to CopyFileW that opens the source file for copying, and uses the GetFinalPathNameByHandleW function to determine whether any junctions or other types of links are used in the path. If they are, our patch makes it look as it the CopyFileW call has failed, thereby silently bypassing the copying of any file that doesn't actually reside in C:\Windows\Temp.
Here is the IDA graph showing our applied patch (green code blocks are patch code; blue code block is a trampoline with the original code).
This micropatch was written for:
- Windows 10 v21H1 (32 & 64 bit) updated with November 2021 Updates
- Windows 10 v20H2 (32 & 64 bit) updated with November 2021 Updates
- Windows 10 v2004 (32 & 64 bit) updated with November 2021 Updates
- Windows 10 v1909 (32 & 64 bit) updated with November 2021 Updates
- Windows 10 v1903 (32 & 64 bit) updated with November 2021 Updates
- Windows 10 v1809 (32 & 64 bit) updated with May 2021 Updates