Detecting malicious firmware modification

It is determined whether an installed firmware of a device matches a reference firmware for the device. In response to a determination that the installed firmware of the device does not match the reference firmware for the device, different types of content sections of the installed firmware of the device are extracted. At least one of the content sections is identified as a dynamic section. A portion of the installed firmware selected to exclude at least the dynamic section is compared with a corresponding portion of the reference firmware to determine a comparison result. A security action is performed based at least in part on the comparison result.

BACKGROUND OF THE INVENTION

BIOS (i.e., Basic Input/Output System) is firmware that initializes hardware during the booting process and provides runtime services for operating systems and programs. Typically the BIOS firmware is pre-installed on the system board of a machine such as a personal computer, and is the first software run when the machine is powered on. The BIOS firmware interfaces with various machines that make up the complementary system chipset of a computer. BIOS firmware is able to be modified. While this facilitates updates to be performed more easily to the BIOS firmware, it also opens the system to be compromised and the computer may become infected with a hacked BIOS designed to cause harm or provide unauthorized access.

DETAILED DESCRIPTION

A technique is disclosed for automating the extraction and initial analysis of installed firmware such as a BIOS that may have been be compromised or tampered with to cause harm to the server or system on which it has been installed. In particular, the technique can be used to differentiate harmless changes to the installed firmware or BIOS from changes that indicate a real hacking attack, requiring further investigation as to the source of the attack to stop future attacks. More specifically, the technique identifies changes in the installed firmware that are indicative of possible attacks through malicious modifications of the installed firmware's code. A BIOS detected as having a change indicative of possible malicious activity can be identified, stored, and reported for further investigation including a deeper, manual analysis by a BIOS security expert.

The technique makes use of prior knowledge of the different types of content sections in installed firmware such as a BIOS. For example, a BIOS has data settings that are configurable and dynamic, such as settings for the time, date, or other configurable settings that can change over time. A firmware/BIOS also has static sections such as program code sections that control the execution of functions and other operations performed by the BIOS such as initializing hardware during the booting process and providing runtime services for operating systems and programs. Because certain changes, for example to the data settings or due to random bit flips (e.g., changes to content stored in memory/storage that caused by noise, radiation, memory error, hardware limitation, etc.), are innocuous and do not indicate malicious activity, an approach that identifies any change in a firmware/BIOS as a malicious attack will result in false positives. In this case, false positives are determinations that the detected change in the firmware/BIOS is due to a malicious modification when in fact the change is innocuous thus triggering a false alarm. Accordingly, to target only the firmware/BIOS changes that are indicative of malicious activity and limit the number of false positives, a mechanism for detecting tampering of the firmware/BIOS as described herein focuses on detecting changes only to the static code sections and not to the dynamic data settings which are known and expected to be constantly changing over time.

The technique triages reporting on the firmware by identifying firmware that might have been subject to malicious modifications rather than reporting on every firmware detected to have changed from a reference firmware that is known to be uncorrupted. The approach classifies errors for further investigation by distinguishing between a real threat (i.e., an attack on the firmware code) and an innocuous difference caused by a change in firmware data settings (e.g., a difference in time or boot sequence). The technique provides a metric of how urgent a manual analysis is for detecting malicious modifications at the firmware level, reserving the reporting of firmware to only those cases that warrant the time and resources for further investigation. This automated system improves and makes more efficient the process of detecting malicious modifications to installed firmware such as a BIOS.

FIG. 1is a block diagram depicting components of a system100for detecting malicious firmware modification. In some embodiments, an initial in-memory operating system is first installed on a machine to be deployed, shown inFIG. 1as Machine being provisioned110. The initial operating system includes code to determine whether an Installed Firmware120(e.g., a BIOS) matches a reference firmware, for example as an initial validation check, by comparing a signature from Installed Firmware120to a reference signature (i.e. a signature from a reference firmware).

