Firmware has become more popular in the world of computer security research. Attacks operating at the firmware level can be difficult to discover, and have the potential to persist even in bare-metal recovery scenarios. This type of hack has been well documented by investigations of the HackingTeam and Vault7exploits.
Fortunately, there are methods for detecting and defending against such attacks. Firmware-based attacks typically attempt to add or modify system firmware modules stored in NVRAM. Tools provided by the open source CHIPSEC project can be used to generate and verify hashes of these modules, so users can detect unauthorized changes.
CHISPEC, introduced in March 2014, is a framework for analyzing platform level security of hardware, devices, system firmware, low-level protection mechanisms, and the configuration of various platform components. It contains a set of modules, including simple tests for hardware protections and correct configuration, tests for vulnerabilities in firmware and platform components, security assessment and fuzzing tools for various platform devices and interfaces, and tools acquiring critical firmware and device artifacts.
The whitelist module (tools.uefi.whitelist) uses CHIPSEC to extract a list of EFI executables from a binary firmware image, and builds a list of “expected” executables and corresponding hashes (.JSON file) to be used later for comparison. Documentation is available as part of the module source code on github, and in the CHIPSEC manual.
The process assumes you’re starting from a “known good firmware image”, preferably a production version of the firmware provided by the manufacturer, and that you’ve used CHIPSEC to scan for known issues before accidentally whitelisting something nasty. This example uses the open source UEFI firmware for the MinnowBoard Turbot (release 0.97), for better visibility into the process.
Generating a Firmware Whitelist
The following CHIPSEC command line creates a whitelist named efilist.json based on a “known good image” (platform_fw.bin):
python chipsec_main.py -i -n -m tools.uefi.whitelist -a generate,efilist.json,platform_fw.bin
Applying this process to the x64 “release” and “debug” images of the MinnowBoard Turbot 0.97 firmwareproduces the following whitelists:
- MNW2MAX1.X64.0097.D01.1709211100.bin (UEFI x64 firmware, debug mode) – X64D97_whitelist.json
- MNW2MAX1.X64.0097.R01.1709211052.bin (UEFI x64 firmware, release mode) – X64R97_whitelist.json
(exercise for the reader: download the firmware images, run CHIPSEC, see if your whitelist matches)
It’s important to note that resulting JSON whitelist file isn’t a just hash of the binary file, it contains hashes of the firmware image’s executable modules. CHIPSEC has the ability to scan and catalog individual firmware components, which can be used to whitelist or blacklist specific executables.
Posting Whitelists
If you were a system manufacturer, you could publish these whitelists for customer verification. However, it’s best to sign files for verification purposes. To assure that the whitelist obtained by an end-user is the official whitelist, it can be signed with GPG using a detached signature:
gpg –detach-sign <file>
Additionally, users should authenticate certificates for a well-known domain name for the system manufacturer when delivered over HTTPS. It’s also advisable for IT organizations to sign internally generated whitelists to prevent unauthorized lists from being used in audits.
Checking Whitelists
If a detached signature is available, GPG can be used to verify the whitelist file:
gpg –verify <file>
Once the authenticity of the whitelist has been verified, the user needs to take an image of the platform firmware using CHIPSEC. This command line used the ‘dump’ command to generate user_fw.bin:
python chipsec_util.py spi dump user_fw.bin
Now CHIPSEC can be used to verify the platform firmware image against the associated whitelist. This example would verify against the x64 “release” image for Minnowboard Turbot 0.97:
python chipsec_main.py -i -n -m tools.uefi.whitelist -a check,X64REL_whitelist.json,user_fw.bin
At this point, CHIPSEC will return a “PASSED” or “WARNING” status. If the test returns “PASSED”, all hashes were found in the whitelist and they match expected values. If the test returns “WARNING”, was then something is different. Note that a “WARNING” against doesn’t immediately indicate a security threat (ex: user may have updated to the manufacturer’s latest firmware), but it does require investigation to make sure the altered firmware image isn’t due to an attempted attack.
Limitations
Using tools like CHIPSEC this can improve security but no system can be absolutely secure, and these procedures cannot defend against all possible attacks. There are a number of limitations to consider when interpreting whitelist results:
- There may be customized or proprietary image packaging methods that CHIPSEC does not understand. This could result in some modules being excluded, so corresponding changes may be missed during a whitelist comparison.
- Software running on an already-compromised system can be fooled. If a system is already compromised, CHIPSEC and similar software may not produce reliable indicators.
Summary
The ability for CHIPSEC to generate whitelists provides a method for validating the firmware supply chain. Manufacturers can leverage these tools to help users verify official firmware releases, and IT administrators can generate whitelists for internal audits based on trusted images.
For more such intel IoT resources and tools from Intel, please visit the Intel® Developer Zone
Source:https://software.intel.com/en-us/blogs/2017/12/05/using-whitelists-to-improve-firmware-security
Follow Us
