AntiVirus (AV) products are still widely used on workstations and servers and provide a better level of protection against common malware. These products usually offer a range of interesting features such as fancy user interfaces (GUIs), firewall and network inspection functions or kernel mode drivers for self-protection, rootkit identification, etc.. One of the drawbacks of AV products is that at a certain point they need to be run with the highest privileges in order to perform all the different things that an AV product needs to perform to protect the underlying system against suspicious activity. A software that runs with the highest privileges is also an attractive target for attackers, as finding and exploiting a vulnerability in such software usually offers a high chance to elevate privileges from that of a standard user to a higher-level access (normally SYSTEM or root access, depending on the running operating system).
I was recently investigating the Windows version of an AV product from one of the “big” AV companies. Out of respect for the AV vendor, his name is not mentioned in this blog. I was specifically looking for bugs that would allow a privilege escalation attack to gain administrative access on the system. I started looking for basic flaws such as insecure file, directory or registry permissions. After some digging, the folder “C:\ProgramData\AV\AV for Endpoint\” caught my attention.
The ProgramData directory is normally used by applications to store specific data that can be used by processes or services belonging to the respective application. This folder has permissive DACLs ((Discretionary Access Control Lists) by default and therefore allows every user free access to it. These standard DACLs are prone to cause security bugs, especially if low privileged users can create files that are later used by a privileged process. In such a case, we could potentially inject arbitrary code, that would then be executed by the application process with higher privileges.
The AV’s Programdata folder (as well as further subfolders) was mainly used here for product updates. This means that the AV product temporarily saves all downloaded data in this directory before it starts copying it to the actual program folder of the main application, which was located at C:\Program Files\AV\AV for Endpoint. This task was performed by a process (update.exe) that runs as NT AUTHORITY\SYSTEM.
Looking at the DACL on the Programdata folder, we can see that the “BUILTIN\Users” group also has write permissions:
This is particularly interesting in that a privileged process (update.exe) is saving files in a directory that low privileged users can modify.
I started running Process Monitor to check the update process in detail. It turned out that all already existing files and subdirectories in the AV’s ProgramData folder were overwritten by the privileged process during the update. So I tried to abuse the small time window during an update to replace a legitimate downloaded DLL and EXE file with a malicious file containing the payload. Although the replaced file was successfully copied to C:\Program Files\AV\AV for Endpoint\, it was not executed. Apparently a digital certificate validation was made against the binary files of the AV product. This means that if the file’s signature could not be validated, the file was not loaded. This makes it harder to actually exploit the permissive access rights in the ProgramData folder.
Manipulation of INF Files
The AV product also stores downloaded INF files in the Programdata directory. An INF file is a text file that provides instructions for the Windows Setup and Device Installer Services (known as SetupAPI). These instructions are used by SetupAPI to install the driver on the underlying system. More information about INF files can be found via the following URL: https://github.com/MicrosoftDocs/windows-driver-docs/blob/staging/windows-driver-docs-pr/ifs/creating-an-inf-file-for-a-file-system-driver.md
INF files cannot be used to launch a user-mode application, however, we can take advantage of the CopyFiles directive in an INF file in order to execute our payload by the AV product. Please note that any unsigned binary will not be loaded, so we need to find a different way to solve the problem.
The following example shows an original INF file that has been downloaded from the AV product during an update:
The idea is to use the CopyFiles directive to replace the AV’s legitimate service binary. This approach bypasses the signature validation problem and also allows us to disable the AV on the system 🙂
This modified INF file ensures that the AV service binary avprotect.exe in the directory C:\Program Files\AV\AV for Endpoint\ is overwritten with our payload.exe.
update.exe is a service that runs with SYSTEM privileges. So our payload would also be executed with these privilege and allows us to successfully escalate our privileges. The payload I used simply creates a new user and drops it to the local administrators group (quite noisy when it comes to EDR, but this exploit is just an example). It would also be possible to weaponize a custom binary file in order to receive remote code execution running as SYSTEM.
The service is restarted during the update process and creates the new admin user on the system.
Conclusion
Security products often need to be run with the highest privileges. A vulnerability can therefore lead to a complete compromise of the system if it is successfully exploited. Insecure DACLs can be easily exploited by attackers to run malicious code, but are also easy to patch. AV vendors should be aware of such attacks and ensure that appropriate file an directory permissions are set for their software.