DETECTION APPARATUS, DETECTION METHOD, AND DETECTION PROGRAM

Abstract

To enable accurate detection of the presence / absence of vulnerability in software running on the IoT.SOLUTION: A collection unit 15a collects predetermined firmware. An extraction unit 15b extracts files representing software included in the firmware. An identification unit 15c identifies a version number of the extracted software. A determination unit 15d determines the presence / absence of difference between consecutively positioned pieces of software in a chronological order having the same version number.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to a detection device, a detection method, and a detection program. [Background technology]

[0002] Generally, in embedded systems such as the Internet of Things (IoT), firmware containing various software is used to control the hardware. Since most of this software uses Open Source Software (OSS), which is often found to have vulnerabilities, the IoT is also vulnerable.

[0003] 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). CVE registers the names and version numbers of software with vulnerabilities, and by checking the software name and version number against CVE, it is possible to know whether or not there is a vulnerability.

[0004] Furthermore, when software has vulnerabilities, the software is often updated to increase the version number after correcting the part causing the vulnerability. [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] “CVE”, [online], October 2021, [Retrieved January 18, 2022], Internet<URL:https: / / cve.mitre.org> [Non-Patent Document 2] “OWASP Dependency-Check”, [online], OWASP, [Retrieved January 18, 2022], Internet<URL:https: / / www.owasp.org / index.php / OWASP_Dependency_Check> Summary of the Invention [Problem to be solved by the invention]

[0006] However, with conventional technology, it is difficult to detect the presence or absence of vulnerabilities in software that runs on IoT. 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, if the software name and version number are compared with the CVE, it will be 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.

[0007] The present invention has been made in consideration of the above, and aims to accurately detect the presence or absence of vulnerabilities in software running on the IoT. [Means for solving the problem]

[0008] In order to solve the above-mentioned problems and achieve the objective, the detection device of the present invention is characterized by having a collection unit that collects specified 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 determines whether or not there is a difference between software with the same version numbers arranged in chronological order. Effect of the Invention

[0009] According to the present invention, it is possible to accurately detect whether or not there is a vulnerability in software that runs on the IoT. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a diagram for explaining an overview of the detection device. [Diagram 2] FIG. 2 is a schematic diagram illustrating a schematic configuration of the detection device. [Diagram 3] FIG. 3 is a diagram illustrating an example of the data configuration of the firmware table. [Figure 4] FIG. 4 is a diagram illustrating an example of the data structure of the file table. [Diagram 5] FIG. 5 is a diagram for explaining the process of the identification unit. [Figure 6] FIG. 6 is a diagram for explaining the process of the determination unit. [Figure 7] FIG. 7 is a diagram for explaining the process of the determination unit. [Figure 8] FIG. 8 is a flowchart showing the procedure of the detection process. [Figure 9] FIG. 9 is a diagram illustrating a computer that executes a detection program. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. Note that the present invention is not limited to this embodiment. In addition, in the description of the drawings, the same parts are indicated by the same reference numerals.

