How to Handle Driver/Firmware/BIOS Vulnerabilities

I want to make it really clear that what I outlay below is not the only way or maybe even the best way to handle these kinds of vulnerabilities. I think it is the most direct way that takes out some of the complexities involved with other methods. As always, I’m open to criticism so let me know in the comments if I’ve gone astray.

It really hasn’t been a good year for hardware manufacturers and those that assemble their parts into final products. I’m most familiar with HP and they seem to have made some particularly poor life choices in this regard:

May 2017: (INTEL-SA-00075) (HP: HPSBHF03557) Intel Active Management Technology (AMT) Vulnerability

May 2017: (HP: HPSBGN03558) Conexant HD Audio Driver Keylogger

October 2017: (HP: HPSBHF03571) WPA2 ‘KRACK’ Vulnerability

November 2017: (INTEL-SA-00086) (HP: HPSBHF03571) Intel Management Engine (IME) Vunerability

November 2017: (HP: HPSBHF03564) Synaptics Touchpad Driver Keylogger

What does everything above have in common? A long list of models that all need to have updated drivers, BIOS, and/or firmware. If you do not control the models used in your organization you are simply screwed. I’ve heard of school districts that use off-lease hand-me-downs leading to hundreds or even thousands of different models in their environment. Truly a nightmare. If you’ve maintained any sort of control over the models used in your environment then things might not be pretty but they should at least be manageable.

How to Create a Target Collection

When the Intel Management Vulnerability was found Intel released their own detection tool. This tool has the ability to run silently and write the results to the registry. I’ve seen plenty of admins create a package to run the detection tool, a configuration item to detect the registry status value, and a collection based on the baseline results. Alternatively, others choose to extend hardware inventory to capture the results.

This all struck me as rather complicated so I looked for some existing inventory item that could be used. What I found was that the IME firmware version was synonymous with the AMT version which can be inventoried. To do so, configure hardware inventory to include the SMS_AMTObject WMI class. This allows you to write a collection query like the following. Standard disclaimer: copy and pasting from the internet tends to screw up quotation marks so be sure to replace them by hand or in a text editor.

Select SMS_R_SYSTEM.ResourceID From SMS_R_System Where ResourceID in (Select ResourceID From SMS_G_System_AMT_AGENT Where SUBSTRING(SMS_G_System_AMT_AGENT.AMT,1,5) IN ('11.0.','11.5.','11.6.','11.7.') or SUBSTRING(SMS_G_System_AMT_AGENT.AMT,1,6) IN ('11.10.','11.20.'))

This query will select the IME/AMT versions listed as vulnerable by Intel. However, even this may not be necessary.

How to Deploy: One Application, Many … Many Deployment Types

Once you know what devices are vulnerable how do you fix them? You could make a bunch of packages or applications and deploy them to specific models. I’ve seen administrators creating task sequences to handle reboots and detection. Instead, I’m using a single application (per vulnerability or type) that has a deployment type for each model. The key to this is to create a custom Global Condition. You can use Global Conditions to create your own custom logic for your application requirements.

Create Global Condition for Hardware Model

Navigate to Software Library\Overview\Application Management\Global Conditions right click on the node and select Create Global Condition. Then name it and fill in the following details:

Setting Type: WQL Query

Data Type: String

Namespace: Root\Cimv2

Class: Win32_ComputerSystem

Property: Model

You should end up with something like this:

With this global condition you can now create a deployment type requirement for one or more model names:

Great, Now What Models Do I Have?

Note that some manufacturers are not particularly consistent in setting the model name in the BIOS (see my screenshot above). In our case we tend to get a different value for devices that have had their motherboard replaced by the manufacturer. What this means is that you need to know what models you have in your environment and how they report themselves. That’s easy enough: go to Monitoring\Overview\Queries and create a query with the following WQL statement:

Select Distinct SMS_G_System_COMPUTER_SYSTEM.Model From SMS_R_System Inner Join SMS_G_System_COMPUTER_SYSTEM On SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId Order By SMS_G_System_COMPUTER_SYSTEM.Model

Run this query to list every unique model name you have in your environment.

How to Detect The Updated Driver/BIOS/Firmware

How to detect that the update was successful is a bit of an art rather than pure science. For drivers the most straight-forward way is to detect the version of one of the files. Here’s the detection method I wrote for the Conexant Audio Driver:

The IME updates for HP use a softpaq which adds a uninstall registry entry like the following:

For BIOS updates you can reference the SystemBiosDate or SystemBiosVersion registry values in HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System.

For firmware updates, specifically the IME firmware, you can again rely on the WMI classes and write a Powershell detection method:

If ((Get-WMIObject -NameSpace root\cimv2\sms -class SMS_AMTObject -property AMT).AMT -eq '11.8.50'){ Write-Host 'Success' }

Deployment Revisited: Deploy ALL THE THINGS

Let’s review. With the list of distinct models created by the query above you can cross-reference them to the manufacturer’s list of affected models. You then create a deployment type for each model using requirements based on a custom global condition. You then use update-specific detection methods to make sure the update was successfully applied. With these things you can safely deploy the application to everything in your environment and simply avoid the complexity of trying to figure out what devices are vulnerable. Any device that requires the application is vulnerable. Any device that is not applicable or has the application installed is protected. To reiterate what I said above, this only works if you have reasonable control over the models that are used in your organization.

Don’t Forget to Update your Driver Packages

While everything above is focused on protecting existing devices don’t forget to update your driver packages so that newly imaged devices are protected right from the start.

A Few HP-Specific Notes

Since I primarily deal with HPs, here’s a couple of notes: