Threat factor detection system and detection method through comparative analysis of SBOM infrastructure installation files from the consumer's perspective

Abstract

The present invention relates to a threat factor detection system and detection method through comparative analysis of SBOM-based installation files from the consumer's perspective, which can analyze software patch files to determine whether or not malicious code exists. The system and method include the type of API function for executing the installation file installed on the client terminal and the SBOM (Software Bill of Materials) regarding the parameters of the API function at the time of calling the API function. a reference information DB that stores information about API functions (API materials) for executing a target installation file as previous component information, and SBOM information about the type of API function for executing the target installation file and the parameters of the API function at the time of calling the API function as next component information; a component disassembly module that extracts components of the installation file input to the client terminal; an API information extraction module that checks the API function to extract the SBOM of the component, checks the API function to be monitored that is called when malicious code is executed by setting a state value for the API function, extracts the code block of the API function to be monitored by linking with a disassembler, checks the parameters at the time of calling by tracing back the code call information for the code block of the API function to monitor, generates SBOM information about the type of API function and the parameters of the checked API function as next component information, and stores the SBOM information in the reference information DB; and a comparison and analysis module that compares the next component information generated by the API information extraction module with the previous component information of the target API function to check whether they match.

Description

[Technical Field]

[0001] The present invention relates to a threat factor detection system and method through SBOM-based file comparison analysis from a consumer perspective, which can analyze software patch files to determine whether or not malicious code exists. [Background technology]

[0002] Software suppliers provide patch files to ensure stable software operation when adding, changing, or removing software features. However, with the advent of the IoT environment, various unverified files are being indiscriminately distributed across networks, and there have been cases of modified files being distributed even on trusted servers. For example, malicious code disguised as information files related to the recent North Korea-US summit was distributed, and recently, malicious code has been distributed in large quantities via torrents.

[0003] When major software providers such as Microsoft, Adobe, and Hancom provide update services or security patches, users typically access and download the patch files from the providers. However, attackers have recently infiltrated software providers and inserted malicious code into the patch files they distribute, indirectly attacking all of the software's customers. In this case, the traditional method of checking whether the patch file contains malicious code was not enough to detect the threat posed by the malicious code in advance, ultimately causing significant damage to the many users to whom the patch files were distributed.

[0004] This malicious code not only exploits new, unknown, zero-day vulnerabilities, but also exploits vulnerabilities that have been previously patched. In particular, in the case of a company, if a patch file infected with malicious code is distributed to all clients within the company via the internal network, it could cause enormous damage.

[0005] This created an urgent need for security technology that could precisely analyze the patch file itself and determine in advance whether or not it was infected with malicious code. Summary of the Invention [Problem to be solved by the invention]

[0006] Therefore, the present invention has been invented to solve the above-mentioned problems, and aims to provide a threat factor detection system and detection method through comparative analysis of SBOM-based installation files from the consumer's perspective, which detects malicious code hidden in software patch files from the consumer's perspective and enables countermeasures for data security. [Means for solving the problem]

[0007] In order to achieve the above object, the present invention provides: A reference information DB that stores the type of API function for executing the installation file installed in the client terminal and SBOM (Software Bill of Materials) information on the parameters of the API function at the time of calling the API function as previous component information, and stores the type of API function for executing the installation file to be checked and SBOM information on the parameters of the API function at the time of calling the API function as next component information; a component decomposition module for extracting components from the installation file input to the client terminal; an API information extraction module that checks API functions to extract the SBOM of the component, checks API functions to be monitored that are called when malicious code is executed by setting a state value for the API function, extracts code blocks of the API functions to be monitored through linkage with a disassembler, traces back code call information for the code blocks of the API functions to check parameters at the time of call, generates SBOM information about the type and parameters of the API functions whose parameters have been checked as next component information, and stores the generated SBOM information in a reference information DB; and a comparison and analysis module that compares the next component information generated by the API information extraction module with the previous component information of the corresponding API function to check whether they match; It is a threat factor detection system through comparative analysis of SBOM-based installation files from the consumer's perspective. [Effects of the Invention]

