How to Fix CVE-2018-0986 [ Microsoft Malware Protection Engine Remote Code Execution Vulnerability] from BigFix,? I dont see any Fixlet for it
Itâs funny, we are told to turn off windows update for Bigfix but when we need fixes for things like your CVE and one of the later ones, CVE-2021-42298, nothing but crickets from HCL.
The Malware Protection Engine updates come when running Windows Update but that negates the usefulness of Bigfix.
These updates must be published by HCL and maintained if we are going to continue to see value in the product.
A newer version based upon this will be published in the next publish of Updates for Windows Applications Extended: https://github.com/jgstew/bigfix-content/blob/main/fixlet/Update%20Windows%20Defender%20Virus%20Definitions%20-%20v1.247.1082.0%20-%2064bit%20-%20Windows.bes
I donât think I ever tested this fully, but this SHOULD trigger Windows Defender to update itself regardless of Windows Update: https://github.com/jgstew/bigfix-content/blob/main/fixlet/Update%20Online%20Windows%20Defender%20Virus%20Definitions%20-%20Windows.bes
We already had automated builds of this content in place, but I had not tested it on Windows Server until now.
What we need is dll updates. That is what vulnerability software like Tenable and Qualys are flagging. Even uninstalling defender using âUninstall-WindowsFeature -Name Windows-Defenderâ does not work. The dllâs are still left behind.
The virus definitions include the DLL for the engine.
We donât use defender like a lot of other companies that use 3rd party anti-virus/malware software do. Those 3rd party tools usually shut off defender or they ask you to remove it.
I canât say I have tested the updates in this configuration. Iâm not even sure if Windows Update would update them in this configuration either.
If defender is disabled, then this seems like a false positive, because if the software is never run, then I donât think it could actually be exploited.
This might help.
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-42298
Read under the heading âMicrosoft Defender is disabled in my environment, why are vulnerability scanners showing that I am vulnerable to this issue?â
I may need to have our vulnerability team speak to our vendor about this.
Seems like the vendor just needs to read the âVulnerability scanners are looking for specific binaries and version numbers on devices. Microsoft Defender files are still on disk even when disabled. Systems that have disabled Microsoft Defender are not in an exploitable state.â part.
It is technically a false positive.
That said, we should have content published by the end of this week to update the virus definitions (which should include the engine DLL) with BigFix⌠that said, Iâm not sure if it will work when it is disabled. Please test it on a single machine and let us know if it works when Defender is disabled or not.
You can try this on your end on a lab machine.
Run in elevated Powershell console
Uninstall-WindowsFeature -Name Windows-Defender
Boot machine (it will tell you to)
After it comes back up
Get-WindowsFeature -Name Windows-Defender
It should show as Available.
Run your Bigfix update.
Verify that the Microsoft Malware Protection Engine version is 1.1.18700.3 or later. The dll is called mpengine.dll
I donât know that I will have time before the content is published.
I am curious if this would work when disabled as well: bigfix-content/fixlet/Update Online Windows Defender Virus Definitions - Windows.bes at main ¡ jgstew/bigfix-content ¡ GitHub
Do you have an ETA on published date?
Itâs going through our QA & review system, should be public by end of week
Whatâs even more interesting is once you uninstall defender, the only evidence of the mpengine.dll is located off of C:\Windows\WinSxS\amd64_windows-defender-am-engine_31bf3856ad364e35*
So, I believe our vulnerability tool is detecting a false positive.
We just published the Defender update, Content Modification: Updates for Windows Applications Extended published 2023-07-26
Currently we test that Defender is enabled to begin with, so it will probably be not relevant by default on your machines. Weâre not sure the update could even deploy with Defender disabled and prefer to err on the side of caution.
You could custom-copy the fixlet and remove Relevance 6 that checks the protection has not been disabled, and see whether the update clears your false-positive status. If the update can run on systems with Defender disabled, we could tweak that relevance.
Thanks for pointing this out. I actually forgot that check was there.
Does this content update mpengine.dll?
Good question! The documentation around these Defender updates is sorely lacking. I also saw our Patch team published a couple of new fixlets in âPatches for Windowsâ -
405262302 4052623: Update for Microsoft Defender antimalware platform - Microsoft Defender Antivirus - KB4052623
405262303 4052623: Update for Microsoft Defender antimalware platform - Microsoft Defender Antivirus - KB4052623 (x64)
âŚin addition to the one we were just discussing from âUpdates for Windows Applications Extendedâ -
5603601 Update: Windows Defender Virus Definitions v1.393.1315.0 - Windows (x64)
TL;DR - I suggest running both fixlets, the fixlet in âPatches for Windowsâ updates the Defender service binaries but not definitions or threat intelligence; the update in 'Updates for Windows Applications Extended" updates the definitions and thread intelligence DLL but not the Defender service binary.
These fixlets use different downloads, and it wasnât clear where the overlaps are.
I set up a test, Win10 1909 un-patched instance to try them out.
I used a simple command line to find every instance of mpengine.dll on the disk to compare them before-and-after
dir /s /b mpengine.dll > \temp\mpengine_versions.txt
Before running any updates
q: unique values of (it as string as version) of values whose(name of it = "ASSignatureVersion" OR name of it = "AVSignatureVersion") of keys "Signature Updates" of (keys "Microsoft Antimalware" of it ; keys "Windows Defender" of it) of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft" of native registry
A: 1.285.74.0
q: image paths of service whose (display name of it as lowercase contains "defender antivirus service" or display name of it as lowercase contains "windows defender service")
A: "C:\Program Files (x86)\Windows Defender\MsMpEng.exe"
q: version of file "C:\Program Files\Windows Defender\MsMpEng.exe"
A: 4.18.1902.5
q: (version of it, pathname of it) of native files (lines of file "c:\temp\mpengine_versions.txt")
A: 1.1.15600.4, C:\ProgramData\Microsoft\Windows Defender\Definition Updates\Default\MpEngine.dll
A: 1.1.15600.4, C:\Users\All Users\Microsoft\Windows Defender\Definition Updates\Default\MpEngine.dll
A: 1.1.15600.4, C:\Windows\WinSxS\amd64_windows-defender-am-engine_31bf3856ad364e35_10.0.18362.1_none_d188cb97337971c6\MpEngine.dll
(side note - I may have found a bug in the âimage path of serviceâ inspector, weâre looking into that. Where I retrieve the verision of MsMpEng.exe above, I manipulated the path manually. For this particular fixlet it wonât matter - the update actually moves the image path of the MsMpEng.exe to a new path and it will not hit the edge-case that may be an inspector bug.)
Running the update from âPatches for Windowsâ - relocates MsMpEng.exe from \Program Files to \ProgramData, restarts the service, and updates the MsMpEng.exe binary. It does not update or add any mpengine.dll files, nor the signature versions
q: unique values of (it as string as version) of values whose(name of it = "ASSignatureVersion" OR name of it = "AVSignatureVersion") of keys "Signature Updates" of (keys "Microsoft Antimalware" of it ; keys "Windows Defender" of it) of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft" of native registry
A: 1.285.74.0
q: image paths of service whose (display name of it as lowercase contains "defender antivirus service" or display name of it as lowercase contains "windows defender service")
A: "C:\ProgramData\Microsoft\Windows Defender\platform\4.18.23050.9-0\MsMpEng.exe"
q: version of file "C:\ProgramData\Microsoft\Windows Defender\platform\4.18.23050.9-0\MsMpEng.exe"
A: 4.18.23050.9
q: (version of it, pathname of it) of native files (lines of file "c:\temp\mpengine_versions.txt")
A: 1.1.15600.4, C:\ProgramData\Microsoft\Windows Defender\Definition Updates\Default\MpEngine.dll
A: 1.1.15600.4, C:\Users\All Users\Microsoft\Windows Defender\Definition Updates\Default\MpEngine.dll
A: 1.1.15600.4, C:\Windows\WinSxS\amd64_windows-defender-am-engine_31bf3856ad364e35_10.0.18362.1_none_d188cb97337971c6\MpEngine.dll
Running the signature updates from âUpdates for Windows Applications Extendedâ updates the signature versions, and adds new instances of mpengine.dll with the newer versions. It does not update the MsMpEng.exe version or relocate the service to ProgramData:
q: unique values of (it as string as version) of values whose(name of it = "ASSignatureVersion" OR name of it = "AVSignatureVersion") of keys "Signature Updates" of (keys "Microsoft Antimalware" of it ; keys "Windows Defender" of it) of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft" of native registry
A: 1.393.1315.0
q: (version of it, pathname of it) of native files (lines of file "c:\temp\mpengine_versions.txt")
A: 1.1.15600.4, C:\ProgramData\Microsoft\Windows Defender\Definition Updates\Backup\mpengine.dll
A: 1.1.15600.4, C:\ProgramData\Microsoft\Windows Defender\Definition Updates\Default\MpEngine.dll
A: 1.1.23060.1005, C:\ProgramData\Microsoft\Windows Defender\Definition Updates\{2CB60B59-2884-4088-9245-1F04FBA247E5}\mpengine.dll
A: 1.1.15600.4, C:\Users\All Users\Microsoft\Windows Defender\Definition Updates\Backup\mpengine.dll
A: 1.1.15600.4, C:\Users\All Users\Microsoft\Windows Defender\Definition Updates\Default\MpEngine.dll
A: 1.1.23060.1005, C:\Users\All Users\Microsoft\Windows Defender\Definition Updates\{2CB60B59-2884-4088-9245-1F04FBA247E5}\mpengine.dll
A: 1.1.15600.4, C:\Windows\WinSxS\amd64_windows-defender-am-engine_31bf3856ad364e35_10.0.18362.1_none_d188cb97337971c6\MpEngine.dll
After running the definitions update from âPatches for Windows Applications Extendedâ, new versions of the DLL are present and appear to be used, but the update does not appear to remove the old DLL and it is kept in different locations. Iâm not sure whether your endpoint scanner will trigger a positive or negative in this case, whether itâs smart enough to check for which .dll is actually being used, choosing the current DLL among the several copies present.
My Win10 1909 does not have the Uninstall-WindowsFeature cmdlet. I did disable Defender using the Settings app, and Local Group Policy.
The update from âPatches for Windowsâ becomes non-relevant (as the Defender service is stopped). The update from âUpdates for Windows Applicationsâ remained Relevant, but fails to install with an error exit code from the installer
Command succeeded (Exit Code=-2147023291) wait __Download\mpam-fe-x64.exe -q (action:5551)
The updateplatform.amd64fre_aa7e29ece94fbaacd94a7f34896b3f9671a18d18.exe that the âPatches for Windowsâ fixlet downloads also fails with a similar exit code.
With Defender disabled, I donât expect either of these updates to work.
It seems like we need to fix the relevance to no longer be relevant when Windows Defender is not enabled.
Iâm not sure exactly what the best relevance for that is.
The one I recently switched it to is:
exists string values whose(it as trimmed string != "") of selects "AMRunningMode FROM MSFT_MpComputerStatus" of wmis "ROOT\Microsoft\Windows\Defender"
It seems like when it is disabled, no AMRunningMode
is reported.
This might be âmoreâ correct:
/* Check that Windows Defender is enabled: */ ( not exists (it as string as integer) whose(it = 1) of values "DisableAntiSpyware" of (keys "Microsoft Antimalware" of it ; keys "Windows Defender" of it) of (keys "HKLM\SOFTWARE\Microsoft" of it; keys "HKLM\SOFTWARE\Policies\Microsoft" of it) of native registry ) AND ( exists string values whose(it as trimmed string != "") of selects "AMRunningMode FROM MSFT_MpComputerStatus" of wmis "ROOT\Microsoft\Windows\Defender" )