MECM Baseline: Check for GRUB vulnerability Windows 10

We needed to check for the GRUB vulnerability on our Windows 10 devices.

See advisory below:

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200011

We have a few thousand devices to check, so checking manually was going to be a issue, we decided to use MECM baseline to run a script to check for devices that had the issue.

Microsoft give the below command in the advisory to check if the issue exist

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Microsoft Corporation UEFI CA 2011’

If this command returns a true value the device is vulnerable.

To use the command in a baseline we used the try / catch in PowerShell to get a compliance response as the above command is a terminating error and wont return a result other wise.

try{
$GRUBCheck = [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Microsoft Corporation UEFI CA 2011’
if ($GRUBCheck -eq $true){
$complinant = ‘False’
}
else
{
$complinant = ‘True’
}
}
catch {
}

$complinant

This slideshow requires JavaScript.

Once we had the script we needed to create the configuration item and baseline.

To create the configuration item open MECM console > Assets and Compliance > Overview > Compliance settings > Configuration item

Create Configuration ItemGRUB3Select Windows Desktops and Servers (custom)GRUB4Select Windows 10 as the version of Windows that will be assessed. GRUB5Add a new settings item. GRUB6Give the item a name

Setting type to script and data type to string. Click Add script. GRUB7Put in the script above.grub8Next add in a compliance rule.GRUB10

Give the compliance rule a name, select the settings item we create earlier, set the value to True so that any devices that doesn’t have the vulnerability will return as compliant. GRUB11Once all the settings and compliance rules are configure following the wizard to complete GRUB12Next we need to create the configuration baseline

Assets and Compliance > Overview > Compliance settings > Configuration item GRUB13Give the compliance baseline a name

Click add and select configuration item.GRUB14Add the configuration item created earlier. GRUB15Click ok to complete the baseline GRUB16Once the baseline is configured, deploy the baseline to the required device collection GRUB17You can either wait for the next time the client does a machine policy retrieval or run the action manually from the client.  Once the client get the updated policy the baseline should show under configurations.GRUB18

Once evaluated we can check the deployment in MECM to find device that are compliant or non-compliant.GRUB19

VMware 6.7 PSC Decommission: Failed to get the PSC thumbprint

As part of our recent VMware 6.7 upgrade we where migrating from external PSC to embedded PSC.

All went fine until we tried to decommission the old PSC’s, when trying to view the thumbprint we got the below error:

Failed to get the PSC thumbprint. Ensure PSC port is correct.

With out getting the thumbprint you can’t continue.

We tested accessing the PSC using web browser,

using openssl from the vCenter appliance

openssl s_client -connect PSC01.domain.local:443

We also tested access using telnet to confirm if port 443 was open

curl -v telnet://PSC01.domain.local:443

All test came back fine and there was no ports being blocked.

In the end the issue was caused by using the short name for the vCenter servers https://VCSA/UI

When we changed to the full FQDN, https://VCSA.domain.local/UI this fixed the issue and we where able to complete the decommission. The issue looks to be related to the SAN name on the cert only having the FQDN.

PSC2

VMware ESXi 6.7 Upgrade: Missing dependencies VIBs Error

Recently we have been upgrading some VMware host from ESXi 6.0 to ESXi 6.7, We where applying the image using VMware update manager and a HPE custom ESXi image.

When applying the image we where getting incompatible warring and where not able to apply the image to upgrade ESXi on some hosts.

The issues was related to VIBS but they where not showing in the html 5 client. vibs1

To find the missing VIBS we ended up having to mount the ISO through HPE ILO and try a manual upgrade which did show the conflicting VIBS. vibs2

In our case the VIBS causing issue was the below.

Mellanox_bootbank_net-mlx4-core_1.9.9.8-10EM.510.0.0.799733
Mellanox_bootbank_net-mlx4-en_1.9.9.0-10EM.510.0.0.799733
Emulex_bootbank_scsi-lpfc820_10.5.55.0-10EM.500.0.0.472560
Mellanox_bootbank_net-mst_2.0.0.0-10EM.500.0.0.472560

The issue seem to be related to older hosts that where previously upgraded from ESXi 5.5.

VMware recommends doing a fresh install if possible but in this case that was not possible, but if you get this error and can do a fresh install that would be the better option. If you can’t do a fresh install below is how I checked to see if the VIBS where in use and how to remove them. 

Next we needed to find out if the VIBS where in use by either the storage or network adapters,

below is the VMware KB that explain how to do this.

https://kb.vmware.com/s/article/1027206

To get the list of storage and network adapter use the esxcli commands

esxcli storage core adapter list

esxcli network nic list

To get check the VIBS version we can use

esxcli software vib list | grep Mel

esxcli software vib list | grep scsi-lpfc820

vibs3

Once we know the version numbers of the VIBS, we just need to confirm they are not used and if not used remove them.

If they where in use we would need to look at creating a custom image or wipe and reload the ESXi host.

We use esxcli to view if the drivers are in use and what version each is

esxcli system module list | grep lpfc820, esxcli network nic get -n vmnic0

vibs4

Once we confirm that none of the VIBS are required the last step is to remove each one. Below is the KB from VMware on removing VIBS.

https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.upgrade.doc/GUID-7FFEBD91-5D82-4E32-93AB-F10D8BFFECAA.html

There might be some VIBS that have dependency’s on others in our case the net-mlx4-core needed to be removed after the net-mlx4-en as it was dependent on it.

To remove we use esxcli software vib remove -n ‘vibname’

vibs5

Reboot the ESXi host if required,

After the reboot, scan the host again from updates tab in VMware vSphere web client and it should now show as non-complaint and not incompatible. vibs6

The host should now upgrade as normal.