By Heimdall ISH

A new Zero Day vulnerability (still unpatched) was presented to the security world on November 22nd. 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 arbitrary file permissions. 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 use Windows Installer to elevate privileges by changing access to restricted system files. To explain how Naceri's proof of concept works, we first need 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 moments as acquisition and execution.

During acquisition, the installer follows the instructions in the msi file database and generates a step-by-step script to carry out 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 the temporary mitigation of this vulnerability, the author demonstrates how the installation orchestrated by the msi contained in his PoC should work (i.e. without the bug he discovered and employed):

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

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

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

The Config.Msi folder, shown in the top 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 revert the system to its pre-installation state. One of the tools needed for this is the rollback file, with a .rbf extension . This is a script that will guide the restoration of all the files that were deleted during the installation, whose backup is kept in Config.Msi. The following images show the process described by the author (creating an msi, followed by creating the files and folders in question).

Bug in the creation of the rollback file

A question may have arisen among more attentive readers: if the installer is responsible for creating the files in a directory, why is the InstallerFileTakeOver.exe process 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; therefore, this process, not PoC, should write the content of the executables in question.

This 0-day elevation of privileges 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 the arrow in the bottom left-hand corner with the message "lock notepad.exe". This is a deliberate action by PoC to cause the bug mentioned and the reason for its process interacting 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 use is this bug? The rollback file isn't just created where it shouldn't be; it's 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 an ordinary user, but this happens as SYSTEM.

Changing the permissions of the target file

We've reached 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 access to the rollback file by msiexec. The following entries, associated with InstallerFileTakeOver, are the name changes and symlink creations that make up the race condition. The second highlight shows a change to the same file that msiexec tried to access.

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

After running InstallerFileTakeOver.exe (the proof of concept), the elevation_service permissions 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 the 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 altered 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 executed 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 the proof of concept with an arbitrary file supplied as an argument results in the information contained in the target being lost. Example: when used against the system.ini file, it becomes 0 bytes after obtaining permissions. This behavior does not mean that this vulnerability is only used to delete files, as demonstrated by its use against the Edge elevation service.

Detection and mitigation

When reporting on this vulnerability, many sources associate it exclusively with the Microsoft Edge elevation service. This is not true. Although this executable was the target chosen by its author, the erroneous behavior of Windows Installer that allows elevation of privileges does not depend on the chosen target. Therefore, we do not advise detecting this 0day 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 an installation error due to SHARING VIOLATION (a condition required for the vulnerability to work). This error is indicated by the 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 contains the full path of the file involved in the sharing violation. This type of MsiInstaller error associated with unusual directories for installations (such as %TEMP%, in the case above) 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 has not been exploited.

To date, no updates or patches have been released to mitigate this vulnerability.