timidri / puppet-meltdown

3 stars 6 forks source link

Variant 1 False Positives #12

Closed rychannel closed 6 years ago

rychannel commented 6 years ago

Looking for the KB patch installed is likely to show false positives with how Microsoft does its patches now. Since Microsoft patches are now cumulative, different KB numbers can be used that will also cover the issue.

For example, if the patch came out in January, and I applied the May patch bundle. The KB number for the May Patch bundle is what will appear as being installed, not the original patch KB

kreeuwijk commented 6 years ago

This issue cannot occur for the 'meltdown' fact, since the module does not look for a specific KB patch to be present. Instead, it uses Microsoft's official SpeculationControl add-in for PowerShell, which verifies if the system is patched for Spectre/Meltdown (regardless of the actual patch that was used).

The module only searches for a specific KB patch on WSUS/Windows Update if an admin uses the meltdown::windows_update task to patch a system. If the system is already patched, the KB patch will not be presented to the system by the update server, which is still the desired result.

One possible issue could be if the admin decides to only publish a subsequent cumulative patch on WSUS, and not the individual patch that the Task is looking for. However that could be fixed by either falling back to Windows Update, or publishing the KB patch on the WSUS server.

rychannel commented 6 years ago

It looks like searching for KB is literally the first thing its doing...

`
switch -Wildcard ((Get-WmiObject -class Win32_OperatingSystem).Caption) { 'Microsoft Windows Server 2008 Standard' { $hotfix = 'KB4090450' } 'Microsoft Windows Server 2008 Enterprise' { $hotfix = 'KB4090450' } 'Microsoft Windows Server 2008 Datacenter' { $hotfix = 'KB4090450' } 'Microsoft Windows Server 2008 R2' { $hotfix = 'KB4056897' } 'Microsoft Windows Server 2012 Standard' { $hotfix = 'KB4088877' } 'Microsoft Windows Server 2012 Datacenter' { $hotfix = 'KB4088877' } 'Microsoft Windows Server 2012 R2' { $hotfix = 'KB4056898' } 'Microsoft Windows Server 2016' { $hotfix = 'KB4056890' } 'Microsoft Windows Server, version 1709' { $hotfix = 'KB4056892' } }

if ($hotfix) {
    $arrCVE.Add('CVE-2017-5753', @{
        "CVE"              = "2017-5753"
        "description"      = "Spectre Variant 1"
        "vulnerable"       = if ([bool](Get-WmiObject -query 'select * from win32_quickfixengineering' | ? HotFixID -eq $hotfix)) {$False} else {$True}
        "info"             = @{
            "hotfix_installed" = [bool](Get-WmiObject -query 'select * from win32_quickfixengineering' | ? HotFixID -eq $hotfix)
        }
    })`
rychannel commented 6 years ago

With our patch management software it pulls the latest directly from Microsoft, we don't even use WSUS with our servers

rychannel commented 6 years ago

Also, it appears that speculationcontrol is only capable of checking for the variant 2 and 3

kreeuwijk commented 6 years ago

Actually, you are correct. I’ll go back and make sure we populate those facts from the SpeculationControl script instead.

kreeuwijk commented 6 years ago

Ah I remember now why we use the patch status for Variant 1. It’s indeed because the SpeculationControl script doesn’t provide the status of patching for this Variant. We’ll have a look at if there is a better method, or if the WMI does return true when the patch is installed via a cumulative update later on.

rychannel commented 6 years ago

I think Variant 1 will be difficult to track just because of Microsoft cumulative patching. The wannacry fact ran in to the same issue. Every month several KBs had to be added to the list.