In some embodiments, the code that determines whether the installed firmware matches the reference firmware in the in-memory operating system computes a check sum or hash of Installed Firmware120(e.g., a hash of the BIOS), which serves as the signature from Installed Firmware120. The in-memory operating system running the code that determines whether the installed firmware matches the reference firmware also obtains a reference signature from a reference firmware. In some embodiments, the reference firmware (e.g., reference BIOS) is an uncorrupted version of Installed Firmware120provided by a manufacturer of Installed Firmware120. In some embodiments, the signature of the reference firmware is a reference hash value or golden value provided by the manufacturer of Installed Firmware120. In other embodiments, the code that determines whether the installed firmware matches the reference firmware downloads a reference copy (e.g., a reference BIOS) of Installed Firmware120from a remote server such as Validation Server160through Network150and calculates the golden value (i.e., the reference signature) using the downloaded reference copy of Installed Firmware120. In other embodiments, the reference copy (e.g., a reference BIOS) of Installed Firmware120is obtained from a local storage (e.g., the reference copy is installed to the disk on the machine during a provisioning process). In the example shown, the reference signature is a reference hash value or golden value calculated by the code in the initial in-memory operating system and stored in a database. In both cases, the golden values provided by the manufacturer or calculated by the code in the initial in-memory operating system can be stored in a database such as Central Database140and can be accessed by the code that determines whether the installed firmware matches the reference firmware through Network150.

In some embodiments, instead of computing the check sum or hash of Installed Firmware120(e.g., a hash of the BIOS) to obtain the signature of Installed Firmware120, the signature of Installed Firmware120is obtained instead from a Trusted Platform Module or TPM130. In the example ofFIG. 1, a TPM chip130is shown as installed on Machine110, but the TPM technology used by system100may be implemented in other ways such as in TPM firmware. TPM chip130calculates the check sum value or hash value of Installed Firmware120(e.g., the BIOS) and writes it to a register (e.g., Platform Configuration Register 0) on TPM chip130. Thus, Platform Configuration Register 0 (i.e., PCR0) of TPM chip130holds the check sum value or hash value of Installed Firmware120, which can be read by the code that determines whether the installed firmware matches the reference firmware. In this case, the PCR0 value serves as the signature of Installed Firmware120and is compared against the golden value (i.e., the reference signature) obtained from Central Database140via Network150.

FIG. 2is a flowchart illustrating an embodiment of a process for detecting malicious firmware modification. The process200shown inFIG. 2can be used to automate the detection, diagnosis, and performance of remedial security actions to address tampering and attacks directed to pre-installed firmware including BIOSs and UEFIs (Unified Extensible Firmware Interfaces). Additionally, the technique described herein provides an approach that can assist in detecting tampering with firmware code to aid in taking informed remedial security measures.

An initial in-memory operating system installed on a machine being provisioned includes code to perform an initial validation check on Installed Firmware120. In some embodiments, the process determines whether an installed firmware matches a reference firmware at210. If at220a match is determined, at222, the process proceeds to provision the machine at224. Provisioning the machine at224may include: installing the machine's operating system, installing applications, installing/initializing services and configurations, and/or performing other actions needed for the machine to function in deployment.

After the machine is provisioned at224, the process performs remote attestation at226. Remote attestation is a method by which a host or client can authenticate its hardware and software configuration to a remote host or server. The remote attestation process will ensure that the PCR0 value read from the TPM chip is correct by passing signed messages (e.g., secured using security keys) back and forth to make sure the correct value is received. If the remote attestation process is successful, the machine is deployed, put into use, or put into production. If the remote attestation process fails, a security action is performed. For example, the machine is prevented from being deployed and the firmware is uploaded or stored and a report is generated to indicate that further analysis or investigation is needed.

FIG. 3is a block diagram showing an example of the basic steps involved in remote attestation. In particular,FIG. 3shows how an application provides attestation to a challenging service provider to receive some value added service from the provider. The remote attestation shown inFIG. 3is merely an example and other remote attestation may be utilized in various other embodiments.

