By Heimdall ISH

A new Zero Day vulnerability (as yet unpatched) was introduced to the security universe on November 22. Mistakenly classified in the news as a bypass of CVE-2021-41379, this is actually a new variant discovered by the same author of the original vulnerability, Abdelhamid Naceri.

The PoC(proof of concept) released by Naceri, InstallerFileTakeOver.exe, relies on a Windows Installer bug to change permissions on arbitrary files. This anomalous behavior is directed at the Microsoft Edge update privilege elevation service (MicrosoftEdgeElevationService), resulting in the elevation of privileges to SYSTEM.

How Windows Installer Works

Both CVE-2021-41379 and this 0 day vulnerability take advantage of Windows Installer to elevate privileges by changing access to restricted system files. To explain how Naceri's proof of concept works, it is first necessary to explain how Windows Installer works. The Windows Installer consumesinstallation packages, which contain instructions for the steps of the installation process in a database; these packages have the extension .msi. Microsoft's documentation categorizes these two times as acquisition and execution.

During the acquisition, the installer follows the instructions in the msi file database and generates a step-by-step script to perform the installation process. During the execution phase, this script is provided to a process with elevated privileges, which executes it to perform the installation on the system.

In his documentation for temporary mitigation of this vulnerability, the author demonstrates how the msi orchestrated installation contained in his PoC should work (i.e. without the bug he discovered and employed):

In short, PoC creates an installation package (.msi file), which will be responsible for:

- Create in the target directory the files @AppHelpToast.png, splwow64.exe and the folder "microsoft
plz";

- Create notepad.exe inside the "microsoft plz" folder.

The Config.Msi folder, shown in the upper left corner of the image, is a system folder that exists in the root of C:³.

This folder keeps backups of files during an installation process. If the process is interrupted for any reason, this location contains everything needed to roll back the system to its pre-installation state. One of the tools needed for this is the rollback file, extension .rbf. This is a script that will guide you in restoring all the files that were deleted during the installation, which are backed up in Config.Msi. The following screenshots demonstrate the process described by the author (creation of a msi, followed by the creation of the files and folders in question).

Bug in rollback file creation

A doubt may have arisen in the more attentive readers: if the installer is responsible for creating the files in a directory, why is the process InstallerFileTakeOver.exe messing with notepad.exe? The installation packages run in session 0 (reserved for services and other processes run by the SYSTEM user) via msiexec.exe, so this process, not PoC, should write the contents of the executables in question.

The elevation of privileges for this 0 day is based on a bug that occurs when the installation package tries to access a file that is locked for sharing.

This situation results in the .rbf file being created outside the Config.Msi directory. This is illustrated by the researcher in the following diagram:

Notice in the bottom left corner the arrow with the message "lock notepad.exe". This is a purposeful action by PoC to cause the mentioned bug and the reason for your process to interact with a file that the installation package wants to read. There is a specific function for this in the proof-of-concept code:

But what is the use of this bug? The rollback file is not only created where it shouldn't be; it is created without impersonation. Impersonation is the ability to perform an action with credentials other than those held by the process. The correct thing would be for msiexec.exe to write to the target directory with the permissions of a normal user, but this occurs as SYSTEM.

Changing permissions on the target file

We come to the last part of the proof of concept, a race condition. As soon as the .rbf file is created in the wrong place, the InstallerFileTakeOver.exe process will be alerted.

The first highlight is the attempted rollback file access by msiexec. The following entries, associated with InstallerFileTakeOver, are the name changes and symbolic link creations that constitute the run condition. The second highlight shows a change in the same file that msiexec attempted to access.

The practical effect is to change the permissions of the target file, demonstrated below:

After running InstallerFileTakeOver.exe (the proof of concept), the permissions of elevation_service have changed. The user who performed the action (DESKTOP-RP7H2UN\dodo) now has full permission to the file in question, as shown by (F)5.

This new access is used by the author to overwrite such an executable, as shown in the following actions:

This change is the final part of the proof of concept. The new elevation_service will be responsible for opening an elevated command prompt, completing the elevation of privileges:

It is interesting to note that the changed elevation_service has the same icon as the PoC executable. Its detection by antivirus engines is also high, as shown below:

You can confirm the effectiveness of the proof of concept with a simple whoami command at the generated prompt:

Limitations

The proof of concept can only be applied to files that are not in use at the time of its execution. If it is run without arguments, the target is the Microsoft Edge elevation service. The PoC code has a routine that confirms that this service is not running:

Note that the code on the right looks for the return ERROR_SERVICE_DOES_NOT_EXIST as confirmation that the target is not running. If an argument is supplied (in the form of a file for which the user wants to receive full permissions), the target cannot be in use either. In our tests, using proof of concept with an arbitrary file provided as argument results in the loss of information contained in the target. Example: When used against the file system.ini, the file contains 0 bytes after permissions have been granted. This behavior does not mean that this vulnerability is only for deleting files, as demonstrated by its use against the Edge elevation service.

Detection and mitigation

In reporting this vulnerability, many sources associate it exclusively with the Microsoft Edge lift service. This is not true. Although such an executable was the chosen target by its author, the erroneous Windows Installer behavior that allows elevation of privileges does not depend on the chosen target. Thus, we do not advise that detection of this 0 day be based on interactions with elevate_service.exe.

Similarly, the community has produced YARA detection rules based on PoC components, such as the test pkg.msi file. This detection model is also unreliable, since component names are easily changed.

A more robust indicator, also pointed out by Rapid7, is the event ID 1033 in the Application logs. It can be used to find times when MsiInstaller produced a SHARING VIOLATION installation error (condition required for the vulnerability to work). This error is indicated by code 1603. Similarly, event ID 11306 carries the error message itself. An example is provided below:

Error 1306. Another application has exclusive access to the file
'C:\Users\dodo\AppData\Local\Temp{1391479E-FCA4-4BB0-BA7D-BBE51017C60B}\microsoft
plz\notepad.exe'. Please shut down all other applications, then click "Retry".

Note that the error message gives the full path to the file involved in the share violation. This type of MsiInstaller error associated with unusual directories for installations (such as %TEMP% in the above case) is an indicator of possible exploitation of this vulnerability.

Remember that the proof of concept has a routine that deletes all executables and folders that were created during its execution. Thus, not finding the files outlined in the error is not an indicator that the flaw was not exploited.

So far no updates or patches have been released that mitigate this vulnerability.