Or at least not entirely useless

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: HPSBGN03558Conexant 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:

  • Calling the softpaq with -s usually installs it silently but the IME firmware updates will still show a command prompt window.
  • The IME firmware doesn’t initiate the needed reboot.  Be sure to force it in the User Experience tab of the deployment.

8 Comments

  1. Branden

    Bryan this is great- I’m trying to detect the version of the Synaptics driver installed on the machines in my environment.
    How would I go about doing this- I think your detection method script above only covers the intel stuff? – I could be wrong.

    • Bryan Dam

      Quite right, that script is only for the Intel Management Engine firmware update. For drivers the most straightforward option is to pick one of the driver’s files and do a version check. I recommend always using greater or equal to so that if a future update gets installed there’s no conflict. Some drivers, not all, actually install themselves like an application and show up in the Programs control panel. In those cases there should be some entries in the uninstall registry keys.

  2. Gachevsky

    Good stuff here. I’m getting a syntax error when I try to run your AMT query. Can you tell if something needs tweaking in your example?

    • Bryan Dam

      Ah, forgot the standard disclaimer. Try replacing every quotation mark by hand and running that.

      • Gachevsky

        That did it! Thanks!

  3. Bill HUNT

    While very thorough, and very useful, it looks like you are missing what I think is one of the more concerning hardware vulnerability recently discovered, the TPM vulnerability that impairs the effectiveness of encryption methods like BitLocker from securing the hardware with the physical TPM chip.
    ADV170012 | Vulnerability in TPM could allow Security Feature Bypass – https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV170012
    HPSBHF03568 rev. 5 – Infineon TPM Security Update – https://support.hp.com/us-en/document/c05792935

    This requires a Microsoft KB, a BIOS update in most cases, as well as updating the Firmware of the TPM chip itself. I’m looking into how to deploy this to both existing workstations as well as new build via SCCM right now and may provide my process to supplement this post if others could benefit.

    • Bryan Dam

      You’re spot on Bill. I just learned about that one a few hours ago while talking to HP and was going to add it to the list. They’re going to send me info on the solution they’ve cooked up. Theirs involved a Task Sequence which I fundamentally hate so I’ll see if there’s another way. If you’ve already solved it though then by all means add a link here and I can add it to the post.

      • Vern Bateman

        Bryan, If and when you receive the info from HP re the TPM Update & a task sequence..can you post or send my way. Got through the one TPM upgrade (7.62), but now working on the other IFX TPM update (4.43), which is far less friendly…and of course it applies to more of my clients.

Leave a Reply to Bill HUNTCancel reply

© 2024 Dam Good Admin

Theme by Anders NorenUp ↑