As shown in the block diagram300ofFIG. 3, when Application330needs a service from outside User Platform310, it first establishes communication at301with a service providing system or service provider (not shown). The service provider issues a challenge through Service Challenger320to Application330to demonstrate or confirm that the service provider is running the necessary components of itself inside one or more enclaves. The challenge itself contains a nonce for liveness purposes. At302, Application330requests a report from Application Enclave340and passes in the nonce contained in the challenge. At303, Application Enclave340generates a report structure and returns this report structure along with a manifest to Application330. The manifest contains those values that are included in the user data portion of the report and may include the nonce and an ephemerally generated public key to be used by the challenger for communicating secrets back to the enclave. At304, the report is delivered to Quoting Enclave350for signing. Quoting Enclave350authenticates the report and converts the body of the report into a quote and signs it with the security key. At305, Quoting Enclave350returns the quote structure requested to Application330. At306, Application330returns the quote structure and any associated manifest of supporting data to Service Challenger320. At307, Service Challenger320uses the security public key certificate to validate the signature over the quote or may optionally choose to use a security verification service to perform this function. In particular, Service Challenger320compares the enclave information in the quote against a trusted configuration and only renders the service to Application330if the enclave information matches the trusted configuration. Service Challenger320might enforce different trust policies, for example, only trusting a specific version of an enclave, identified by the measurement of the code and data in the enclave, or trusting all enclaves with a specific Product ID from a specific enclave author, identified by the hash of the public key in the security certificate. A trust policy must include enclave authorship and attributes checks. The steps described above serve as an example to illustrate one possible way that an enclave can be attested by a remote entity in a remote attestation process. The trusted configuration mentioned above is typically provided by the enclave author to the service provider. The mechanism for the service provider to acquire the trusted configuration is out of the scope of the remote attestation. One possible mechanism is that the service provider utilizes the existing public key infrastructure to verify the identity of the entity providing the trusted configuration information before accepting the trusted configuration information.

In response to a determination that the installed firmware of the device does not match the reference firmware for the device at228, the process extracts different types of content sections of the installed firmware of the device at230. In some embodiments, at least one of the content sections is identified as a dynamic section. The process compares a portion of the installed firmware to a corresponding portion of the reference firmware at235. In some embodiments, the installed firmware is a BIOS, shown as Installed Firmware120inFIG. 1, and the reference firmware is an uncorrupted version of Installed Firmware120(e.g., a golden reference BIOS) provided by a manufacturer of Installed Firmware120. The process200proceeds at step240to perform a security action in response to the comparison of the installed firmware to the reference firmware. After a security action is performed at240, the installed firmware is replaced (e.g., ROM storing the installed firmware is re-flashed using the reference firmware) at step250.

The process provisions the machine at224by installing the main operating system for the machine by performing other provisioning including installing applications, services, and configurations needed for the machine to be deployed. Next, remote attestation is performed at step226according to the steps described with respect toFIG. 3. If remote attestation fails, the installed firmware is reported for further investigation and additional security action (not shown). If remote attestation succeeds, the machine is deployed or placed in production (not shown).

FIG. 4is a flowchart illustrating additional steps in an exemplary embodiment of a firmware matching process210which can be used to perform an initial validation check on the installed firmware. The process210may be performed by code in the initial in-memory operating system on the machine being provisioned (e.g., Machine110ofFIG. 1). Alternatively, in some embodiments, the process210is performed remotely, by passing values back and forth from a remote analysis server such as Validation Server160ofFIG. 1. For example, a service can determine whether the installed firmware matches the reference firmware by requesting a signature of the installed firmware or BIOS and comparing the signature of the installed firmware to a reference signature obtained remotely from a database.