[0008] The present invention compares a normal patch file and a new patch file for software by breaking them down to the API level, thereby determining whether malicious code exists by checking for risky actions such as changes in file format or the calling of new API functions, and thus preventing the installation of risky patch files during the patching process for the target software. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a block diagram illustrating the configuration of a detection system according to the present invention; [Figure 2] 1 is a flowchart illustrating a detection method performed on the basis of the detection system according to the present invention; [Figure 3] 3 is a flowchart specifically illustrating the component extraction step shown in FIG. 2; [Figure 4] 3 is a flowchart specifically illustrating the component analysis step illustrated in FIG. 2; [Figure 5] 3 is a flowchart specifically illustrating the parameter extraction analysis step shown in FIG. 2; [Figure 6] 3 is a flowchart specifically illustrating the parameter comparison step shown in FIG. 2. DETAILED DESCRIPTION OF THE INVENTION

[0010] The present invention will now be described in detail with reference to the accompanying drawings, in which: FIG.

[0011] FIG. 1 is a block diagram illustrating the configuration of a detection system according to the present invention, and FIG. 2 is a flowchart illustrating a detection method performed based on the detection system according to the present invention.

[0012] Referring to Figures 1 and 2, the detection system 10 according to the present invention is composed of a reference information DB 11, a component decomposition module 12, an API information extraction module 13, and a comparison analysis module 14, which operate based on the OS (Operating System) of the client terminal C.

[0013] The reference information DB 11 stores SBOM (Software Bill of Materials) information regarding the type of API function for executing an existing patch file installed on the client terminal C and the parameters (call factors) of the API function at the time of calling the API function as previous component information, and stores SBOM information regarding the type of API function for executing a patch file to be checked and the parameters of the API function at the time of calling the API function as next component information. The previous component information and next component information may also include the number of calls for each API function. The previous component information is used as reference information for determining whether the next component information checked in a new patch file is malicious. Meanwhile, the detection system 10 according to the present invention may specify all patch files of software as check targets, or may specify only patch files suspected of posing a threat as check targets. For reference, in this embodiment, the previous component information is stored separately for each software. In the description of the present invention, a patch file is one example of an installation file installed on the terminal C, and the installation file may be a program that performs a specific function in conjunction with the OS 20 of the terminal C. In this embodiment, the installation file is described as a patch file, but the installation file is not limited to this, and the scope of the claims claims the name "installation file," which is a representative name that can encompass one program.

[0014] The component disassembly module 12 disassembles a patch file input to the client terminal C into components for updating specific software. To this end, the component disassembly module 12 extracts components not only through an installer or decompressing a compressed file, but also through sandbox execution, etc.

[0015] To check whether a patch file is infected with malicious code, the API information extraction module 13 checks API functions and extracts parameters from the execution component among the disassembled components to extract SBOM. To extract and check API function parameters, the API information extraction module 13 adds a status value to the API function to extract API functions called when malicious code is executed and designates the API functions as API functions to be monitored. The module also prioritizes extracting entire code blocks from the API functions to be monitored. In this embodiment, code block extraction is performed using disassembler software such as IDA (Interactive DisAssembler) or GHIDRA. For reference, a disassembler generates assembly language source code from machine code and supports various operating systems and executable files. The code block refers to machine code consisting of a combination of binary digits.

[0016] Thereafter, the API information extraction module 13 traces back the code call information of the code block, checks the parameters at the time the caller calls the actual API function, and records the parameter information in the analysis report (next component information). In this embodiment, the traceback of the code call information uses an extension script engine (IDA-PYTHON (registered trademark)) provided by disassemblers such as IDA and GHIDRA. For reference, the extension script engine controls metadata such as code blocks, variables, and IDA state values ​​provided by IDA in the Python language.

