JP7672654B2 - DETECTION APPARATUS, DETECTION METHOD, AND DETECTION PROGRAM - Google Patents

Description

The present invention relates to a detection device, a detection method, and a detection program.

In general, in embedded systems such as the Internet of Things (IoT), firmware that includes various software is used to control the hardware. Since much of this software uses Open Source Software (OSS), which is often found to have vulnerabilities, the IoT is also vulnerable.

Conventionally, a vulnerability database (CVE, Common Vulnerability Enumeration) has been used to detect vulnerabilities based on the version numbers of software used in a system (see Non-Patent Documents 1 and 2). The CVE registers the names and version numbers of vulnerable software, and by checking the software name and version number against the CVE, it is possible to know whether or not there is a vulnerability.

In addition, when software has vulnerabilities, the software is often updated to fix the part causing the vulnerability and increase the version number.

“CVE”, [online], October 2021, [Retrieved January 18, 2022], Internet <URL: https://cve.mitre.org> “OWASP Dependency-Check”, [online], OWASP, [Retrieved January 18, 2022], Internet <URL: https://www.owasp.org/index.php/OWASP_Dependency_Check>

However, with conventional technology, it is difficult to detect whether software running on the IoT has vulnerabilities. For example, when a patch that updates software without changing the version number is applied, the vulnerability is fixed without changing the version number. In that case, when the software name and version number are compared against the CVE, it is determined that the software has a vulnerability, even though the patch has been applied and the vulnerability has been fixed, resulting in a false positive.

The present invention has been made in consideration of the above, and aims to accurately detect whether or not software running on IoT has vulnerabilities.

To solve the above-mentioned problems and achieve the objective, the detection device according to the present invention is characterized by having a collection unit that collects predetermined firmware, an extraction unit that extracts a file representing software contained in the firmware, an identification unit that identifies the version number of the extracted software, and a discrimination unit that discriminates whether there is a difference between software with the same version number arranged in chronological order.

The present invention makes it possible to accurately detect whether or not there are vulnerabilities in software running on IoT.

FIG. 1 is a diagram for explaining an overview of the detection device. FIG. 2 is a schematic diagram illustrating a schematic configuration of the detection device. FIG. 3 is a diagram illustrating an example of the data structure of the firmware table. FIG. 4 is a diagram illustrating an example of the data structure of the file table. FIG. 5 is a diagram for explaining the process of the identification unit. FIG. 6 is a diagram for explaining the process of the determination unit. FIG. 7 is a diagram for explaining the process of the determination unit. FIG. 8 is a flowchart showing a detection process procedure. FIG. 9 is a diagram illustrating a computer that executes a detection program.

One embodiment of the present invention will be described in detail below with reference to the drawings. Note that the present invention is not limited to this embodiment. In addition, in the drawings, the same parts are denoted by the same reference numerals.

[Detection device overview]
1 is a diagram for explaining an overview of the detection device. The detection device of this embodiment manages software names and version numbers included in the firmware of an IoT product in chronological order, and detects software to which a patch that fixes vulnerabilities without changing the version number has been applied before and after a firmware upgrade. Then, the detected software to which a patch has been applied while keeping the version number unchanged is excluded from the target of matching against the CVE, thereby preventing false detection of vulnerabilities.

For example, as shown in Fig. 1, for firmware _F1 and _F2 with consecutive version numbers of an IoT product, the software names and version numbers included in each are compared to identify those with the same software name and version number. Then, for those with the same version number, such as software B shown in Fig. 1, it is determined whether a patch to fix the vulnerability has been applied.

Specifically, the detection device determines that a patch that fixes a vulnerability has been applied if the hash values and program structures are different. For example, if the hash values are the same, it determines that there is no change in the software version between firmware _F1 and _F2 and that no patch has been applied. If the hash values are different but the program structures are the same, it determines that there is some change in the software file between firmware _F1 and _F2 but that no patch has been applied. And if both the hash values and the program structures are different, it determines that a patch that changes the program structure of the software has been applied between firmware _F1 and _F2 .