As shown inFIG. 4, determining whether an installed firmware matches a reference firmware at210can include determining whether a signature of the installed firmware (e.g., Installed Firmware120ofFIG. 1) matches a reference signature. To perform this determination, the process obtains a signature of the installed firmware at410, obtains a reference signature at420, and compares the signature from the installed firmware to the reference signature at430. The process then determines whether the signatures match at440. If the signatures match (pass the validation check) at222and the process proceeds as described with respect toFIG. 2by provisioning the machine at224and performing remote attestation at226. If the signatures do not match (fail the validation check) at228, the process proceeds as described with respect toFIG. 2by extracting different types of content sections of the installed firmware at230and comparing a portion of the installed firmware with a corresponding portion of the reference firmware at235, performing a security action at240, re-flashing the installed firmware at250, and then provisioning the machine at224and performing remote attestation at226.

In some embodiments, determining whether the installed firmware matches the reference firmware is performed by code in the initial in-memory operating system installed on the machine being provisioned (e.g., Machine110ofFIG. 1). The code computes a check sum or hash of the installed firmware (e.g., a hash of the BIOS), which serves as the signature from the installed firmware. This signature from the installed firmware is requested by the process210at step410.

In some embodiments, the reference signature is a golden value corresponding to a hash of a reference firmware. The reference firmware is a version of the installed firmware that has not been compromised such that when a hash function is applied, the result is a valid or trusted hash value corresponding to an uncorrupted version of the installed firmware (e.g., a golden BIOS) provided by a manufacturer of the installed firmware. In some embodiments, the signature of the reference firmware is a reference hash value or golden value provided by the manufacturer of the installed firmware.

In other embodiments, the code that determines whether the installed firmware matches the reference firmware downloads a reference copy (e.g., golden reference BIOS) of the installed firmware from a remote server and calculates the golden value (i.e., the reference signature) using the downloaded reference copy of installed firmware. In these embodiments, the reference signature is a reference hash value or golden value calculated by the code in the initial in-memory operating system and stored in a database. In both cases, the golden values provided by the manufacturer or calculated by the code in the initial in-memory operating system can be stored in a database such as Central Database140and can be accessed by the code that determines whether the installed firmware matches the reference firmware through Network150ofFIG. 1. Thus, as shown inFIG. 4, the code that determines whether the installed firmware matches the reference firmware can obtain a reference signature at420from a database that stores the golden values, which may be provided by the manufacturer of the installed software or pre-computed and stored by the code in the initial in-memory operating system. After obtaining the reference signature at420, the code that determines whether the installed firmware matches the reference firmware compares this reference signature to the signature from the installed firmware at430and determines whether the two signatures match at440.

In some embodiments, determining whether the installed firmware matches the reference firmware is performed on firmware installed on a machine being provisioned by a process210, as depicted inFIG. 4, by code installed in an initial in-memory operating system of the machine. In some cases, the installed firmware is an installed BIOS and the hash of the installed BIOS includes a hash value obtained from a Platform Configuration Register number 0 or PCR0 value of a TPM chip that computes and stores the hash of the installed BIOS program/code. In this case, the valid hash value corresponding to the hash of the reference firmware is a hash comprising a golden hash value for a version of the BIOS that has not been compromised. The golden hash value can be provided by the manufacture of the BIOS or it can be pre-calculated by the code installed in the initial in-memory operation system on a reference copy of the BIOS (i.e., a golden BIOS provided by the manufacturer of the BIOS). The golden hash values can be stored in a database such as the Central Database140ofFIG. 1, and can be accessed via a network, such as Network150ofFIG. 1.

In some embodiments, the hash value for the installed BIOS is obtained directly from the kernel or installed BIOS and does not include a security check. In other embodiments, the PCR0 value for the installed BIOS is obtained from a TPM (Trusted Platform Module) chip, shown at130inFIG. 1. More specifically, the TPM chip130is a secure cryptoprocessor for executing secure cryptographic operations such as taking a hash of the BIOS. Because it includes multiple physical security mechanisms to make it tamper resistant, the TPM chip is appropriate for system integrity measurements and for key creation and use. In this case, the BIOS firmware that is loaded during the boot process can be measured and recorded by the TPM chip and the measurements used as evidence for how the machine started. The integrity of the BIOS can be checked by confirming that a TPM-based key was used only when the correct software (e.g., BIOS firmware that has not been tampered with or compromised) was used to boot the system. However, because the process performed inFIG. 4and/or step210ofFIG. 2is performed by a lightweight in-memory program, the PCR0 value believed to be obtained from the TPM chip cannot be authenticated due to additional resources being not accessible by the lightweight in-memory program. Thus the PCR0 value believed to be obtained from the TPM chip is initially trusted (e.g., trusted during the process performed inFIG. 4and/or step210ofFIG. 2) and later the authenticity of the PCR0 value is validated during remote attestation (e.g., in step226ofFIG. 2).