[0017] The API information extraction module 13 repeatedly extracts parameters until there is no code block of the API function to be monitored, and generates information about the type and parameters of the API function to be monitored as next component information and stores it in the reference information DB.

[0018] The comparison analysis module 14 compares the previous component information stored in the reference information DB 11 with the next component information recorded as an analysis report by the API information extraction module 13 to check for changes, and stores the changed parts as changed values. If any items suspected to be dangerous are found among the differences or changes between the previous component information and the next component information, the related details are recorded as result values.

[0019] A method for detecting a threat factor based on the detection system 10 according to the present invention will now be described.

[0020] FIG. 2 is a flowchart illustrating a detection method performed on the basis of the detection system according to the present invention.

[0021] 1 and 2, the detection method according to the present invention includes a component extraction step S10 for breaking down a patch file into components and extracting them, a component analysis step S20 for checking API functions to extract SBOMs from the extracted components, a parameter extraction step S30 for extracting parameters from the API functions of all components extracted from the patch file or components suspected of containing malicious code, and a parameter comparison step S40 for comparing the extracted parameters with reference information (previous component information) to check for changes. Here, the parameter comparison step S40 may further include a step of transmitting changes to the next component information based on the reference information to a server S of a supplier of the patch file for confirmation.

[0022] The detection system 10 and detection method of the present invention extracts the SBOM (Software Bill of Materials) of previous component information from the previous patch file installed on the client terminal C of the user corresponding to the application consumer, and when an attempt is made to install a patch file to be checked on the client terminal C thereafter, the SBOM of the next component information from the patch file to be checked is extracted and compared, thereby enabling proactive metadata comparison from the consumer's (user's) perspective. In other words, the consumer (user) is able to proactively determine whether the patch file is abnormal and prevent infection of the client terminal C in advance, rather than relying solely on the supplier's judgment of whether the patch file is dangerous.

[0023] In addition, the detection system 10 and the detection method of the present invention communicate with the supplier's server S through a communication medium such as the cloud, allowing the consumer (user) to directly participate and communicate in the decision-making process between the software developer and the operation manpower regarding whether or not there is an abnormality in the patch file on the supplier's server S in an SDLC (Software Development Life Cycle) environment that performs the SBOM function.

[0024] FIG. 3 is a flowchart specifically illustrating the component extraction step shown in FIG.

[0025] Referring to Figures 1 to 3, the component extraction step S10 in the detection method of the present invention includes an installer verification step S11, an installer deactivation step S12, an installed component extraction step S13, a compressed file verification step S14, a compressed file deactivation step S15, a transfer to sandbox step S16, a macro script execution step S17, and an overall component list verification step S18.

[0026] To explain the component extraction step S10 in more detail, the component disassembly module 12 of the detection system 10 detects an installer from a patch file received from the supplier server S (S11). If the installer of the patch file is confirmed as a result of the detection, the component disassembly module 12 decomposes the installer (S12) and extracts all component information for the client terminal C (S13). Here, disassembling the installer does not mean executing the installer, but rather disassembling the installer to extract the components comprised in the corresponding patch file. Generally, an installer is a main component with the extension *.exe, and the component disassembly module 12 decomposes the installer to extract the sub-components comprised in the main component.

[0027] On the other hand, if the component disassembly module 12 cannot recognize a specific component as an installer from the patch file, it subsequently detects whether the patch file is a compressed file (S14). If it is determined from the patch file as a result of the detection that it is a compressed file, it decompresses the compressed file (S15).

[0028] If the installer and compressed files are not all recognized from the patch file, the component disassembly module 12 executes a sandbox process for virtual execution of the patch file. In the sandbox process, the component disassembly module 12 activates a sandbox mode, copies the patch file to the sandbox (S16), and executes a dedicated script to execute the patch file in sandbox mode (S17). The component disassembly module 12 of the present invention automatically executes the patch file in sandbox mode using a mouse macro script.