The detection device can avoid false positives about the presence or absence of vulnerabilities by excluding software that it determines has been patched from the targets of comparison with the CVE.

[Configuration of the detection device]
2 is a schematic diagram illustrating a schematic configuration of a detection device 10 according to the present embodiment. As illustrated in FIG. 2, the detection device 10 is realized by a general-purpose computer such as a personal computer, and includes an input unit 11, an output unit 12, a communication control unit 13, a storage unit 14, and a control unit 15.

The input unit 11 is realized using input devices such as a keyboard and a mouse, and inputs various instruction information, such as starting processing, to the control unit 15 in response to input operations by an operator. The output unit 12 is realized by a display device such as a liquid crystal display, a printing device such as a printer, etc. For example, the output unit 12 displays the results of the detection process described below.

The communication control unit 13 is realized by a NIC (Network Interface Card) or the like, and controls communication between the control unit 15 and external devices via telecommunication lines such as a LAN (Local Area Network) or the Internet. For example, the communication control unit 13 controls communication between the control unit 15 and a server that provides firmware for IoT products.

The storage unit 14 is realized by a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory, or a storage device such as a hard disk or an optical disk. The storage unit 14 stores in advance the processing program that operates the detection device 10 and data used during execution of the processing program, or stores the data temporarily each time processing is performed. The storage unit 14 may be configured to communicate with the control unit 15 via the communication control unit 13.

In this embodiment, the memory unit 14 stores a firmware table 14a, a file table 14b, etc. Note that this information is not limited to being stored in the memory unit 14 of the detection device 10, and may be collected, for example, when the detection process described below is executed.

Here, FIG. 3 is a diagram illustrating an example of the data configuration of the firmware table. As illustrated in FIG. 3, the firmware table 14a includes the product name, firmware version number, and firmware release date of the IoT product. For example, FIG. 3 illustrates the firmware version number "FW_ABC_001" and firmware release date "2020/01/10" of the firmware for the IoT product with the product name "P_ABC".

Prior to the detection process described below, this information is collected by the collection unit 15a from a server that provides firmware for the IoT product via the input unit 11 or the communication control unit 13, and is stored in the memory unit 14.

FIG. 4 is a diagram illustrating an example of the data configuration of the file table. As illustrated in FIG. 4, the file table 14b includes the file ID of the file representing the software included in the firmware, the firmware version number, the software name, the software version number, and the presence or absence of differences. The file table 14b is generated in the detection process described below, and is stored in the memory unit 14.

For example, Figure 4 shows that the software file included in the firmware with firmware version number "FW_ABC_001" has a file ID of "SW_ABC_001_0001", a software name of "httpsserver", and a software version number of "1.1.0".

Returning to the explanation of FIG. 2, the control unit 15 is realized using a CPU (Central Processing Unit) or the like, and executes a processing program stored in memory. As a result, the control unit 15 functions as a collection unit 15a, an extraction unit 15b, an identification unit 15c, a discrimination unit 15d, and a matching unit 15e, as exemplified in FIG. 2. Note that each or some of these functional units may be implemented in different hardware. For example, the matching unit 15e may be implemented in hardware different from the other functional units. The control unit 15 may also include other functional units.

The collection unit 15a collects predetermined firmware. For example, the collection unit 15a collects firmware and firmware meta-information from a firmware distribution site for IoT products via the input unit 11 or the communication control unit 13. The meta-information includes the product name, firmware version number, and firmware release date. The collection unit 15a accumulates the meta-information as a firmware table 14a in the storage unit 14. The collection unit 15a also transfers the firmware to the extraction unit 15b, which will be described below.

The collection unit 15a may immediately transfer the collected firmware to the extraction unit 15b without storing it in the memory unit 14 as a firmware table 14a.

The extraction unit 15b extracts files that represent software included in the firmware. Specifically, the extraction unit 15b unpacks the firmware acquired from the collection unit 15a and extracts the files included in the firmware. For example, the extraction unit 15b extracts files that are executable programs, such as ELF files in the case of Linux (registered trademark).