The PCR0 value for the installed BIOS can be written to the TPM chip130, and the golden hash value can be stored in a database, such as Central Database140ofFIG. 1, for later access. As shown inFIG. 2, in response to determining that the PCR0 value for the installed BIOS matches the golden value (resulting in a determination that the installed firmware matches the reference firmware at222), the process200provisions the machine at224and performs remote attestation at226.

In some embodiments, determining whether the installed firmware matches the reference firmware at210includes checking to see whether the PCR0 value for the installed BIOS matches the golden hash value obtained from the database. For example, only the static configuration of the BIOS is hashed to generate the PCR0 value and this PCR0 value is obtained for comparison with the golden hash value. If the PCR0 value for the installed BIOS matches the golden hash value obtained from the database, the installed firmware is determined to match the reference firmware at222and the process proceeds as described with respect toFIG. 2by provisioning the machine at224and performing remote attestation at226. If the PCR0 value for the installed BIOS does not match the golden hash value obtained from the database, the installed firmware is determined not to match the reference firmware at228and the process proceeds as described with respect toFIG. 2by extracting different types of content sections of the installed firmware at230and comparing a portion of the installed firmware with a corresponding portion of the reference firmware to determine a comparison result at235, performing a security action at240, re-flashing the installed firmware at250, provisioning the machine at224, and performing remote attestation at226.

In some embodiments, in order to distinguish between changes in the installed firmware that are innocuous and changes to the installed firmware that are indicative of possible attacks through malicious modifications of the installed firmware's code, prior knowledge of the different types of content sections in the installed firmware is used to filter out the dynamic sections of the installed firmware leaving only the static portion of the installed firmware corresponding to its code. The presumption is that the static portion of the installed firmware corresponding to its code should not change in any appreciable way unless it has been tampered with or compromised. Accordingly, the technique seeks to detect only the changes to the code of the installed firmware while ignoring changes to the dynamic sections that represent data settings and configurations. Focusing on the changes detected in the code will minimize false positives or false alarms that are the result of interpreting innocuous changes in the data settings as harmful. Here, only the static portion of the installed firmware is compared to the corresponding static portion of the reference firmware, with the reference firmware serving as a benchmark for comparison. The magnitude of the difference between the static portions of the installed firmware and the reference firmware provides a metric for identifying cases of installed firmware (e.g., bad BIOSs) that might have been subject to malicious modifications and should be reported.

FIG. 5is a flowchart depicting further details of a process to distinguish between changes in the installed firmware that are innocuous and changes to the installed firmware that are indicative of possible attacks through malicious modifications of the installed firmware's code. In particular,FIG. 5illustrates additional steps in an exemplary embodiment of process230ofFIG. 2to extract different types of content sections of the installed firmware of the device in response to a determination that the installed firmware of the device does not match the reference firmware for the device at228. The process230may be performed by code on disk or in the initial in-memory operating system on the machine being provisioned or may be performed remotely using a service or through a remote server such as Validation Server160connected via Network150to the Machine being provisioned110, as shown inFIG. 1.