[0029] As described above, if the installer and compressed files are not recognized and the entire installation file for terminal C cannot be extracted, the component disassembly module 12 of the present invention performs the process of installing the actual patch file in a sandbox (virtual environment). Generally, to install software on a computer, an operator must follow the procedure and click the corresponding menu with a mouse. However, since the patch file installation process in a sandbox environment is performed in an environment isolated from the outside, the installation process must be executed without operator intervention. To this end, the component disassembly module 12 executes a mouse macro script to generate mouse click effects in accordance with the installation process.

[0030] Next, the component disassembly module 12 tracks the installation process of the patch file installed in the sandbox mode and checks the list of all installed components (S18). As a result, the component disassembly module 12 can extract, check, and list the components configured in the patch file.

[0031] FIG. 4 is a flowchart specifically illustrating the component analysis steps shown in FIG.

[0032] Referring to Figures 1 to 3, the component analysis step S20 in the component detection method according to the present invention includes an API function call step S21, a step S22 of checking whether an API function that is activated when malicious code is executed is being executed, a state value addition step S23, and a step S24 of checking whether a component to be analyzed is present.

[0033] More specifically, the component analysis step S20 involves the API information extraction module 13 extracting callable API functions from the components extracted by the component decomposition module 12 (S21). During the extraction, the API information extraction module 13 checks for the presence of API functions that are activated when malicious code is executed (hereinafter, "monitored API functions") by additionally setting state values. If no API functions are detected, the component analysis process is terminated (S22). The module also checks the number of API function calls to determine whether the number of calls to key API functions exceeds a reference value. If a monitored API function is detected or if the number of calls to a specific API function exceeds a reference value, the API information extraction module 13 sets an IDA state value for parameter extraction of the corresponding API function (S23). The API information extraction module 13 continuously analyzes other execution components configured in the patch file to confirm the extraction of the monitored API function. If no other execution components are detected, the module terminates the process of identifying the monitored API function and setting the IDA state value for parameter extraction (S24).

[0034] FIG. 5 is a flowchart specifically illustrating the parameter extraction analysis steps shown in FIG.

[0035] 1-2 and 4-5, the parameter extraction step S30 in the component detection method according to the present invention includes a code block extraction step S31, a step S32 of checking whether a major API function to be monitored is executed, a code call information back-tracing step S33, a call time parameter extraction step S34, and a step S35 of checking whether a code block exists.

[0036] More specifically, the parameter extraction step S30 involves the API information extraction module 13 analyzing the API functions to be monitored extracted in the component analysis step S20 to extract code blocks (S31). Of all the API functions configured as components of the patch file, the API functions to be monitored for parameter extraction are the API functions to be monitored. The API information extraction module 13 then checks whether the API functions are the API functions to be monitored identified through the additional setting of state values. If they are not the API functions, the parameter extraction process is terminated (S32). However, if the API functions are identified as the API functions to be monitored, the API information extraction module 13 reverse-traces the code call information of the code blocks to extract parameters at the time of the call (S33). The parameter information is then included in the next component information corresponding to the analysis report and recorded and stored in the reference information DB 11 (S34). In this embodiment, the next component information is stored separately for each related software.

[0037] Thereafter, the API information extraction module 13 repeatedly extracts parameters from the monitored API function until there are no more code blocks to be analyzed (S35). FIG. 6 is a flowchart specifically illustrating the parameter comparison step shown in FIG.

[0038] 1-2 and 5-6, the parameter comparison step S40 in the component detection method according to the present invention includes a reference information DB checking step S41, a previous component information search step S42, a next component information checking step S43, a next component information search step S44, a parameter information checking step S45, and a change item checking step S46.

[0039] More specifically, the parameter comparison step S40 is described in detail in the reference information DB confirmation step S41. The step checks whether previous component information, which is an analysis report stored in advance as reference information, has been searched for. As described above, component information related to the type, number of calls, and all parameters (call factors) of API functions called at the time of call, among API functions of components configured in the old version patch file, that are suspected of being threats and designated as monitoring targets, is stored as previous component information, and the previous component information is designated as reference information. If an order for comparing the next component information with the reference information is not entered, the parameter comparison process ends.

