If an arbitrary file was deleted on behalf of the NT AUTHORITY\SYSTEM account, we are talking about a system hack and a denial of service incident.
This article discusses interesting techniques related to deleting arbitrary files and folders and other seemingly ineffective primitives of file system operation.
Difficulties with deleting arbitrary files
When deleting arbitrary files in Windows, there are two serious obstacles:
Most critical Windows files are blocked using DACL lists. The latter do not allow you to modify files even on behalf of the SYSTEM account. OS files mostly belong to the TrustedInstaller account, and only she can change them. (Exercise: Find critical Windows files that can still be deleted or overwritten on behalf of SYSTEM.)
It is not enough for an attacker to find a file that can be deleted on behalf of SYSTEM: a fail-open situation should occur when deleting (security degradation).
There is a third potential difficulty: some important system files will always be unavailable due to violation of the conditions of collective access.
In practice, it is very difficult to find a file whose deletion would make sense from the point of view of hacking the system and at the same time allowed it. If you search in the usual places, for example in directories C:\Windows , C:\Program Files or C:\Program Data, there is nothing suitable there. Previously, the operation of antivirus and other software was shown. However, the possibility of exploitation depends on the specific vulnerable behavior of programs.
There is a solution — in the Windows Installer
In March 2021, a vulnerability was reported by a researcher named Abdelhamid Naceri, also known as halov. The vulnerability consisted in deleting an arbitrary file through the User Profile service (User Profile) on behalf of the SYSTEM account. The message also mentioned a technique that allows you to use file deletion to elevate privileges (EoP) and run the command line on behalf of SYSTEM. The increase was achieved by deleting a file located in a very unexpected place.
Below is a simplified description of the Windows Installer service and the mentioned privilege escalation method.
The Windows Installer service is responsible for installing applications. The author of the application creates a file with the .msi extension. This is a database with a description of the changes required to install the application: which folders need to be created, which files need to be copied, which registry keys need to be changed, which special actions need to be performed, and so on.
At the same time, the Windows Installer service implements transaction management — to ensure the integrity of the system in the event of an installation failure and for a neat rollback of the installation. When the Windows Installer makes a change to the system, it creates a record about it every time. And when the installer overwrites a file in the system with a newer version from the package being installed, it saves a copy of the old version. Records allow the service to return the system to its original state when the installation is rolled back. In the simplest scenario, records are stored in a folder C:\Config.Msi .
During installation, the Windows Installer service creates a folder C:\Config .Msi and writes information there to roll back changes. When changes are made to the system during installation, the service writes information about them each time to a file with the .rbs extension (rollback script) in the folder C:\Config.Msi . Also, when overwriting an older version of a file with a newer one, the installer saves a copy of the source file in the folder C:\Config.Msi . Copies are assigned the extension .rbf (rollback file). If you need to roll back an incomplete installation, the installer service accesses the .rbs and .rbf files and uses them to return the system to its original state.
It is important to protect this mechanism from outside interference. If an attacker is able to modify the .rbs and .rbf files before reading them, then the system can be arbitrarily changed during the rollback. Therefore, the Windows installer uses DACL to set strict restrictions on access to files in the folder C:\Config.Msi .
However, there is a loophole. An attacker can use a vulnerability that allows deleting arbitrary folders to completely delete a folder C:\Config .Msi immediately after its creation by the Windows installer. The attacker can then recreate the folder C:\Config .Msi with reduced DACL access rights (ordinary users are allowed to create folders in the root directory C:\). And when the Windows installer creates the rollback files of the changes in C:\Config .Msi, the criminal will be able to replace the folder C:\Config .Msi is its fake version with modified .rbs and .rbf files. Then during the rollback, the Windows installer will make arbitrary changes to the system in accordance with malicious scenarios.
In this case, the only necessary primitive of operation is the ability to delete an empty folder. The primitives of moving or renaming a folder will also work.