In some embodiments, the process230extracts different types of content sections of the installed firmware of the machine at510. At least one of the extracted content sections is identified as a dynamic section, which corresponds to data settings that are configurable and can change over time. After the sections of the installed firmware are extracted at510, they are parsed at520in order to identify and separate the dynamic from the static sections. The dynamic sections of the installed firmware are filtered out by a filtering process at530in order to isolate and retain only the static sections of the installed firmware corresponding to its code. Similarly, sections of the reference firmware are extracted at515and parsed at525in order to identify and separate the dynamic from the static sections of the reference firmware. The dynamic sections of the reference firmware are filtered out by a filtering process at535to isolate and retain only the static sections of the reference firmware corresponding to its code. In this manner, a difference is determined at540that represents a measure of how much the code section of the installed firmware has changed with respect to the code section of the reference firmware, effectively ignoring any differences in the dynamic sections which are innocuous and not indicative of malicious activity.

In some embodiments, the installed firmware is installed in a flash ROM of the machine being provisioned and the process230ofFIG. 4includes extracting a current image of the installed firmware from a flash ROM of the machine being provisioned. Different types of content sections of the installed firmware can subsequently be extracted at510from the current image of the installed firmware extracted from the flash ROM of the machine being provisioned.

In some embodiments, the process230obtains a reference copy of a previously extracted image of the installed firmware. This reference copy corresponds to an image of the installed firmware having a valid hash value, such as a golden BIOS provided by the manufacturer of the BIOS, and serves as a benchmark (i.e., the reference firmware) for comparison. The process compares a portion of the installed firmware selected to exclude at least the dynamic section with a corresponding portion of the reference firmware. In this example, a portion of the current extracted image of the installed firmware that was extracted from the flash ROM of the machine provisioned is compared to a corresponding portion of the reference copy or golden BIOS.

In some embodiments, the current extracted image of the installed firmware is put on a disk file and the current extracted image on the disk file is locally compared to the reference copy or golden BIOS on the machine being provisioned. The comparison may be performed by code in the initial in-memory operating system on the machine being provisioned. In some cases, the reference copy or golden BIOS is obtained from a cloud service (not shown). Alternatively, instead of putting the current extracted image on a disk file and locally comparing that image to the reference copy on the machine being provisioned, the current extracted image of the installed firmware can be put or uploaded to another device or machine different from the machine being provisioned and the comparison can be performed on the other device or machine. In some embodiments, the process of comparing the current extracted image of the installed firmware to a corresponding portion of the reference copy or golden BIOS is performed remotely, by passing values back and forth from a remote analysis server such as Validation Server160ofFIG. 1.

To limit the number of false positives, the technique focuses on detecting changes to the non-dynamic or static code sections, because changes to the dynamic data settings and configurations are expected and are likely not indicative of tampering of the code. The parsing and filtering steps ofFIG. 5are applied to each of the installed firmware at520and530and the reference firmware at525and535respectively in order to select a portion that excludes at least the dynamic section of each of the installed firmware and the reference firmware in order to determine a difference at540. The difference determined at540thus represents a difference in the code of the installed firmware.

In some embodiments, a portion of the installed firmware selected to exclude at least the dynamic section is obtained by parsing the current extracted image of the installed firmware into sections or raw bytes at520. These sections or raw bytes of the current extracted image are identified as corresponding to different types of content sections of the installed firmware including the dynamic section. The parsing step at520is followed by filtering the sections or raw bytes of the current extracted image at530to exclude the sections or raw bytes of the current extracted image that correspond to the dynamic section, leaving only the sections or raw bytes of the current extracted image that correspond to a non-dynamic or static section.

The corresponding portion of the reference firmware which forms the basis for comparison is obtained in a similar manner, namely, by parsing the reference copy of the previously extracted image of the installed firmware into sections or raw bytes at525, wherein the sections or raw bytes of the reference copy are identified as corresponding to different types of content sections of the installed firmware including the dynamic section. This parsing step is followed by filtering the sections or raw bytes of the reference copy at535to exclude the sections or raw bytes of the reference copy that correspond to the dynamic section, leaving only the sections or raw bytes of the reference copy that correspond to a non-dynamic or static section. The parsing steps can be performed by a firmware parser, which can be any parser that understands the data format of binary images extracted from the installed firmware or BIOS and can parse the binary images into sections or raw bytes that can be identified as different types of content sections.