[0040] In the previous component information search step S42, in order to search for previous component information, which is reference information, the comparison analysis module 14 checks the corresponding software and searches the reference information DB 11 for reference information of the same type.

[0041] In the next component information confirmation step S43, it is confirmed whether or not the next component information, which is the analysis report corresponding to the reference information, is searched. If the search order of the next component information is not input for comparison with the reference information, the parameter comparison process ends.

[0042] In the next component information search step S44, the comparison and analysis module 14 checks the corresponding software to search for the next component information, and searches the reference information DB 11 for the next component information of the same type.

[0043] In the parameter information confirmation step S45, the comparison and analysis module 14 confirms parameter information from the reference information (previous component information) and the next component information. The parameter information may be parameter information for all API functions configured in the component, or may be parameter information for an API function designated as a monitoring target. In this embodiment, the parameter information is the parameter information for the API function to be monitored.

[0044] In the change confirmation step S46, the comparison and analysis module 14 checks whether parameters have been changed based on the code call information of the code block for each API function. Here, the code call information may be the number of calls for each API function and the parameters (call factors) of the called API function. If the code call information in the reference information and the code call information in the next component information differ (change), the comparison and analysis module 14 may store the change as a change value, or may store only items that are suspected to be risky among the change items as a change value.

[0045] At the same time, the comparison and analysis module 14 connects to the supplier server S through a communication medium such as the cloud and transmits a change value that is a result of mutual comparison between the previous component information and the next component information.

[0046] In the above detailed description of the present invention, reference has been made to a preferred embodiment of the present invention, but it will be understood that a person skilled in the art or having ordinary knowledge in the art can make various modifications and changes to the present invention without departing from the spirit and technical scope of the present invention as set forth in the claims below.

Claims

1. a reference information DB that stores SBOM (Software Bill of Materials) information regarding the type of API function for executing an installation file installed in a client terminal and the parameters of the API function at the time of calling the API function as previous component information, and stores SBOM information regarding the type of API function for executing an installation file to be checked and the parameters of the API function at the time of calling the API function as next component information; a component decomposition module for extracting components from the installation file input to the client terminal; an API information extraction module that checks API functions to extract an SBOM of the component, checks API functions to be monitored that are called when malicious code is executed by setting a state value for the API function, extracts code blocks of the API functions to be monitored through linkage with a disassembler, traces back code call information for the code blocks of the API functions to check parameters at the time of the call, generates SBOM information on the type and parameters of the API functions whose parameters have been checked as next component information, and stores the generated SBOM information in a reference information DB; and a comparison and analysis module that compares the next component information generated by the API information extraction module with previous component information of the corresponding API function to determine whether they match; A threat factor detection system through comparative analysis of SBOM infrastructure installation files from a consumer perspective, comprising:

2. The component decomposition module: If the installer and the compressed file cannot be recognized from the installation file that comprises one or more selected installers and compressed files, activate the sandbox and execute the installation file using a mouse macro script to check the components to be installed in the sandbox mode; 2. The system for detecting threat factors through comparative analysis of SBOM infrastructure installation files from a consumer perspective according to claim 1.

3. The previous component information and the next component information include the number of calls for each API function, The API information extraction module designates the API function as a monitoring target API function when it confirms that the number of calls of the API function is equal to or greater than a reference value; 2. The system for detecting threat factors through comparative analysis of SBOM infrastructure installation files from a consumer perspective according to claim 1.

4. The comparative analysis module: Specifying the previous component information as a change value for the next component information, and transmitting the change value to the supplier's server; 2. The system for detecting threat factors through comparative analysis of SBOM infrastructure installation files from a consumer perspective according to claim 1.

Images