Firmware anomaly detection method and device
The firmware anomaly detection method addresses vulnerabilities in UEFI by analyzing startup and operational data with intelligent models, offering active defense against malicious code and ensuring server stability.
Patent Information
- Application Number
- CN202411216172.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-30
- Publication Date
- 2024-12-13
AI Technical Summary
Existing server firmware, particularly UEFI, is vulnerable to external attacks and interference, leading to potential crashes and operational disruptions, with existing security measures like Secure Boot and static analysis failing to provide active defense against malicious code.
A firmware anomaly detection method that utilizes a detection system to analyze operation information during the startup process, including access request data of target services, to identify anomalies using intelligent models and threshold comparisons, ensuring out-of-band management to detect and alert against malicious code.
Effectively defends against UEFI malicious code attacks by dynamically monitoring firmware behavior, providing timely alerts and ensuring server stability through proactive anomaly detection.
Smart Images
Figure CN119128876A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of computer technology, and in particular to a firmware anomaly detection method and device. Background Art
[0002] Unified Extensible Firmware Interface (UEFI) is a computer firmware interface standard used to start a computer and perform hardware initialization.
[0003] In the related art, the server is very weak in the firmware startup link. It is not only difficult to resist external attacks, but also easily interfered by external control and cannot be started, which can easily cause the server to crash and endanger the normal operation of the server. Summary of the invention
[0004] In view of this, the present disclosure provides a firmware anomaly detection method and device.
[0005] According to a first aspect of the present disclosure, a firmware anomaly detection method is provided, comprising: in response to powering on an electronic device, loading a detection system of the electronic device; in response to completion of loading of the detection system, obtaining operation information of the firmware of the electronic device during a startup process using the detection system, wherein firmware startup is a stage before the operating system of the electronic device is started; and analyzing the operation information using the detection system to detect whether there is an anomaly in the firmware.
[0006] According to an embodiment of the present disclosure, the detection system is used to obtain the operation information of the firmware of the electronic device during the startup process, including: using the detection system to obtain access request data of at least one target service, the target service represents the function provided by the firmware during the startup process; according to the access request data, the operation information is determined; wherein the target service includes: at least one of a firmware protocol and a firmware service, and the operation information includes at least one of the following: the number, frequency, and time of target service calls.
[0007] According to an embodiment of the present disclosure, a detection system is used to obtain the operating information of the firmware during the startup process, including: during the firmware startup process, the operating information obtained at different times is stored in the detection system; and in response to the arrival of multiple marking moments, the operating information obtained before each marking moment is analyzed to obtain the number and frequency of at least one target service call.
[0008] According to an embodiment of the present disclosure, in response to reaching multiple marking moments, the operation information obtained before each marking moment is analyzed to obtain the number and frequency of at least one target service call, including: according to different stages in the firmware startup process, the operation information of different stages is obtained; the operation information within each stage and / or the operation information obtained before the end of each stage is analyzed to obtain the number and frequency of at least one target service call.
[0009] According to an embodiment of the present disclosure, the detection system is used to analyze the operation information to detect whether the firmware has an abnormality, including: the detection system uses an intelligent model to process the operation information to detect whether the firmware has an abnormality.
[0010] According to an embodiment of the present disclosure, a detection system is used to analyze operation information to detect whether there is an abnormality in the firmware, including: the detection system processes the operation information based on a first model to detect whether there is an abnormality in the firmware, and generates a first prompt message when an abnormality is detected, wherein the intelligent model includes the first model; and / or the detection system processes the operation information based on a second model to detect whether there is an abnormality in the firmware, and generates a second prompt message when an abnormality is detected, wherein the intelligent model includes the second model; wherein the second model is of a different type from the first model, and the second prompt message and the first prompt message target different abnormal situations.
[0011] According to an embodiment of the present disclosure, the first model is used to determine at least one first abnormal result from an abnormal database based on operating information, and the abnormal database includes a mapping relationship between operating information of multiple target services and the first abnormal result; the second model is used to analyze and predict at least one second abnormal result based on the operating information, and the second abnormal result does not exist in the abnormal database.
[0012] According to an embodiment of the present disclosure, a detection system processes operation information based on a first model to detect whether there is an abnormality in the firmware, and generates a first prompt message when an abnormality is detected, including: determining a first call count of at least one group based on the operation information, wherein a plurality of target services belong to different groups respectively, and the groups are divided according to the functions of the target services; when the first call count does not meet a first threshold range, detecting that there is an abnormality in the firmware, and generating a first prompt message; determining a second call count of at least one target service based on the operation information; when the second call count does not meet a second threshold range, detecting that there is an abnormality in the firmware, and generating a second prompt message, wherein the first prompt message is different from the second prompt message.
[0013] A second aspect of the present disclosure provides a firmware anomaly detection device, including: a loading module, used to load a detection system of an electronic device in response to the electronic device being powered on; an acquisition module, used to acquire running information of the firmware of the electronic device during a startup process using the detection system in response to completion of loading of the detection system, wherein firmware startup is a stage before the operating system of the electronic device is started; and a detection module, used to analyze the running information using the detection system to detect whether there is an anomaly in the firmware.
[0014] According to an embodiment of the present disclosure, the device further includes: a storage module, configured to store the operation information.
[0015] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] The above and other objects, features and advantages of the present disclosure will become more apparent through the following description of the embodiments of the present disclosure with reference to the accompanying drawings, in which:
[0017] Figure 1 A schematic diagram of server authority management in the related art is schematically shown;
[0018] Figure 2 A flowchart of a firmware anomaly detection method according to an embodiment of the present disclosure is schematically shown;
[0019] Figure 3 A flowchart of a firmware anomaly detection method according to an embodiment of the present disclosure is schematically shown;
[0020] Figure 4 A flowchart of a firmware anomaly detection method according to another embodiment of the present disclosure is schematically shown;
[0021] Figure 5 A flowchart of a firmware anomaly detection method according to another embodiment of the present disclosure is schematically shown;
[0022] Figure 6 A schematic diagram of intelligent model detection according to an embodiment of the present disclosure is schematically shown;
[0023] Figure 7 The schematic diagram shows a principle diagram of a firmware anomaly detection method according to an embodiment of the present disclosure;
[0024] Fig. 8A One of the evaluation effects of the firmware anomaly detection method according to an embodiment of the present disclosure is schematically shown;
[0025] Figure 8BThe second evaluation effect of the firmware anomaly detection method according to the embodiment of the present disclosure is schematically shown;
[0026] Fig. 9 The structure block diagram of the firmware anomaly detection device according to an embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION
[0027] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present disclosure. In the following detailed description, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present disclosure. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present disclosure.
[0028] The terms used herein are only for describing specific embodiments and are not intended to limit the present disclosure. The terms "comprise", "include", etc. used herein indicate the existence of features, steps, operations and / or components, but do not exclude the existence or addition of one or more other features, steps, operations or components.
[0029] All terms (including technical and scientific terms) used herein have the meanings commonly understood by those skilled in the art unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.
[0030] When using expressions such as "at least one of A, B, and C, etc.", they should generally be interpreted according to the meaning of the expression commonly understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.).
[0031] The embodiments of the present disclosure provide a firmware anomaly detection method and device. Before introducing the technical solution provided by the embodiments of the present disclosure, the related technologies involved in the present disclosure are first described.
[0032] Reference Figure 1 UEFI, as the underlying firmware, has very high system permissions. If it is maliciously tampered with, it will pose a great threat to user data and privacy. And because UEFI is loaded before the operating system boots, this UEFI malicious code cannot be repaired by conventional antivirus software, and reinstalling the system will not work.
[0033] At present, the industry has introduced many security features, such as Secure Flash, Secure Boot, Self-Healing, etc., to protect the security of UEFI from various aspects such as preventing unauthorized erase and write operations, measuring code integrity, and automatic recovery. Or when a new security vulnerability is discovered, the only way to complete the defense is to upgrade UEFI. However, from the discovery of the security vulnerability to the actual update of UEFI by the user, there is no effective defense, and the proportion of users updating UEFI is relatively low. Or static analysis of BIOS code is performed to detect vulnerabilities. However, none of the above methods can actively defend against UEFI malicious code.
[0034] Before further describing the embodiments of the present disclosure in detail, the nouns and terms involved in the embodiments of the present disclosure are described. The nouns and terms involved in the embodiments of the present disclosure are subject to the following interpretations.
[0035] Firmware is a software that provides low-level control for server hardware, which is crucial to the stability and manageability of the server. Therefore, the resilience of the firmware is essential. Firmware is usually stored in a storage device, which may include a non-volatile flash memory device, a random access memory (RAM) and a read-only memory (ROM), etc. The non-volatile flash memory device may also be called a flash device. Among them, the firmware may include BMC (Baseboard Management Controller) and UEFI (Unified Extensible Firmware Interface), as well as ME (Management Engine) firmware running on PCH (South Bridge Chip).
[0036] Out-of-Band Management (OOBM) is a network management method that uses a channel separate from the main network channel to manage network devices. This management method does not rely on the main production network, but is carried out through a dedicated channel, ensuring business continuity and network management security. Out-of-band management allows network operators to establish trust boundaries when accessing management functions and apply them to network resources. Out-of-band management provides an independent, secure and reliable network management method, ensuring that network administrators can effectively manage network devices and maintain the normal operation of the network under any circumstances.
[0037] The embodiment of the present disclosure provides a firmware anomaly detection method, including: in response to the electronic device being powered on, loading the detection system of the electronic device; in response to the detection system being loaded, using the detection system to obtain the running information of the firmware of the electronic device during the startup process, wherein the firmware startup is the stage before the operating system of the electronic device is started; and using the detection system to analyze the running information to detect whether the firmware is abnormal. The detection system analyzes the running information (i.e., services and protocols) during the firmware startup process to detect whether the UEFI is attacked by malicious code, thereby achieving the purpose of actively defending against the UEFI malicious code attack.
[0038] The following will be passed Figure 2~Figure 8B The firmware anomaly detection method of the disclosed embodiment is described in detail.
[0039] Figure 2 The flowchart of the firmware abnormality detection method according to the embodiment of the present disclosure is schematically shown.
[0040] like Figure 2 As shown, the firmware abnormality detection method of this embodiment includes operations S110 to S130.
[0041] In operation S110 , in response to the electronic device being powered on, a detection system of the electronic device is loaded.
[0042] The detection system manages the firmware in the form of out-of-band management, that is, the detection system and the firmware are connected to the terminal device through different channels respectively.
[0043] Exemplarily, after the terminal device is powered on, the detection system is loaded first, then the firmware is started, and finally the operating system is started.
[0044] In operation S120, in response to the detection system loading being completed, the detection system is used to obtain the running information of the firmware of the electronic device during the startup process. The firmware startup is the stage before the operating system of the electronic device is started.
[0045] Exemplarily, the operation information during the firmware startup process may be a boot service, that is, the actual function provided by the firmware during the boot process. The boot service helps the boot loader and the operating system to boot. For example, initializing system hardware, setting up memory, processing file systems, etc. For example, the operation information may include call information of services and protocols.
[0046] It should be known that the firmware is the core software system directly fixed on the motherboard, which stores the most important basic input and output programs of the server, the self-test program after power-on, and the system self-starting program. After power-on, the firmware reads and writes specific information of the system settings from ROM and other memories, providing the lowest-level and most direct hardware settings and control for the server.
[0047] In operation S130, the operation information is analyzed using a detection system to detect whether the firmware has an abnormality.
[0048] Exemplarily, the acquired operation information is analyzed by using a detection system to determine whether the firmware is attacked by malicious code.
[0049] In other embodiments, the detection system can also be used to obtain the operation information of the firmware of the electronic device during operation. The firmware operation is the stage after the operating system of the electronic device is started. By analyzing the operation information of the firmware during operation, it can be obtained whether there is an abnormality in the firmware during the operation stage.
[0050] The detection system is used to obtain first operation information of the firmware of the electronic device during the startup process and operation information during the operation process, and the detection system is used to analyze the first operation information and the second operation information to perform firmware anomaly detection on the entire operation process of the electronic device.
[0051] It is understandable that the detection system analyzes the running information (i.e., services and protocols) during the firmware startup process to detect whether UEFI is attacked by malicious code, thereby achieving the purpose of actively defending against UEFI malicious code attacks.
[0052] Figure 3 The flowchart of a firmware abnormality detection method according to an embodiment of the present disclosure is schematically shown.
[0053] As described above, in operation S120, in response to the detection system loading being completed, the detection system is used to obtain the running information of the firmware of the electronic device during the startup process. Figure 3 As shown, the operation may further include operation S121a to operation S122a.
[0054] In operation S121a, access request data of at least one target service is acquired by using a detection system, where the target service represents a function provided by the firmware during a boot process.
[0055] In operation S122a, operation information is determined according to the access request data.
[0056] The target service includes: at least one of a firmware protocol and a firmware service, and the operation information includes at least one of the following: the number, frequency, and time of calling the target service.
[0057] In the disclosed embodiment, the firmware startup process involves access requests for multiple target services. The access request for the target service is the firmware accessing and requesting a specific service or resource. For example, memory detection (target service), the firmware performs a memory self-test (POST) to verify the integrity and availability of the system memory (RAM), and the firmware issues an access request to the system memory module to check whether it has any faults and determine the total amount of available memory. Graphics card initialization, the firmware requests to identify and initialize the graphics card to ensure normal display output. The firmware accesses the hardware registers of the graphics card, configures its basic settings, and detects the display connection status.
[0058] For example, during the memory detection process, the firmware usually calls specific services and protocols to perform hardware initialization and self-test. For example, firmware service: POST (Power-On Self-Test), POST checks all basic hardware components, including memory, to ensure that they function properly when the system starts. POST does not rely on network protocols, but is part of the self-test program built into the firmware. Firmware protocol: Memory Map protocol, the layout and status information of the system memory is obtained through the Memory Map protocol.
[0059] The operation information may include the number, frequency and time of the firmware protocol calls in the target service, or the number, frequency and time of the firmware service calls, or the number, frequency and time of the firmware protocol and firmware service calls. For example, during the firmware startup process, the number of times the Memory Map protocol is called, if there are multiple calls, what is the time interval between two adjacent calls, and how long after each call is started.
[0060] The abnormality judgment can be made according to the number of calls, the frequency of calls or the time of calls of the target service. The number of calls, the frequency of calls or the time of calls of the target service can also be combined in any number as the operation information for abnormality judgment. The embodiments of the present disclosure are not limited to this.
[0061] It is understandable that when the firmware is not attacked by malicious code (normal startup), the calls (number, frequency and time) of the firmware service and firmware protocol in the target service are all within the normal range. If the firmware is attacked by malicious code, the operation of the malicious code requires the support of the firmware in the terminal. Therefore, the calls (number, frequency and time) of the firmware service and firmware protocol in the target service will be far away from the normal range. In this way, it is possible to monitor whether there is a malicious code attack during the firmware startup process.
[0062] Figure 4 The flowchart of a firmware abnormality detection method according to another embodiment of the present disclosure is schematically shown.
[0063] As described above, in operation S120, in response to the detection system loading being completed, the detection system is used to obtain the running information of the firmware of the electronic device during the startup process. Figure 4 As shown, the operation may further include operation S121b to operation S122b.
[0064] In operation S121b, during the firmware startup process, the operation information acquired at different times is stored in the detection system.
[0065] In operation S122b, in response to reaching a plurality of marking moments, respectively, the operation information acquired before each marking moment is analyzed to obtain the number and frequency of at least one target service call.
[0066] In the disclosed embodiment, the firmware startup process is a period of time, but at different times, the calls to the target service are different. For example, hardware initialization is required at the beginning, and then the driver needs to be loaded. That is, the functions that the firmware wants to achieve at different times are different. Therefore, during the firmware startup process, the number and frequency of calls to the firmware protocol and firmware services at different times are counted in stages to perform abnormal analysis and detection.
[0067] For example, the multiple marking moments may be user-defined moments, or may be end moments of multiple stages commonly used for firmware startup. The embodiment of the present disclosure does not specifically limit the definition of the marking moments.
[0068] In some embodiments, statistics can be collected for the number and frequency of calls to different firmware protocols and firmware services at all times before each marking moment, or for the number and frequency of calls to different firmware protocols and firmware services between two marking moments.
[0069] It is understandable that the calling of the target service is recorded and analyzed in stages according to the marking time, so as to realize dynamic detection of abnormal firmware startup data, so as to quickly detect abnormal firmware problems.
[0070] Figure 5 The flowchart of a firmware abnormality detection method according to another embodiment of the present disclosure is schematically shown.
[0071] As described above, in operation S122b, in response to reaching multiple marking moments, the operation information obtained before each marking moment is analyzed to obtain the number and frequency of at least one target service call. Figure 4 As shown, the operation may further include operation S1211b to operation S1212b.
[0072] In operation S1221b, according to different stages in the firmware startup process, operation information of different stages is obtained.
[0073] In operation S1222b, the operation information in each stage and / or the operation information obtained before the end of each stage is analyzed to obtain the number and frequency of at least one target service call.
[0074] For example, the commonly used stages of firmware startup include SEC (Security), PEI (Pre-EFIInitialization), DXE (Driver Extension Environment), BDS (Boot Device Selection) and TSL (Transient System Load). Among them, the SEC stage is the hardware reliability verification stage, which is used to obtain system control and pass system status parameters to the next stage PEI; the PEI stage is the pre-initialization stage, which is used to initialize the hardware such as CPU, chipset and motherboard; the DXE stage is the driver execution stage, which is used to poll and load the drivers of all devices; the BDS stage is the boot device selection stage; the TSL stage is the transient system loading stage, which is used to call OSLoader to load the operating system.
[0075] For example, in the SEC phase, the firmware usually (normal startup) calls the first firmware protocol 10 times and calls the first firmware service 3 times. If the number of calls to the first firmware protocol and the first firmware service in the SEC phase is counted at the end of the SEC phase, and the number of calls is significantly different from the number of calls during normal startup, it can be determined to be abnormal.
[0076] As described above, in operation S130, the detection system is used to analyze the operation information to detect whether the firmware is abnormal. In an achievable manner, the operation may further include operating the detection system to process the operation information using an intelligent model to detect whether the firmware is abnormal.
[0077] In an embodiment of the present disclosure, operation information (eg, the number of calls, ratings, or times of target services at different marking moments) is input into an intelligent model for anomaly detection.
[0078] First, it is necessary to use multiple historical data (normal startup + abnormal startup) of the firmware startup process to train the intelligent model. Multiple historical data are divided into training set, verification set and test set. The training set is used to train the intelligent model to minimize the loss of the output results of the intelligent model. The trained intelligent model is verified by the verification set. Finally, the verified intelligent model is tested by the test set. The abnormal startup data can be abnormal data caused by malware such as UEFI rootkit during the firmware startup process and / or operation; it can also include PoC (Proof of Concept) data, which refers to samples or codes used to prove that a vulnerability exists and can be exploited.
[0079] Among them, multiple historical data can cover the collection of UEFI firmware images from the official websites of seven mainstream OEM manufacturers; covering all well-known firmware suppliers (Insyde, AMI, Phoenix) firmware suppliers; covering all major X86 CPU architectures; based on two widely used open source versions of the UEFI specification (EDKII and Project Mu), etc. At the same time, multiple historical data can also cover various stages of firmware development; in production line production, product certification testing (PA testing), user experience testing (UX testing) and other stages; various specific startup modes: sleep mode recovery (S4), remote wake-up (WOL), power failure (PowerLoss), with or without adapter (AC / DC), update upgrade mode (WUFU), recovery mode (Recovery), etc.; the terminal contains data with different configurations. So that the collection of historical data widely covers different situations of firmware startup, makes the training of the intelligent model more comprehensive, and thus makes the prediction results of the intelligent model more accurate.
[0080] In order to ensure the accuracy of the training of the intelligent models (first model and second model). It can be evaluated from the following aspects. For example, accuracy: calculates the ratio of correctly predicted instances to the total number of instances in the dataset. Precision: measures the ratio of correctly predicted positive instances to all instances predicted by the model as positive. Recall: measures the ratio of correctly predicted positive instances to all instances that actually belong to the positive class. F1-Score: takes into account false positives and false negatives and provides a balanced view of model performance. FPR: calculates the proportion of instances in which the system incorrectly classifies negative instances as positive to the total number of actual negative instances. FNR: measures the proportion of actual positive cases that are incorrectly identified as negative by the system or test. Overhead: additional resources, time, or complexity introduced by a specific function, process, or operation.
[0081] For example, according to historical data training, in the SEC stage, the firmware usually (normal startup) calls the first firmware protocol 10 times and calls the first firmware service 3 times. If at the end of the SEC stage, the number of calls to the first firmware protocol within the SEC stage is 15 times, and the number of calls to the first firmware service is 10 times, which is significantly different from the number of calls during normal startup, the intelligent model can be determined as abnormal.
[0082] Figure 6 A schematic diagram of intelligent model detection according to an embodiment of the present disclosure is schematically shown.
[0083] Further, as described above, the detection system is used to analyze the operation information to detect whether the firmware has an abnormality. In one possible implementation, the operation includes: the detection system processes the operation information based on the first model, detects whether the firmware has an abnormality, and generates a first prompt message when an abnormality is detected, wherein the intelligent model includes the first model. The detection system processes the operation information based on the second model, detects whether the firmware has an abnormality, and generates a second prompt message when an abnormality is detected, wherein the intelligent model includes the second model. The second model is of a different type from the first model, and the second prompt message and the first prompt message are different in the abnormal situation.
[0084] In the embodiments of the present disclosure, refer to Figure 6 , the intelligent model includes a first model and a second model. The first model and the second model are of different types. For example, the first model can be a detection of firmware service calls during firmware startup, and the second model can be a detection of firmware protocol calls during firmware startup. Or the first model can be a result match of the test data based on known abnormal results, and the second model can be a prediction of unknown abnormal results.
[0085] The acquired operation information can be input into the first model and the second model at the same time, and detection can be performed separately to perform abnormality detection of different contents.
[0086] The first prompt information and the second prompt information may both display specific content of the abnormal result, for example, an attacker forges or tampers with the BIOS update package.
[0087] In other embodiments, the first model may be used alone for detection, or the second model may be used alone for detection, which is not limited in the embodiments of the present disclosure.
[0088] Furthermore, the first model is used to determine at least one first abnormal result from the abnormality database based on the operating information, and the abnormality database includes a mapping relationship between the operating information of multiple target services and the first abnormal result; the second model is used to analyze and predict at least one second abnormal result based on the operating information, and the second abnormal result does not exist in the abnormality database.
[0089] Exemplarily, the first model may be a supervised learning model, and the first model is intended to detect known attacks or operations that do not need to be processed. That is, the data to be predicted is input into the first model, and the first model matches the data of the known malicious attack firmware. If the corresponding data can be matched, it means that there is an abnormality, and the first abnormal result is output.
[0090] The second model can be an unsupervised model, and the second model is designed to detect anomalies to identify rare events, items, or suspicious observations. That is, the data to be predicted is input into the second model, and the second model analyzes whether there is an anomaly based on the data to be predicted. Among them, the prediction result output by the second model is unknown, which may be an anomaly caused by a hidden association between the number of calls, frequency, and time between multiple firmware services and protocols, and outputs a second anomaly result. That is, the second anomaly result does not exist in the anomaly database of the first model.
[0091] Further, as described above, the detection system processes the operation information based on the first model, detects whether there is an abnormality in the firmware, and generates a first prompt information when an abnormality is detected. The operation includes the following operations.
[0092] According to the operation information, a first call count of at least one group is determined, and the plurality of target services belong to different groups respectively, and the groups are divided according to functions of the target services.
[0093] When the first calling number does not satisfy the first threshold range, it is detected that the firmware is abnormal and a first prompt message is generated.
[0094] A second calling number of at least one target service is determined according to the operation information.
[0095] When the second call number does not satisfy the second threshold range, it is detected that the firmware is abnormal, and a second prompt information is generated, and the first prompt information is different from the second prompt information.
[0096] In the embodiment of the present disclosure, different target services during the firmware startup and operation process can be divided into the following multiple groups according to the attributes (eg, functions) of the target services, as shown in Table 1.
[0097] First, the call counts of the firmware services and firmware protocols in the four groups (virtual memory, pool memory, events, and protocols) in the running information are counted (first count) to obtain the first call count. It is determined whether the first call count is within the first threshold range of the combination of the call counts of the firmware protocols and services in each group during normal startup. If so, it indicates that the startup is normal. If not, it indicates that the startup is abnormal, and the first prompt information about the group is generated. For example, there is an abnormality in the virtual memory.
[0098] Secondly, the number of calls to the firmware services and firmware protocols in the nineteen types of target services in the operation information is counted (second statistics) to obtain the second number of calls. It is determined whether the second number of calls is within the second threshold range of the combination of the number of calls to the firmware protocols and services in each target service during normal startup. If so, it indicates that the startup is normal. If not, it indicates that the startup is abnormal, and the first prompt information about the target service is generated. For example, there is an abnormality in memory release. That is, the second prompt information can be the abnormal result after the refinement of the first prompt information. So that personnel can quickly locate the abnormal problem.
[0099] Table 1
[0100]
[0101] Among them, UEFI Boot belongs to the general startup process of the server. In this process, the server is still performing initialization configuration operations.
[0102] UEFI Runtime mainly provides support after the operating system is loaded. After the operating system is started, the UEFI Runtime service can be called by the operating system and applications for further system management and configuration operations.
[0103] Figure 7 The principle diagram of the firmware anomaly detection method according to an embodiment of the present disclosure is schematically shown.
[0104] like Figure 7 As shown, in one possible implementation, the detection system includes: a hook program, a storage database, and an intelligent model.
[0105] The detection system is integrated into the AI chip, and the detection system and firmware are connected to the terminal device through different channels to achieve out-of-band management of the detection system.
[0106] The hook program is used to capture multiple firmware protocols and firmware services called during UEFI startup and / or operation. The storage database is used to store the data information captured by the hook program (multiple firmware protocols and firmware services). The intelligent model is used to analyze the number, frequency and time of multiple firmware protocols and firmware service calls based on the data information captured in the storage database to determine whether there is malicious code running. When an abnormality is determined, an abnormal prompt message will be generated.
[0107] Among them, the hook program can be externally loaded through Option ROM. Option ROM is mainly used to solidify the firmware code in the hardware device. It can also be hard-coded to call the DXE Driver through the USB interface. That is, load the custom driver from the USB device at startup and implement additional functions or modifications through the UEFI driver environment.
[0108] In order to evaluate the feasibility of the firmware anomaly detection method of the embodiment of the present disclosure, the test results are now described.
[0109] Fig. 8A One of the evaluation effects of the firmware anomaly detection method according to an embodiment of the present disclosure is schematically shown; Figure 8B The second evaluation effect of the firmware anomaly detection method according to the embodiment of the present disclosure is schematically shown.
[0110] Reference Fig. 8A , showing that during the firmware startup process, malware uses boot services to execute its malicious code or attack. During the firmware startup process, according to the total number of firmware service and firmware protocol calls in the group, it can be seen that the number of calls to virtual memory, events, and protocols by the abnormal code during execution has increased significantly, so it can be determined that there is an abnormality in the firmware of the device.
[0111] Further, refer to Figure 8B During the firmware startup process, according to the total number of target service calls, it can be seen that the number of calls to N1, N2, ... N14, N15, etc. by the abnormal code during execution increases significantly. Due to the increase in the number of calls to different target services, the total number of firmware protocol and firmware service calls in different groups increases. Therefore, by analyzing the number of calls to firmware services and firmware protocols during the firmware startup process / running process, it can be determined whether there is an abnormality in the firmware startup.
[0112] Based on the above firmware anomaly detection method, the present disclosure also provides a firmware anomaly detection device. Fig. 9 The device is described in detail.
[0113] Fig. 9 The structure block diagram of the firmware anomaly detection device according to an embodiment of the present disclosure is schematically shown.
[0114] like Fig. 9 As shown, the firmware anomaly detection device 300 of this embodiment includes a loading module 310 , an acquisition module 320 and a detection module 330 .
[0115] The loading module 310 is used to load the detection system of the electronic device in response to the electronic device being turned on. In one embodiment, the loading module 310 can be used to perform the operation S110 described above, which will not be described in detail here.
[0116] The acquisition module 320 is used to obtain the operation information of the firmware of the electronic device during the startup process in response to the completion of the loading of the detection system, and the firmware startup is the stage before the operating system of the electronic device is started. In one embodiment, the acquisition module 320 can be used to perform the operation S120 described above, which will not be repeated here.
[0117] The detection module 330 is used to analyze the operation information using the detection system to detect whether the firmware is abnormal. In one embodiment, the detection module 330 can be used to perform the operation S130 described above, which will not be repeated here.
[0118] In some embodiments, Fig. 9 The firmware anomaly detection device may further include: a storage module.
[0119] The storage module is used to store the operation information.
[0120] The storage module builds a database and stores the firmware services and the operation information written by the firmware during the firmware startup and / or operation process in the database, so that the subsequent intelligent model can centrally call the target service operation information.
[0121] According to an embodiment of the present disclosure, any multiple modules of the loading module 310, the acquisition module 320 and the detection module 330 can be combined into one module for implementation, or any one of the modules can be split into multiple modules. Alternatively, at least part of the functions of one or more of these modules can be combined with at least part of the functions of other modules and implemented in one module. According to an embodiment of the present disclosure, at least one of the loading module 310, the acquisition module 320 and the detection module 330 can be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, a system on a package, an application-specific integrated circuit (ASIC), or can be implemented by hardware or firmware such as any other reasonable way of integrating or packaging the circuit, or implemented in any one of the three implementation methods of software, hardware and firmware or in any appropriate combination of any of them. Alternatively, at least one of the loading module 310, the acquisition module 320 and the detection module 330 can be at least partially implemented as a computer program module, and when the computer program module is run, the corresponding function can be executed.
[0122] It will be appreciated by those skilled in the art that the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways, even if such combinations and / or combinations are not explicitly described in the present disclosure. In particular, the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways without departing from the spirit and teachings of the present disclosure. All of these combinations and / or combinations fall within the scope of the present disclosure.
[0123] The embodiments of the present disclosure are described above. However, these embodiments are only for illustrative purposes and are not intended to limit the scope of the present disclosure. Although the embodiments are described above separately, this does not mean that the measures in the various embodiments cannot be used in combination to advantage. The scope of the present disclosure is defined by the attached claims and their equivalents. Without departing from the scope of the present disclosure, those skilled in the art may make a variety of substitutions and modifications, which should all fall within the scope of the present disclosure.
Claims
1. A firmware anomaly detection method, comprising: In response to the electronic device being powered on, loading a detection system of the electronic device; In response to the detection system being loaded, using the detection system to obtain the running information of the firmware of the electronic device during the startup process, wherein the firmware startup is a stage before the operating system of the electronic device is started; as well as The detection system is used to analyze the operation information to detect whether there is an abnormality in the firmware.
2. The method according to claim 1, wherein: The using a detection system to obtain the operation information of the firmware of the electronic device during the startup process includes: Acquire access request data of at least one target service using a detection system, wherein the target service represents a function provided by the firmware during a boot process; Determining the operation information according to the access request data; The target service includes at least one of a firmware protocol and a firmware service, and the operation information includes at least one of the following: The number, frequency, and time of calls to the target service.
3. The method according to claim 1 or 2, wherein: The method of using the detection system to obtain the running information of the firmware during the startup process includes: During the firmware startup process, storing the operation information acquired at different times in the detection system; and In response to reaching a plurality of marking moments respectively, the operation information acquired before each of the marking moments is analyzed to obtain the number and frequency of calls of the at least one target service.
4. The method according to claim 3, wherein: The step of analyzing the operation information acquired before each of the marking moments in response to reaching the plurality of marking moments to obtain the number and frequency of the at least one target service call comprises: According to different stages of the firmware startup process, acquiring the operation information of the different stages; The operation information in each of the stages and / or the operation information acquired before the end of each of the stages are analyzed to obtain the number and frequency of calls to the at least one target service.
5. The method according to claim 2, wherein: The using the detection system to analyze the operation information to detect whether the firmware is abnormal includes: The detection system processes the operation information using an intelligent model to detect whether there is an abnormality in the firmware.
6. The method according to claim 5, wherein: The using the detection system to analyze the operation information to detect whether the firmware is abnormal includes: The detection system processes the operation information based on the first model, detects whether the firmware has an abnormality, and generates first prompt information when an abnormality is detected, wherein the intelligent model includes the first model; and / or The detection system processes the operation information based on the second model, detects whether the firmware has an abnormality, and generates second prompt information when an abnormality is detected, wherein the intelligent model includes the second model; The second model is of a different type from the first model, and the second prompt information and the first prompt information target different abnormal situations.
7. The method according to claim 6, wherein: The first model is used to determine at least one first abnormal result from an abnormal database according to the operation information, wherein the abnormal database includes a mapping relationship between operation information of multiple target services and the first abnormal result; The second model is used to analyze and predict at least one second abnormal result based on the operation information, and the second abnormal result does not exist in the abnormal database.
8. The method according to claim 6 or 7, wherein: The detection system processes the operation information based on the first model, detects whether the firmware has an abnormality, and generates a first prompt message when an abnormality is detected, including: determining a first call count of at least one group based on the operation information, wherein the plurality of target services belong to different groups respectively, and the groups are divided according to the functions of the target services; When the first call number does not meet a first threshold range, detecting that the firmware is abnormal and generating a first prompt message; Determining a second call count of the at least one target service according to the operation information; When the second calling number does not satisfy a second threshold range, it is detected that the firmware is abnormal, and a second prompt information is generated, and the first prompt information is different from the second prompt information.
9. A firmware anomaly detection device, comprising: A loading module, used for loading a detection system of the electronic device in response to the electronic device being powered on; an acquisition module, configured to acquire, in response to completion of loading of the detection system, operation information of the firmware of the electronic device during a startup process using the detection system, wherein the firmware startup is a stage before the operating system of the electronic device is started; as well as The detection module is used to analyze the operation information using the detection system to detect whether there is any abnormality in the firmware.
10. The device according to claim 9, wherein: Also includes: The storage module is used to store the operation information.