Because we are interested in detecting changes to the non-dynamic or static sections, the process compares a portion of the installed firmware selected to exclude at least the dynamic section with a corresponding portion of a reference firmware to determine a difference at540. In some embodiments, the parsing and filtering steps applied to each of the current extracted images of the installed firmware and the reference copy of the previously extracted image of the installed firmware result in the generation of filtered sections or raw bytes of the current extracted image that can be compared to corresponding sections or filtered raw bytes of the reference copy. Comparing the filtered sections or raw bytes of the current extracted image of the installed firmware to the corresponding filtered sections or raw bytes of the reference copy or reference firmware can comprise determining a difference between the filtered sections or raw bytes of the current extracted image of the installed firmware and the filtered sections or raw bytes of the reference copy or reference firmware. This difference is obtained by performing a bit-to-bit or byte-to-byte comparison of the filtered sections or raw bytes of the current extracted image of the installed firmware and the corresponding filtered sections or raw bytes of the reference copy of the previously extracted image of the installed firmware (i.e. the reference firmware). In this manner, the process counts the number of bits or bytes that differ between the filtered sections or raw bytes of the current extracted image of the installed firmware and the corresponding filtered sections or raw bytes of the reference copy of the previously extracted image of the installed firmware.

Note that the parsing and filtering steps ensure that the bit-to-bit or byte-to-byte comparisons are performed only on the code sections of the installed firmware and the reference firmware. In other words, by first parsing the each of the installed firmware and the reference firmware into different content sections, the process can filter out the dynamic content sections corresponding to data settings that are expected to change leaving only the non-dynamic or static content sections corresponding to the code as a basis for comparison. Thus, the difference obtained at540ofFIG. 5is a count of the bits that differ in the code between the installed firmware and the reference firmware.

Parsing the firmware to separate it into different types of sections and filtering the parsed firmware to exclude at least the dynamic sections can be performed on the machine being provisioned (e.g., Machine110ofFIG. 1). Alternatively, in some embodiments, parsing and filtering is performed remotely, by a remote service or by a firmware parser on a remote server such as Validation Server160ofFIG. 1connected to the machine being provisioned via a network.

Comparing a portion of the installed firmware selected to exclude at least the dynamic section with a corresponding portion of the reference firmware to determine a comparison result can include comparing a raw byte section corresponding to the portion of the installed firmware selected to exclude at least the dynamic section with a reference raw byte section corresponding to the portion of the reference firmware. In some examples, as shown inFIG. 5, comparing a portion of the installed firmware with a corresponding portion of the reference firmware includes determining a difference between filtered sections of the installed firmware to corresponding filtered sections of the reference firmware at540. In some embodiments, determining a comparison result includes determining a magnitude of difference between the portion of the installed firmware selected to exclude at least the dynamic section and the corresponding portion of the reference firmware.

FIG. 5also depicts additional steps in an exemplary embodiment of process240ofFIG. 1to perform a security action based at least in part on the comparison result determined at235. The process240may be performed by code in the initial in-memory operating system on the machine being provisioned or may be performed remotely using a service or through a remote server such as Validation Server160connected via Network150to the Machine being provisioned110, as shown inFIG. 1.

In some embodiments, the process240performs a security action by determining whether the comparison result exceeds a threshold value. For example, the security action can be performed in response to a determination that the magnitude of difference exceeds a threshold. The threshold value can be a non-zero value and in response to a determination that the comparison result does not exceed the threshold value, the process240will not report the installed firmware for further analysis. Alternatively, in response to a determination that the comparison result does exceed the threshold value, the process240will report the installed firmware for further analysis. Additionally, performing a security action at240can include replacing the installed firmware with the reference firmware.