[0012] [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 CVE matching, thereby preventing false detection of vulnerabilities.

[0013] For example, as shown in Figure 1, for firmware F1 and F2 with consecutive version numbers of IoT products, the software name and version number 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 Figure 1, it is determined whether a patch to fix the vulnerability has been applied.

[0014] 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 has been 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.

[0015] The detection device can avoid false positives about the presence or absence of vulnerabilities by excluding software that it determines has had a patch applied from the targets of CVE comparison.

[0016] [Detection device configuration] 2 is a schematic diagram illustrating a schematic configuration of a detection device. As illustrated in FIG. 2, a detection device 10 of this embodiment 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.

[0017] The input unit 11 is realized by using input devices such as a keyboard and a mouse, and inputs various instruction information such as a command to start processing to the control unit 15 in response to an input operation 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 a detection process described below.

[0018] 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 an external device via an electric communication line 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 or the like that provides firmware for IoT products.

[0019] 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 a processing program for operating 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.

[0020] In this embodiment, the storage unit 14 stores a firmware table 14a, a file table 14b, etc. Note that these various pieces of information are not limited to being stored in the storage unit 14 of the detection device 10, and may be collected, for example, when a detection process described later is executed.

[0021] 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 of an IoT product, a firmware version number, and a firmware release date. Fig. 3 illustrates, for example, the firmware version number "FW_ABC_001" and the firmware release date "2020 / 01 / 10" of the firmware for an IoT product with a product name "P_ABC".

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

[0023] 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 a detection process described later, and is stored in the storage unit 14.

[0024] For example, FIG. 4 shows that a software file included in firmware with firmware version number "FW_ABC_001" has a file ID of "SW_ABC_001_0001," a software name of "httpserver," and a software version number of "1.1.0."

[0025] 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 a 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.

[0026] 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 an IoT product via the input unit 11 or the communication control unit 13. The meta-information includes a product name, a firmware version number, and a 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 described below.

[0027] The collection unit 15a may immediately transfer the collected firmware to the extraction unit 15b without storing the firmware in the storage unit 14 as the firmware table 14a.

[0028] The extracting unit 15b extracts files representing software included in the firmware. Specifically, the extracting unit 15b unpacks the firmware acquired from the collecting unit 15a and extracts files included in the firmware. For example, the extracting unit 15b extracts files that are executable programs, such as ELF files in the case of Linux (registered trademark).

[0029] Furthermore, the extraction unit 15b accumulates the file IDs and firmware version numbers of the extracted files in the storage unit 14 as a file table 14b, as shown in FIG.

[0030] 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.

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

[0032] 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[az]*$" is used to identify the matching character string "OpenSSL 1.0.21" from among the extracted character strings. This identifies the software name "OpenSSL" and the software version number "1.0.21".

[0033] Furthermore, as shown in FIG. 4, the identifying unit 15c additionally registers the identified software name and software version number in the file table 14b.

[0034] Returning to the explanation of Fig. 2, the determination unit 15d determines whether or not there is a difference between two pieces of software that have the same version numbers arranged in chronological order.

[0035] 6 and 7 are diagrams for explaining the process of the discrimination unit. First, the discrimination unit 15d arranges the software names and software version numbers in chronological order based on the release dates of the firmware. 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 is a difference between the pairs of files of the previous and next pieces of software.

[0036] Specifically, the determining unit 15d determines that there is a difference when the hash values ​​and program structures of software that have the same version information arranged in chronological order are different from each other.

[0037] 6 illustrates an example of version numbers and hash values ​​of software X arranged in chronological order based on firmware updates. The determination unit 15d determines the version numbers and hash values ​​of N pieces of firmware F1, F2, ..., F N For each, firmware F n and firmware F n+1 and extracts pairs of files that have the same version number of software X but different hash values.

[0038] 6, the processing is completed for F1 and F2 because the version numbers are different. Next, the version numbers 2.1 and F3 are the same, but the hash values ​​are different, so the pair is extracted as a processing target for the discrimination unit 15d.

[0039] Furthermore, when the extracted pair further has a different program structure, the discrimination unit 15d determines that there is a difference. In this case, the discrimination unit 15d estimates that a patch that fixes a vulnerability has been applied to the latter file.

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

[0041] A process of determining whether or not there is a difference in program structure is illustrated in Fig. 7. In the example illustrated in Fig. 7, the determination unit 15d compares the program structures of two source codes obtained by disassembling the binary files 1 and 2, respectively, to determine whether or not there is a difference.

[0042] 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 code or when a specific code exists only on 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 exists only on one side.

[0043] Furthermore, the discrimination unit 15d additionally registers the presence or absence of a difference in the file table 14b, as exemplified 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 subsequent file.

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

[0045] [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 starts, for example, when an operation input is made to instruct the start of the detection process.

[0046] First, the collection unit 15a collects predetermined 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.

[0047] Next, the extracting unit 15b extracts files representing software included in the firmware (step S2). Specifically, the extracting unit 15b unpacks the firmware acquired from the collecting unit 15a and extracts files that are executable programs included in the firmware.

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

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

[0050] Then, the determination unit 15d determines whether or not there is a difference between the software having the same version numbers arranged in chronological order (step S4). Specifically, the determination unit 15d determines that there is a difference when the hash values ​​and program structures are different between files representing software having the same version information arranged in chronological order.

[0051] In addition, the discrimination unit 15d 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.

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

[0053] [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.

[0054] 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 readable characters within a file, and dynamic analysis, which extracts a string output by executing the file.

[0055] Furthermore, when the hash values ​​and program structures of software that have the same version information arranged in chronological order are different, the determining unit 15d determines that there is a difference.

[0056] In addition, the discrimination unit 15d 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.

[0057] In the past, in systems where the names and version numbers of installed software were properly managed by the system administrator, the presence or absence of vulnerabilities could be accurately determined by checking against CVE. In addition, if the system administrator keeps a record of patch application for vulnerabilities, the occurrence of false positives can be detected.

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

[0059] In contrast, the detection device 10 of the present 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 CVE, it becomes possible to accurately detect the presence or absence of vulnerabilities in software that runs on IoT.

[0060] In addition, the collation unit 15e excludes software determined to have a difference and compares the software included in the firmware with the vulnerability database. This enables the detection device 10 to avoid erroneously detecting the existence of a vulnerability by comparing software to which a patch for fixing a vulnerability has been applied with the CVE.

[0061] [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 PDAs (Personal Digital Assistants). The functions of the detection device 10 may be implemented in a cloud server.

[0062] 9 is a diagram showing an example of a computer that executes a detection program. The computer 1000 includes, 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. These components are connected by a bus 1080.

[0063] 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 an 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.

[0064] 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 embodiments is stored in the hard disk drive 1031 or memory 1010, for example.

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

[0066] Furthermore, 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 out the program module 1093 and the program data 1094 stored in the hard disk drive 1031 into the RAM 1012 as necessary, and executes each of the above-mentioned procedures.

[0067] 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, and may be stored in, for example, a removable storage medium 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.

[0068] Although the embodiment to which the invention made by the present inventor is applied has been described above, the present invention is not limited by the description and drawings which form a part of the disclosure of the present invention according to the present embodiment. In other words, other embodiments, examples, operation techniques, etc. made by those skilled in the art based on the present embodiment are all included in the scope of the present invention. [Explanation of symbols]

[0069] 10. Detection Device 11 Input section 12 Output section 13 Communication control section 14 Storage section 14a Firmware Table 14b File Table 15 Control section 15a Collection Section 15b Extraction part 15c Specific part 15d Discrimination part 15e Matching section

Claims

1. 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:

2. 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 a static analysis that extracts a string of human-readable characters in the file and a dynamic analysis that extracts a string output by executing the file.

3. The detection device according to claim 1 , wherein the discrimination unit discriminates that a difference exists when a hash value and a program structure are different between software having the same version information arranged in chronological order.

4. 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.

5. A detection method performed by a detection device, comprising: A collection step of collecting predetermined firmware; an extraction step of 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:

6. A collection step of collecting predetermined firmware; an extraction step for extracting a file representing software contained 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