In addition, the extraction unit 15b stores the file ID and firmware version number of the extracted file as a file table 14b in the memory unit 14, as shown in FIG. 4.

The identification unit 15c identifies the version number of the extracted software. Specifically, the identification unit 15c extracts a character string from the extracted file and identifies the version number of the software corresponding to the file.

For example, the identification unit 15c identifies the version number of the software by using at least one of static analysis, which extracts a string of human-readable characters in a file, and dynamic analysis, which extracts a string output by executing the file. The identification unit 15c then identifies the software name and software version number for the extracted string using regular expressions.

Here, FIG. 5 is a diagram for the processing of the identification unit. FIG. 5 illustrates the processing for identifying the version number of OpenSSL. In the example shown in FIG. 5, the regular expression "^OpenSSL \d\.\d\.\d[a-z]*$" is used to identify the matching string "OpenSSL 1.0.21" from among the extracted strings. This identifies the software name "OpenSSL" and the software version number "1.0.21".

Also, as shown in FIG. 4, the identification unit 15c additionally registers the identified software name and software version number in the file table 14b.

Returning to the explanation of FIG. 2, the determination unit 15d determines whether there is a difference between software that has the same version number when arranged in chronological order.

Here, Figs. 6 and 7 are diagrams for explaining the processing of the discrimination unit. First, the discrimination unit 15d arranges the software names and software version numbers in chronological order based on the firmware release dates. The discrimination unit 15d also checks the version number for each piece of software and calculates a hash value for that software. The discrimination unit 15d then determines whether there are any differences between pairs of files of the previous and next pieces of software.

Specifically, the discrimination unit 15d determines that there is a difference when the hash values and program structures are different between software that has the same version information arranged in chronological order.

6 illustrates an example of software version numbers and hash values arranged in chronological order based on firmware updates for a certain piece of software X. The determination unit 15d checks firmware Fn and firmware _Fn +1 for N pieces of firmware _F1 , _F2 , ..., _FN arranged in chronological order, starting from n= ₁ , and extracts pairs of files having the same version number of software X but different hash values.

6, the processing is completed for _F1 and _F2 because the version numbers are different. Next, _F2 and _F3 have the same version number 2.1 and different hash values, so they are extracted as a pair to be processed by the discrimination unit 15d.

The discrimination unit 15d also determines that there is a difference between the extracted pairs if the program structures are different. In this case, the discrimination unit 15d estimates that a patch that fixes the vulnerability has been applied to the latter file.

Specifically, the discrimination unit 15d determines that the program structures are different when code has changed between files representing software that have the same version information arranged in chronological order, or when code exists in only one of the files. For example, the discrimination unit 15d determines that the program structures are different when a change is found in assembler code within a code block between two binary files. Alternatively, the discrimination unit 15d determines that the program structures are different when a code block exists in only one of the binary files.

Figure 7 illustrates a process for determining whether there is a difference in program structure. In the example shown in Figure 7, the determination unit 15d compares the program structure between two source codes obtained by disassembling binary files 1 and 2, respectively, to determine whether there is a difference.

For example, as shown in FIG. 7 (difference 1), the discrimination unit 15d determines that the program structures are different when there is a change in the code or when specific code is present on only one side. Also, as shown in FIG. 7 (difference 2), the discrimination unit 15d determines that the program structures are different when a specific code block is present on only one side.

The discrimination unit 15d also registers the presence or absence of differences in the file table 14b, as shown in FIG. 4. For example, when the discrimination unit 15d determines that there is a difference between the previous and next files, it registers "Yes" in the "Difference" column of the later file.

Returning to the explanation of FIG. 2, the comparison unit 15e excludes software determined to have differences and compares the software included in the firmware with the CVE. In other words, the comparison unit 15e excludes software to which a patch that fixes vulnerabilities has been applied from comparison with the CVE. This makes it possible for the comparison unit 15e to avoid erroneously detecting the presence of vulnerabilities by comparing software with fixed vulnerabilities with the CVE.