FIG. 5shows that performing a security action based at least in part on the comparison result can include reporting the installed firmware for further analysis at560or not reporting the installed firmware at570in response to determining whether the magnitude of the difference obtained at540ofFIG. 5exceeds a threshold (e.g., threshold number of bits/bytes). In the example ofFIG. 5, if the difference between the filtered sections of the installed firmware and the corresponding filtered sections of the reference firmware determined at540exceeds a threshold at550, the process reports the installed firmware for further analysis or investigation at step560. In the case where the installed firmware is a BIOS, the process uploads or stores the BIOS for analysis including a deeper, manual analysis by a BIOS security expert and indicates that further investigation is required to determine whether the difference detected in the code of the BIOS is indicative of tampering. If on the other hand, the difference determined at540does not exceed the threshold at550, no report is made as indicated in step570. Regardless of whether the difference is determined to exceed or not exceed the threshold at550, the process will proceed to re-flash the installed software at step250ofFIG. 2(if the initial validation check fails at228) and will provision the machine at224and perform remote attestation at226.

The threshold provides an ability to adjust or fine-tune the sensitivity of the triaging of BIOS reporting and can be set to any number of bits or bytes. A lower threshold will tolerate less of a difference between the code (static sections) of the installed firmware and the code (static sections) of the reference firmware. For example, setting the threshold to zero bits will tolerate no difference between the code of the installed firmware and the code of the reference firmware, so that even a difference of one bit will result in a security action such as reporting the installed firmware for further analysis and investigation. A zero bit threshold thus ensures that no difference will be tolerated and minimizes the false negatives (i.e., the missed detections of a bad BIOS) which increases the sensitivity of the triaging. However, there is a trade-off in that lowering the threshold increases the false positives (i.e., false alarms, which in this case are determinations that the change is due to a malicious modification when in fact the change is innocuous). In the case of a zero threshold, a change of one or two bits due to random bit flipping would result in a security action and would increase the false positives. Setting the threshold to a small value, such as one or two bits, might result in a better trade-off between false alarms and missed detections by tolerating the case of random bit-flipping while setting a threshold low enough to detect any meaningful change in the code of the installed firmware that would be indicative of a malicious attack.

The process is not limited to only one instance of the firmware, BIOS, or UEFI but can include a set of valid hash values corresponding to a set of reference firmwares. In this case, the golden hash value corresponding to the hash of the reference firmware is one of a plurality of golden hash values that can be stored in Central Database140ofFIG. 1. Additionally, the reference firmware is one of a plurality of reference firmwares and each of the plurality of golden hash values corresponds to a hash of one of the plurality of reference firmwares.

The technique described herein for detecting malicious firmware modification exploits prior knowledge of the file format of the installed firmware and prior knowledge of where the tampering of the code is likely to have taken place in the installed firmware. Specifically, the disclosed method and system takes advantage of knowing that the non-dynamic or static sections correspond to the code of the installed firmware and that any changes in the dynamic sections corresponding to data settings are to be expected and are unlikely to indicate tampering. The technique also makes use of access to a valid or golden hash value—a signature corresponding to a clean, uncorrupted, version of the installed firmware that provides a benchmark for comparison.

An alternative method for detecting malicious firmware modification that would not require prior knowledge of the file format of the installed firmware can be used in the case where a sufficient volume of data is obtained that represents samples of clean, uncompromised, instances of the installed firmware, BIOSs, or UEFIs. In this case, if enough data is available, on the order of hundreds of samples of good BIOSs for example, a firmware parser may be used to extract the binary images of each sample of good firmware and parse each of the binary images into raw bytes for each sample of good firmware. The raw bytes for each of the samples can be used to train a system using machine learning techniques to determine what parts of the sample always change (corresponding to data settings) and what parts do not change (corresponding to code). The trained system can then be used to determine or predict whether the installed firmware deviates from the samples in a meaningful way (e.g., corresponding to changes in the code) indicating possible tampering of the code of the installed firmware. In response to determining that the installed firmware does not match the good samples but deviates in a meaningful way, the installed firmware can be uploaded and a security action performed.