Blog post

Firmware II: Status check

Created:  25 Jan 2017
Updated:  25 Jan 2017
Author:  Mike H
Firmware Status Check

As we noted back in November, it’s common knowledge that keeping device software up to date and securely configured is important. System firmware, on the other hand, is often overlooked. Despite being critical to the secure operation of a device, it's frequently out of date.

But how bad is the problem? How widespread? And what can be done to remedy the situation?

To answer these questions we decided to put our money where our mouth is and run some simple tests on one of our research networks. The goal was gain an accurate picture of the BIOS version running on all connected devices.

The results were a wake-up call. The firmware of devices running on our own network required some attention. This may be the case for you as well.

The Initial Aim

Before we get to the test results, and our subsequent fixes, it’s worth looking at the tests themselves in a little more detail.

We set out with a simple objective: Collect basic BIOS information for all the Windows laptops connected to our research network. Specifically, we were interested in discovering the BIOS version running on each device and the date it was released.

With this information we could determine whether devices were up to date. We could also investigate whether there were any known vulnerabilities to the BIOS version in operation.

Modus Operandi

In order to tackle the problem, we put together a simple script using PowerShell that searched end user devices across the Active Directory domain and returned selected properties of the Win32_BIOS class and Win32_ComputerSystem class for further analysis.

The full script can be found here. This gave us a set of data that could tell us the BIOS version and release date, alongside other basic information for every computer active within the domain.

Smelling the coffee 

The results were a little dismaying. We found that 85% of the devices sampled were running an out of date BIOS and many were several versions behind the latest release.

We also identified that a few machines were potential candidates for the CVE-2015-2890 vulnerability, which involves a failure to enforce appropriate BIOS write protections after the device has been woken from sleep.

It's got to be automated

These discoveries certainly hit home with us. We immediately took action to update the out-of-date devices.

Unfortunately, we did not have any infrastructure in place to automate this, so we had to do it manually - by checking the individual serial number of the devices on the manufacturer’s website to determine the latest BIOS available. The latest version then had to be downloaded and applied by hand. In our case we also had to remember to suspend BitLocker.

Whilst this process as a whole is not difficult, it is far from efficient and certainly not suitable for large enterprise networks where there could be thousands of devices to be securely managed .

Many of our customers have networks of this size. So, over the next few months, we’ll be looking for ways to manage networks at scale. We’ll be updating our EUD guidance with our findings when we're done.

Conclusions

Whilst we succeeded in identifying and patching systems running an out of date BIOS on our small research network, our approach is still not ideal.

The major downside was that determining the status of the BIOS version reported back from our script was a manual process. In addition, we were reliant on end users downloading and performing the update.

Whilst this is feasible on a small research network, for a large enterprise, it's not scalable. Therefore, in the coming weeks, we plan to focus on testing automation of BIOS updates, with a view to scaling this for large enterprise networks.

This will be the subject of a future blog post. In the meantime though, we would love to receive any comments on your own experiences or feedback below, either positive or negative.

3 comments

Mark Thompson - 07 Feb 2017
Unless some kind of standards driven approach can ever be developed for systems BIOS's it is hard to see how widespread updating of BIOs is ever going to happen. In an SME without in-house IT function it would require hiring in a contractor - expensive - and then taking computers out of service while each one is updated - downtime = more expense. Given that to the business there is no apparent difference afterwards - it worked before, it works now - it is a hard sell. Also flashing BIOS's is not without risk and it is easy to end up with a bricked device if it goes wrong. Who pays then? Further some manufacturers - I'm looking at you HP - have stopped providing free BIOS updates. If your server doesn't have a support contract you can't get the BIOS updates.
Mike H - 15 Feb 2017
I don’t think that we necessarily need to go as far as standards but we certainly require buy in from OEMs to provide a reliable and secure method for updates. We also need to find ways to easily automate the process and provide evidence that this works for small to large organisations. This would solve the problem of hiring contracted staff and keep downtime to a minimum. We plan to present our own findings and make any useful data available where we can as we carry out our own research. In practice though, we believe that the process of applying BIOS/firmware updates should ultimately be no different to software updates. We're not there yet, but it's what we're striving for!
Alex Davies - 02 Mar 2017
Insyde handle this problem with standardisation compliance with their UEFI. HP implemented their BIOS on all of their products. What was referenced here was an out of date version, because the average workplace employee does not have access or know how to update them.

I can say though, remote solutions to this, are in progress!

Leave a comment

Was this blog post helpful?

We need your feedback to improve this content.

Yes No