[Detection process]
Next, the detection process by the detection device 10 according to the present embodiment will be described with reference to Fig. 8. Fig. 8 is a flowchart showing the procedure of the detection process. The flowchart in Fig. 8 is started, for example, when an operation input is made to instruct the start of the detection process.

First, the collection unit 15a collects a specific firmware (step S1). For example, the collection unit 15a collects firmware and firmware meta-information from a firmware distribution site for an IoT product via the input unit 11 or the communication control unit 13. The collection unit 15a accumulates the meta-information as a firmware table 14a in the storage unit 14. The collection unit 15a also transfers the firmware to the extraction unit 15b.

Next, the extraction unit 15b extracts files that represent software included in the firmware (step S2). Specifically, the extraction unit 15b unpacks the firmware acquired from the collection unit 15a and extracts files that are executable programs included in the firmware.

The identification unit 15c also identifies the version number of the extracted software (step S3). Specifically, the identification unit 15c extracts a character string from the extracted file and identifies the version number of the software corresponding to the file.

For example, the identification unit 15c identifies the version number of the software by using at least one of static analysis, which extracts a string of human-readable characters in a file, and dynamic analysis, which extracts a string output by executing the file. The identification unit 15c then identifies the software name and software version number for the extracted string using regular expressions.

Then, the discrimination unit 15d discriminates whether or not there is a difference between the software whose version numbers are the same before and after the chronological order (step S4). Specifically, the discrimination unit 15d discriminates that there is a difference when the hash values and program structures are different between files representing software whose version information is the same before and after the chronological order.

The discrimination unit 15d also discriminates that the program structures are different when code has changed between files representing software that have the same version information arranged in chronological order, or when code exists in only one of the files.

Then, the comparison unit 15e excludes the software determined to have a difference and compares the software included in the firmware with the CVE (step S5). In other words, the comparison unit 15e excludes software to which a patch that fixes a vulnerability has been applied from comparison with the CVE. This completes a series of detection processes.

[effect]
As described above, in the detection device 10, the collection unit 15a collects predetermined firmware. The extraction unit 15b extracts files representing software included in the firmware. The identification unit 15c identifies the version number of the extracted software. The discrimination unit 15d discriminates whether there is a difference between software with the same version number arranged in chronological order.

Specifically, the identification unit 15c identifies the version number of the software by using at least one of static analysis, which extracts a string of human-readable characters in the file, and dynamic analysis, which extracts a string output by executing the file.

The discrimination unit 15d also determines that there is a difference when the hash values and program structures are different between software that has the same version information arranged in chronological order.

The discrimination unit 15d also discriminates that the program structures are different when code has changed between files representing software that have the same version information arranged in chronological order, or when code exists in only one of the files.

Here, in a conventional system where the name and version number of installed software are properly managed by the system administrator, the presence or absence of vulnerabilities can be accurately determined by comparing with the CVE. In addition, if the system administrator keeps a record of patch application for vulnerabilities, the occurrence of false positives can be detected.

On the other hand, IoT owners generally cannot individually manage the software names and version numbers of software that runs on the IoT, or manage updates, etc. for each piece of software, and can only update using firmware provided by the vendor. Therefore, it is difficult for IoT owners to investigate whether software running on the IoT has vulnerabilities.

In contrast, the detection device 10 of this embodiment can estimate software to which a patch that fixes a vulnerability has been applied. Therefore, by excluding software to which a patch has been applied and comparing it with the CVE, it is possible to accurately detect whether or not software running on the IoT has vulnerabilities.

The comparison unit 15e also excludes software determined to have differences and compares the software included in the firmware with the vulnerability database. This enables the detection device 10 to avoid falsely detecting the presence of vulnerabilities by comparing software to which a patch that fixes vulnerabilities has been applied with the CVE.

[program]
A program in which the process executed by the detection device 10 according to the above embodiment is written in a language executable by a computer can also be created. As an embodiment, the detection device 10 can be implemented by installing a detection program that executes the above detection process as package software or online software on a desired computer. For example, the above detection program can be executed by an information processing device, causing the information processing device to function as the detection device 10. In addition, the information processing device also includes mobile communication terminals such as smartphones, mobile phones, and PHS (Personal Handyphone System), as well as slate terminals such as PDA (Personal Digital Assistant). The function of the detection device 10 may also be implemented on a cloud server.

Figure 9 is a diagram showing an example of a computer that executes a detection program. The computer 1000 has, for example, a memory 1010, a CPU 1020, a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. Each of these components is connected by a bus 1080.

The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012. The ROM 1011 stores a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1031. The disk drive interface 1040 is connected to a disk drive 1041. A removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1041. The serial port interface 1050 is connected to a mouse 1051 and a keyboard 1052, for example. The video adapter 1060 is connected to a display 1061, for example.

Here, the hard disk drive 1031 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. Each piece of information described in the above embodiment is stored, for example, in the hard disk drive 1031 or memory 1010.

The detection program is stored in the hard disk drive 1031, for example, as a program module 1093 in which instructions to be executed by the computer 1000 are written. Specifically, the program module 1093 in which each process executed by the detection device 10 described in the above embodiment is written is stored in the hard disk drive 1031.

In addition, data used for information processing by the detection program is stored as program data 1094, for example, in the hard disk drive 1031. Then, the CPU 1020 reads the program module 1093 and program data 1094 stored in the hard disk drive 1031 into the RAM 1012 as necessary, and executes each of the procedures described above.

The program module 1093 and program data 1094 related to the detection program are not limited to being stored in the hard disk drive 1031, but may be stored in a removable storage medium, for example, and read by the CPU 1020 via the disk drive 1041 or the like. Alternatively, the program module 1093 and program data 1094 related to the detection program may be stored in another computer connected via a network such as a LAN (Local Area Network) or a WAN (Wide Area Network), and read by the CPU 1020 via the network interface 1070.

The above describes an embodiment of the invention made by the inventor, but the present invention is not limited to the description and drawings that form part of the disclosure of the present invention according to this embodiment. In other words, other embodiments, examples, operational techniques, etc. made by those skilled in the art based on this embodiment are all included in the scope of the present invention.

REFERENCE SIGNS LIST 10 Detection device 11 Input unit 12 Output unit 13 Communication control unit 14 Storage unit 14a Firmware table 14b File table 15 Control unit 15a Collection unit 15b Extraction unit 15c Identification unit 15d Discrimination unit 15e Collation unit

Claims (6)

A collection unit that collects predetermined firmware;
an extracting unit that extracts a file representing software included in the firmware;
An identification unit that identifies a version number of the extracted software;
a determination unit that determines whether or not there is a difference between two pieces of software having the same version number arranged in chronological order;
a comparison unit that compares software included in the firmware with a vulnerability database, excluding software determined to have the difference;
A detection device comprising: The detection device according to claim 1, characterized in that the identification unit identifies the version number of the software by using at least one of static analysis, which extracts a string of human-readable characters in the file, and dynamic analysis, which extracts a string output by executing the file. The detection device according to claim 1, characterized in that the discrimination unit discriminates that the difference exists when the hash value and program structure are different between software whose previous and next version information arranged in the chronological order are the same. The detection device according to claim 3, characterized in that the discrimination unit discriminates that the program structures are different when code has changed between files representing software that have the same version information arranged in chronological order, or when code exists in only one of the files. A detection method performed by a detection device, comprising:
A collection step of collecting predetermined firmware;
an extraction step for extracting a file representing software included in the firmware;
identifying a version number of the extracted software;
a determination step of determining whether or not there is a difference between the software having the same version number arranged in chronological order;
a comparison step of excluding the software determined to have the difference and comparing the software included in the firmware with a vulnerability database;
A detection method comprising: A collection step of collecting predetermined firmware;
an extraction step for extracting a file representing software included in said firmware;
identifying a version number of the extracted software;
a determination step of determining whether or not there is a difference between the software having the same version number before and after the software arranged in chronological order;
a comparison step of comparing software included in the firmware with a vulnerability database, excluding the software determined to have the difference;
A detection program for causing a computer to execute the above.

Images