Patent ID: 12242617

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

However, this is not intended to limit the present disclosure to the specific embodiments, and it is to be understood that the present disclosure includes all modifications, equivalents, and/or alternatives of embodiments of the present disclosure. Throughout the drawings, like reference numerals may refer to like components.

In this specification, the terms “comprise,” “comprising,” “include,” “including,” “have,” “having,” and the like indicate the presence of corresponding features (e.g., integers, functions, operations, steps, parts, elements, constituents, and/or the like) and do not preclude the presence or addition of additional features.

When a first component is referred to as being “connected” or “coupled” to a second component, the first component may be directly connected or coupled to the second component, or an intermediate component may be therebetween. On the other hand, when a first component is referred to as being “directly connected” or “directly coupled” to a second component, there is no intermediate component therebetween.

As used in various embodiments, expressions such as “first,” “second,” or the like may refer to a variety of components in any order and/or order of importance and do not limit the components. The terms are only used for the purpose of distinguishing one component from others. For example, a first component and a second component may represent different components irrespective of the order or importance of the components.

Singular expressions used in this specification also include plural expressions unless words related to the singular expressions explicitly indicate otherwise.

As used herein, the expression “configured to” may be interchangeably used with, for example, “suitable for,” “having the capacity to,” “designed to,” “adapted to,” “made to,” or “capable of” according to a situation. The term “configured to” does not always mean “specifically designed to” in hardware. Alternatively, in some situations, the expression “device configured to” may mean that the device is “capable of” something together with other devices or parts. For example, the phrase “processor configured to perform A, B, and C” may be an exclusive processor (e.g., an embedded processor) for performing the corresponding operations or a generic-purpose processor (e.g., a central processing unit (CPU) or an application processor) that performs the corresponding operations by executing one or more software programs stored in a memory device.

A system for detecting a vulnerability in software (e.g., firmware) installed on an Internet of things (IoT) device according to exemplary embodiments of the present disclosure is configured to detect a common weakness enumeration (CWE) of a program extracted from the software through taint analysis and symbolic execution at a binary code level. In the system, any external function implemented in the form of a library by a developer is regarded as a target of analysis, which creates more vulnerability analysis targets in an IoT device.

FIG.1is a diagram illustrating a network environment of a system for detecting a vulnerability in software installed on an IoT device according to an aspect of the present disclosure.

Referring toFIG.1, a system1for detecting a vulnerability in a program of an IoT device (hereinafter “vulnerability detection system”) includes an IoT device10, a user terminal50, and a vulnerability analysis device100(hereinafter “analysis device).

The vulnerability detection system1according to embodiments may be completely hardware or may have some hardware aspects and some software aspects. For example, “system” or “device” may collectively refer to hardware with a data processing capability and operating software for running the hardware. In this specification, the terms “unit,” “system,” “device,” and the like are intended to refer to a combination of hardware and software which is run by the hardware. For example, hardware may be a data processing device including a CPU, a graphics processing unit (GPU), or another processor. Also, software may be a running process, an object, an executable file, a thread of execution, a program, and the like.

The components10,50, and100of the system1are connected to each other through a wired/wireless communication network. For example, the communication network may be a local area network (LAN), a wide area network (WAN), a virtual network, a mobile network, such as third generation (3G), fourth generation (4G), or fifth generation (5G), remote communication, or the like, but is not limited thereto.

In various embodiments of the present disclosure, a communication network that connects the IoT device10and the user terminal50may differ from a communication network that connects the user terminal50and the analysis device100. For example, the communication network that connects the IoT device10and the user terminal50may have a shorter communication range than the communication network that connects the user terminal50and the analysis device100.

The IoT device10is an embedded device which may perform network communication. The IoT device10may be, for example, an access point (AP), a closed-circuit television (CCTV), a network-attached storage (NAS) device, a refrigerator, an air conditioner, or another IoT appliance on which firmware is installed, but is not limited thereto.

The user terminal50is a component that functions as a client device for the analysis device100in wired/wireless communication with the analysis device100.

The user terminal50may be a computing system that includes hardware, software, or embedded logic components or a combination of two or more components thereof and may perform appropriate functions implemented or supported by the user terminal50. The user terminal50may be, for example, a desktop computer, a laptop computer, a netbook, a tablet computer, an e-book reader, a Global Positioning System (GPS) device, a camera, a personal digital assistant (PDA), a portable electronic device, a cellular phone, a smartphone, another computing device, another mobile device, another wearable device, another appropriate electronic device including a processor, a memory, and a transceiver unit, or a computing system which is any appropriate combination thereof. However, these are merely examples, and the user terminal50may also be implemented in the form of a server that provides a different service from a service provided by the analysis device100(i.e., a vulnerability detection service) below.

In wired/wireless communication with the IoT device10, the user terminal50extracts a binary file of firmware installed on the IoT device10and provides the extracted binary file to the analysis device100as a target binary file that is to be analyzed for whether there is a vulnerability.

Also, the user terminal50may receive the analysis result of the analysis device100and output the analysis result.

According to various embodiments of the present disclosure, the system1may be configured to implement an input screen for providing the binary file to the analysis device100or an output screen for outputting the vulnerability analysis result to a user in the form of a webpage. The user terminal50may transmit and receive information to and from a server through the webpage.

Operations of the user terminal50will be described in detail below with reference toFIG.8and the like.

The analysis device100is a device that performs an operation of detecting a vulnerability in the target binary file.

According to various embodiments of the present disclosure, the analysis device100may be implemented as a device that is connected to the user terminal50and functions as a server. The analysis device100may be a unitary server or implemented as a distributed server spanning multiple computers or multiple datacenters. In various embodiments of the present disclosure, the analysis device100is multiple computer systems implemented as a network server or computer software. Here, the network server is a computer system and computer software (a network server program) that are connected to a sub-device, which may communicate with another network server, through a computer network, such as a private intranet or the Internet, to receive a task request, perform the task, and provide the result. In addition to such a network server program, the network server is to be understood as a broader concept that includes a set of application programs running on the network server and, in some cases, various databases (DBs) built therein. The server100may be implemented as any type of computing device, such as a network server, a web server, a file server, a supercomputer, a desktop computer, or the like, or a combination thereof. To this end, the analysis device100includes at least one processor for processing data, a memory for storing data, and a communication unit for transmitting and receiving data.

When the target binary file to be analyzed is received from the user terminal50, the analysis device100may detect a vulnerable function in the target binary file through taint analysis, generate a taint path to a user function by tracking a parameter of the detected vulnerable function, and analyze the taint path through symbolic execution to detect a vulnerability in the target binary file.

The analysis device100may report a vulnerability analysis result to the user through the user terminal50.

The taint path includes the user function, and the user function is a user input function which is an internal function of the software or a user library function based on an external library of the software.

The user function may be a user input function or a user library function. The user input function may be an internal function of firmware that is preset to request a user input. The user input function may be an internal function that is known to request a user input, for example, “scanf,” “fgets,” or the like. The user library function is an external function of the firmware that is implemented in the form of a library by the user or developer with reference to an external library.

The configuration and operations of the analysis device100will be described in further detail below with reference toFIGS.2to15.

FIG.2is a block diagram of an analysis device according to various embodiments of the present disclosure.

Referring toFIG.2, the analysis device100includes a communication unit110, a taint analysis unit130, a function DB140, a vulnerability analysis unit170, and a vulnerable pattern DB180. According to various embodiments of the present disclosure, the analysis device100may further include a preprocessing unit150.

The function DB140stores function-related information. For example, the function DB140may store a list of user functions and information related to the user functions in the list.

According to various embodiments of the present disclosure, the function DB140may include a vulnerable function list and a call function list. Each list includes information related to corresponding functions.

In some embodiments, the function DB140may further include a blacklist, a whitelist, and a function data list.

The lists stored in the function DB140will be described in further detail below.

The vulnerable pattern DB180includes vulnerable patterns for determining whether state information resulting from symbolic execution of the target binary file corresponds to the vulnerable patterns. The vulnerable patterns will be described in further detail below.

The DBs140and180are integrated with the analysis device100or implemented as a DB server outside of the analysis device100and connected to the analysis device100. In some embodiments, information stored in DBs may be structured according to a specific data structure. Each DB140or180may be a relational, column, correlation, or other appropriate DB. Although a specific type of DB is described or illustrated in this specification, any appropriate type of DB is taken into consideration. In some embodiments, the system1may provide an interface that allows management, search, change, addition, or deletion of information stored in the DB140or180through the analysis device100or the user terminal50.

For clarity of description, operations of the analysis device100are described with an embodiment in which the DBs140and180are integrated with the analysis device100, but it is apparent to those of ordinary skill in the art that this is illustrative.

The communication unit110may be a software or hardware module that performs a communication interface operation such as inputting data from an external device (e.g., the user terminal50) to the analysis device100or outputting data from the analysis device100.

The analysis device100may acquire the target binary file extracted from the firmware of the IoT device10through the communication unit110.

The taint analysis unit130is a component that analyzes a taint path from the target binary file by performing a taint analysis operation on the target binary file received by the communication unit110.

Taint analysis is an analysis method of determining whether elements are affected by another element and identifying the cause and influence of a problem using the case where elements are tainted by a suspicious element.

In various embodiments of the present disclosure, the taint analysis unit130may be configured to perform a static taint analysis operation. Static taint analysis is a data flow analysis technique for checking how a user input value flows in a program, which is used to statically detect a security vulnerability.

The taint analysis unit130ofFIG.2may be configured to designate a taint sink in the target binary file as a tracking starting point, generate a tracking graph by tracking a parameter from the taint sink, designate a taint source in the target binary file on the basis of the tracking graph and a call function which is preset to call the taint sink, and generate a path from the taint sink to the taint source in the tracking graph as a taint path. The taint analysis unit130may be further configured to generate information related to the taint path when the taint path is generated.

In various embodiments of the present disclosure, the taint analysis unit130may be configured to determine whether the target binary file includes at least one of vulnerable functions included in the prestored vulnerable function list to determine the position of the taint sink in the target binary file, and when a vulnerable function is included in the target binary file, designate the position of the included vulnerable function as the position of the taint sink.

The vulnerable function list is prestored in the function DB140. The vulnerable function list is a list of functions in which vulnerabilities may occur. The vulnerable function list may include one or more of, for example, system, execl, execlp, execv, execle, execve, popen, and do_system. However, the vulnerable functions in the vulnerable function list are illustrative and are not limited thereto.

The taint analysis unit130may determine whether each function used in the target binary file corresponds to a vulnerable function included in the vulnerable function list.

To generate the tracking graph, the taint analysis unit130may include an instruction analyzer132, an operation analyzer133, and an atom analyzer134. The taint analysis unit130may analyze the target binary file from the taint sink, which is the tracking starting point, on block-by-block, operation-by-operation, and atom-by-atom bases to track parameters logically connected to the taint sink and generate the tracking graph.

The instruction analyzer132process the target binary file on an instruction-by-instruction basis to divide the processed instructions into a left term and a right term, transmits one of the divided left and right terms including an operator to the operation analyzer133, and transmits the other of the divided left and right terms including no operator to the atom analyzer134.

For example, the instruction analyzer132may process code components, such as a=b, a=b+c, and a=call(b), on an instruction-by-instruction basis. In some embodiments, the instruction analyzer132may store an analysis log. The instruction analyzer132may determine whether an input instruction is an instruction included in the analysis log, and when the input instruction is an instruction included in the analysis log, may consider that an instruction that has already been analyzed has been input again and not perform an analysis operation.

The operation analyzer133processes the left term or right term on an operation-by-operation basis to determine whether a left-or right-term component is an operator and transmits the term component which is not the operator to the atom analyzer134. Since the term component which is not the operator is an argument, the operation analyzer133may classify a term component as an argument or an operator. For example, the operation analyzer133may process code components, such as a+b, a−b, and a % b on an operation-by-operation basis. Then, operators such as +, −, and % are distinguished from term components other than operators such as a and b, that is, arguments, and a and b are transmitted to the atom analyzer134.

The atom analyzer134processes an argument to be analyzed in the instruction on an atom-by-atom basis to classify the argument as a variable or constant. An atom unit may be one number, value, or symbol, or a combination of two or more thereof. For example, the atom analyzer134may process code components, such as a, &a, *a, and 1, on an atom-by-atom basis. In some embodiments, the atom analyzer134may store an analysis log. When a variable of a target of analysis is an already-analyzed variable, the atom analyzer134may not perform analysis. Specifically, when a specific argument is input as an argument to be analyzed, the atom analyzer134determines whether the argument is included in the analysis log. When the input argument is included in the analysis log, the atom analyzer134may consider that an instruction that has already been analyzed has been input again and not analyze the argument, and may not extend the tracking graph any more.

Also, when an argument to be analyzed is analyzed as a variable in the atom analyzer134, the atom analyzer134searches the target binary file for at least one instruction in which the argument analyzed as a variable is used and inputs each found instruction to the instruction analyzer132. Then, the taint analysis unit130may track each logical relationship with each input instruction in the code and continuously analyze taint propagation of the input instruction.

The taint analysis unit130may generate the tracking graph for generating a taint path on the basis of analysis results of the internal analyzers132to134. The tracking graph is a graph showing taint propagation from a vulnerable function.

FIG.3Ais a view of binary code of an exemplary target binary file from which a taint path will be generated, andFIG.3Bis a diagram illustrating a process of generating a tracking graph by analyzing the target binary file ofFIG.3Ausing an instruction analyzer, an operation analyzer, and an atom analyzer.

In the target binary file ofFIG.3A, it is assumed that a taint sink and a taint source are indicated by sink(c #1) and source(a #1), respectively.

The taint analysis unit130may specify the taint sink sinc(c #1) using a preset vulnerable function list.

Subsequently, the taint analysis unit130may generate a tracking graph which has the designated taint sink as a start point and specify a taint source. Specifically, as shown inFIG.3B, the taint analysis unit130starts tracking taint propagation from the instruction c #1=b #1 related to c #1, which is the argument of the taint sink, through the internal analyzers132,133, and134. The instruction c #1=b #1 is an instruction for defining c #1 which is the argument value of the taint sink inFIG.3A.

The instruction analyzer132divides the instruction c #1=b #1 in which the argument value of the taint sink, which is the start point of the taint path, is used into a left term and a right term and transmits both the left and right terms to the atom analyzer134because there is no operator in either of the left and right terms. The atom analyzer134determines whether the received analysis values of the instruction analyzer132, that is, the argument(s) of the left and right terms, are variables or constants. InFIG.3B, the argument c #1 of the left term has already been analyzed to determine a taint sink and thus may not be analyzed again. The atom analyzer134classifies the argument b #1 of the right term as a variable. Also, since the argument b #1 of the right term is a variable, the atom analyzer134searches the target binary file for the instructions c #1=b #1 and b #1=‘echo’+a #1 in which the variable b #1 is used, and transmits the instructions to the instruction analyzer132.

The instruction analyzer132may only analyze b #1=‘echo’+a #1 which is an instruction received from the atom analyzer134and not c #1=b #1 which has already been analyzed on an instruction-by-instruction basis, to divide the input instruction b #1=‘echo’+a #1 into left-and right-term components. The instruction analyzer132transmits the left-term component b #1 to the atom analyzer134because the left-term component b #1 only includes an argument, and transmits the right-term component ‘echo’+a #1 to the operation analyzer133because the right-term component ‘echo’+a #1 includes an operator. The operation analyzer133classifies components of the received right term ‘echo’+a #1 into an operator and components which are not operators, and transmits the components which are not operators, that is, arguments, ‘echo’ and a #1 to the atom analyzer134. The atom analyzer134does not analyze b #1 which has already been analyzed again. Also, the atom analyzer134analyzes ‘echo’ and a #1 and classifies ‘echo’ as a constant and a #1 as a variable. The atom analyzer134searches for the instructions source(a #1), b #1=‘echo’+a #1 in which the variable a #1 is used and transmits the instructions to the instruction analyzer132. Then, the instruction analyzer132analyzes source(a #1) among the received instructions and transmits the analysis result to the atom analyzer134, and the atom analyzer134may analyze the analysis result of the instruction analyzer132by processing the analysis result on an atom-by-atom basis.

The taint analysis unit130may extend the tracking graph by tracking a parameter which has not been analyzed. Extension of the tracking graph may be finished when analysis is finished up to an atom level.

In various embodiments of the present disclosure, to determine a taint source on the basis of a function for calling the taint sink and the tracking graph, the taint analysis unit130may compare all call instructions which are preset to call the taint sink in the call function with a call instruction in the tracking graph and determine a taint source corresponding to the taint sink on the basis of comparison results between the call instructions.

The end point of the tracking graph may not correspond to the position of the taint source. The taint source may be an intermediate point of the tracking graph.

When the comparison result is that the call instruction in the tracking graph matches at least one of the call instructions in the call function for calling the taint sink, the taint analysis unit130determines that a taint source is present in the tracking graph. The taint analysis unit130may designate the matching call instruction as a taint source corresponding to the taint sink. The taint source is the end point of the taint path. When the taint source is determined, the position of the taint source in the target binary file is also automatically determined.

The taint analysis unit 130 lists all call instructions [test_func($t9), source(a #1), sink(c #1), test_func2(d #1)] in example_func( ), which is a function for calling sink(c #1), in the binary code ofFIG.3Aand compares the call instructions with call instructions in the tracking graph. Since the tracking graph only has the call instruction source (a #1), the instruction source (a #1) is designated as a taint source.

As described above, the taint analysis unit130designates a taint sink rather than a taint source as a tracking starting point. Accordingly, even when there is no information related to a taint source at the time of starting a taint analysis operation, it is possible to start the taint analysis operation. Also, the taint analysis unit130can rapidly generate a taint path compared to other taint analysis methods in which a taint source is designated as a tracking starting point to track the propagation of tainted data from the taint source to a potentially vulnerable point.

In addition, the taint analysis unit130may perform a verification operation on the taint source designated as the end point of the taint path. Specifically, the taint analysis unit130may be further configured to redesignate the taint source on the basis of a preset blacklist.

As taint sources, the taint analysis unit130may designate functions included in the blacklist among all call functions in the tracking graph and the call functions other than a function designated as the taint sink. In other words, some call functions which are designated in advance as taint sinks may be excluded in the redesignation process.

In various embodiments of the present disclosure, to redesignate the taint source on the basis of the preset blacklist, the taint analysis unit130may be configured to cancel the designation of the taint source when the designated taint source includes at least one function in the preset blacklist after the taint source corresponding to the taint sink is designated, determine whether the tracking graph includes a different taint source from the canceled taint source, and redesignate the different taint source as the taint source corresponding to the taint sink when it is determined that the tracking graph includes the different taint source.

The blacklist is a list of functions that are not allowed to be designated as taint sources. The blacklist may include call functions that are not designated as taint sources. The blacklist is stored in the function DB140in advance. The blacklist may include one or more functions of, for example, “abs,” “across,” “asin,” “printLine,” “atan,” “atof,” “atoi,” “atol,” “bsearch,” “calloc,” “ceil,” “clearerr,” “cos,” “cosh,” “creatnew,” “creattemp,” “_C_Quickpool_Int,” and “_close.” However, functions in the blacklist are not limited thereto.

In the exemplary binary code ofFIG.3A, source (a #1) is designated as a taint source because source (a #1) happens to be the only call instruction. However, in an actual taint analysis process, all call instructions in the tracking graph may be designated as taint sources, which lead to overdetection. The taint analysis unit130can prevent overdetection by not designating all call instructions in a tracking graph as taint sources using the preset blacklist.

The taint analysis unit130may generate the taint path that has the taint sink as the start point and has the taint source as the end point. The taint analysis unit130may apply a designated taint sink and taint source to a preset path detection algorithm, generating a taint path that has the position of the taint sink as a start point and the position of the taint source as an end point. In some embodiments, the taint analysis unit130may generate a taint path using a breadth-first search algorithm.

Then, the taint analysis unit130may generate the taint path including instructions of a detected portion of the tracking graph from the taint sink to the taint source.

FIG.4is a diagram illustrating a taint path that is searched using a taint sink and a taint source ofFIG.3B.

Referring toFIG.4, the taint analysis unit 130 may generate a taint path [“c #1=b #1,” “b #1=‘echo’+a #1,” “source(a #1)”] including a designated taint source and taint sink and instructions therebetween from the tracking graph.

Also, the taint analysis unit130may generate information for symbolic execution on the basis of the taint path. The information for symbolic execution is information transmitted to the vulnerability analysis unit170and may be referred to as transmission information in this specification. The transmission information is information related to components (e.g., variables) in a taint path. The transmission information includes information required for the vulnerability analysis unit170to perform a symbolic execution operation. The transmission information includes identification information of the taint path and related information of the taint path.

In various embodiments of the present disclosure, the transmission information may include at least one of a call function of the taint sink, an address of the call function of the taint sink, a risk stage based on a taint analysis result, risk information based on the taint analysis result, an address of the taint source, an argument number of a decimal portion, an address of the taint sink, an argument number of the taint sink, and a size of the argument of the taint sink.

The taint analysis unit130may generate the risk stage and risk information of the taint path as taint analysis results. The risk stage and risk information may be included in the transmission information of the taint path.

The risk stage is information representing the degree of detected risk in the taint analysis results. The risk stage may be represented by one of a plurality of risk levels. For example, the risk stage may be represented by a “high,” “medium,” or “low” level but is not limited thereto.

The risk information represents a risk detected in the taint path. In some embodiments, when the risk stage is a preset threshold degree of risk or more, it is considered that a risk is detected in the taint path. In the above example, the threshold degree of risk may be set to “medium.” Then, when the degree of risk “high” or “medium” is detected, risk information may be generated.

The risk information is information describing a risk stage and may be represented by an instruction in which a risk is detected and the analyzed risk stage. The risk information may be expressed as, for example, “global variable in sink: High,” “input Symbol & buffer argument: High,” or “Input Symbol: Medium.”

In some embodiments, the taint analysis unit130may generate a risk stage for the taint path on the basis of a preset whitelist and generate risk information of the taint path on the basis of the generated risk stage. Specifically, the taint analysis unit130may determine whether there is a function matching a function designated as a taint source in the taint path among functions in the preset whitelist and determine a risk stage, which is associated in advance with the function matching the function designated as a taint source in the whitelist, as a risk stage of a taint source included in the whitelist.

The whitelist is a list of user functions that may be designated as taint sources. User functions with relatively high risk stages are included in the whitelist. In some embodiments, the functions in the whitelist may be user functions with the preset threshold degree of risk or higher (e.g., “medium”).

In various embodiments of the present disclosure, the whitelist may include one or more user input functions in the system1. The whitelist may include one or more user input functions among, for example, “recv,” “fgetc,” “fets,” “fgetwc,” “fscanf,” “fwscanf,” “fread,” “read,” “getc,” “gets,” “getch,” “getche,” “getchar,” “getenv,” “getwc,” “getwchar,” “scanf,” “sscanf,” “swscanf,” and “vscanf.” However, the user input functions in the whitelist are not limited thereto.

Also, the whitelist may include risk stages that are associated in advance with the user input functions. Each user input function is associated with a risk stage preset by the user.

In the system1where a user library function which is any external function and a user input function which is an internal function may both be designated as taint sources, the taint analysis unit130may generate a risk stage and risk information of a user input function designated as a taint source using the whitelist, making it possible to determine which one is more dangerous between the user input function designated as a taint source and the user library function designated as another taint source.

Also, in some embodiments, the taint analysis unit130may further include an expression converter131. Before the taint analysis operation is performed, the expression converter131converts a data expression in the original target binary file extracted from the IoT device10into an expression format which is preset for taint analysis. The preset expression format may be referred to as an intermediate expression format. The code converted into the intermediate expression format may be referred to as intermediate expression code.

The expression converter131may convert original code based on various expression methods into preset intermediate expression code.

The expression converter131may generate decompiled code by decompiling the binary code of the target binary file and convert the expression of the decompiled code into intermediate expression code while preserving the substantial content of the decompiled code. The converted intermediate expression code is handled as decompiled code in subsequent operations.

In some embodiments, when the taint analysis unit130is based on the binary ninja intermediate language (BNIL), the taint analysis unit130may convert the binary code of the target binary file having the original format into intermediate expression code which satisfies a data format based on the static single assignment (SSA) form.

The binary code of the target binary file may be converted from the original data format into intermediate expression code which satisfies the data format of the SSA form. When the SSA form is used, a new variable is assigned with branching in the code, and thus it is easy to generate a taint path of a variable in taint analysis.

The taint analysis unit130may provide the generated taint path and transmission information corresponding to the taint path to the preprocessing unit150or the vulnerability analysis unit170. This operation of the taint analysis unit130will be described in further detail below with reference toFIG.8and the like.

The preprocessing unit150analyzes information related to at least one argument in the taint path and updates the transmission information so that the vulnerability analysis unit170can easily analyze the taint path generated by the taint analysis unit130and the transmission information. With the preprocessing operation of the preprocessing unit150, argument-related information in the transmission information corresponding to the taint path is processed, or information related to a new argument is added.

The preprocessing unit150includes a size analyzer151that calculates the size of a variable in the taint path. In some embodiments, the preprocessing unit150may further include a data type analyzer152that determines the data type of a variable in a taint path.

The size analyzer151may measure the size of at least one of variables in the taint path. The preprocessing unit150may add the measured size of the at least one variable in the taint path to the transmission information of the taint path. Also, the preprocessing unit150may process the expression data of the variable on the basis of the measured size of the variable.

In various embodiments of the present disclosure, when the taint path includes a stack variable, the size analyzer151may calculate the size of the stack variable and add the size information of the stack variable to the transmission information of the taint path. The transmission information to which the size information of the stack variable is added may be provided to the vulnerability analysis unit170and used for performing a symbolic execution operation.

FIG.5is a diagram illustrating an operation of measuring the size of a stack variable according to various embodiments of the present disclosure.

In the case of analyzing a string, only an address is checked in symbolic execution unlike taint analysis in which the string is analyzed as an array. Accordingly, the size information of a variable is not provided to the vulnerability analysis unit170which performs a symbolic execution operation, and when the vulnerability analysis unit170performs a symbolic execution operation without considering the size information of a variable, it is difficult to determine whether a string is the same as the string which is a target of taint analysis.

Also, the preprocessing unit150may process the expression data of the stack variable to be suitable for a preset data format of the vulnerability analysis unit170.

Referring toFIG.5, the preprocessing unit150may calculate the offset between a stack variable in the taint path and another variable at a position next to the position of the stack variable in the target binary file. To assign a stack variable in a function, variables having different offsets are stacked on the basis of a stack base so that a data space is provided. The preprocessing unit150may distinguish the stack variable by calculating the offset between the stack variable and another variable on the basis of the stack base and calculate the size of the stack variable distinguished with the offset.

Here, the calculated offset value includes a padding value. The data space of the stack variable is generated in units of a size determined according to an architecture or operating system (OS), and in this process, the padding value is used. Due to the padding value, the data space given to the stack variable may be larger than an array value of the stack variable actually generated from the code, but the encroachment of this area does not cause any problem with the program. Accordingly, even when a value larger than the array value of the stack variable actually generated from the code is input as an input of the stack variable, if the data space is occupied up to the padding value, the input value of the stack variable does not encroach on the value of another variable. As a result, it is safe to calculate the size of the stack variable including the padding value. In other words, the padding value may serve as a buffer.

When the taint path includes a stack variable, the size analyzer151may calculate the size of the stack variable and add the size information of the stack variable to the transmission information of the taint path. To process the expression data of the stack variable to be suitable for the preset data format of the vulnerability analysis unit170, the size analyzer may calculate the offset between the stack variable in the taint path and another variable at a position next to the position of the stack variable in the target binary file on the basis of the stack base and calculate the size of the stack variable distinguished with the offset. As shown inFIG.5, when processing an array, the BNIL-based taint analysis unit130specifies a name which is the base of a variable array and then expresses the offset of the variable array using a string such as “:3.” On the other hand, the angr-based vulnerability analysis unit170expresses a variable on the basis of the memory address of the variable. Even in the case of the same variable, array is expressed as 0x7fffe430, and array[3] is expressed as 0x7fffe433. As a result, when the variable arrays of the BNIL-based taint analysis unit130are directly input to the angr-based vulnerability analysis unit170, the angr-based vulnerability analysis unit170is not aware that the two variable arrays are variables having the same array and simply determines that the two variable arrays are variables having different addresses. To solve this problem, the preprocessing unit150calculates the size of a stack variable and processes the expression of the stack variable using the calculated stack size. For example, in the example ofFIG.5, the expression of the stack variable array is processed as “address of array[0]+16(0x7fffe43f).” When the processing result is supplied to the vulnerability analysis unit170, the vulnerability analysis unit170may determine that values of the range from 0x7fffe430 to 0x7fffe43f are one array. Subsequently, the vulnerability analysis unit170may be aware that the memory address of a value input through “gets” is a value included in the array.

In consideration of such a difference in language/data format, the size analyzer151preprocesses an analysis result of the taint analysis unit130according to the preset data format of the vulnerability analysis unit170. Specifically, the size analyzer151may calculate the offset of the stack variable as the size of the stack variable and process the expression data (e.g., transmission information) of the stack variable using the calculated size of the stack variable.

Also, the data type analyzer152may be further configured to determine the data type of at least one of the variables in the taint path. The data type analyzer152may process the data type information of a variable of a target of data type analysis in the transmission information of the taint path into a determined data type.

In various embodiments of the present disclosure, the data type analyzer152may be configured to analyze the data type of the stack variable in at least one of the argument aspect, the return value aspect, and the format string aspect of a function and determine the data type of the stack variable.

In some embodiments, the data type analyzer152may be further configured to analyze the data type of the stack variable in the argument aspect of a function and determine the data type of the stack variable. Specifically, the data type analyzer152may determine whether the stack variable is an argument which is input to a function in a prestored function data list to analyze the data type of the stack variable in the argument aspect of a function, and when the stack variable is determined to be an argument which is input to a function in the prestored function data list, determine the data type of the argument related to the function in the function data list as the data type of the stack variable.

Also, the data type analyzer152may be further configured to analyze the data type of the stack variable in the return value aspect of a function and determine the data type of the stack variable. Specifically, the data type analyzer152may determine whether a return value of a function to which the stack variable is input is a return value which is input to a function in the prestored function data list to analyze the data type of the stack variable in the return value aspect of a function, and when the stack variable is determined to be a return value which is input to a function in the prestored function data list, determine the data type of the return value related to the function in the function data list as the data type of the stack variable.

The function data list is a list of information related to functions. The function data list is a record of the names of functions, the data types of arguments, and the data types of return values of the functions. The function data list is stored in the function DB140in advance.

FIG.6is a view illustrating functions included in a function list according to various embodiments of the present disclosure.

As shown inFIG.6, the function data list includes functions that are known to the system1in advance.

The preprocessing unit150may search the prestored function data list for a function to which a stack variable is input. The known function data list includes return data types and argument data types other than variable arguments as items.

When the stack variable is an argument that is set to be input to a known function, the preprocessing unit150checks an instruction at a position where each stack variable is used in a function. When the left term of the corresponding instruction is a register which is used as an argument, the preprocessing unit150may search for a call instruction to check the name of a function to which the stack variable is input, and search the function data list for the function name to check the data type of the argument.

When the stack variable is a return value that is set to be input to a known function, the preprocessing unit150checks an instruction at a position where each stack variable is used in a function like in the case of an argument. When the right term of the corresponding instruction is a register which is used as an argument, the preprocessing unit150may search for a call instruction to check the name of a function to which the stack variable is input, and search the function data list for the function name to check the data type of the return value.

The preprocessing unit150may generate final transmission information by transforming at least some of the transmission information including a measured size of the stack variable and the determined data type of the stack variable into a data format which is preset for the vulnerability analysis unit170. The data format which is preset for the vulnerability analysis unit170may be, for example, the JavaScript Object Notation (JSON) format, but is not limited thereto.

In some embodiments, when the taint analysis unit130performs taint analysis on the basis of the BNIL, the preprocessing unit150may convert the decompiled binary code into a low level on the BNIL before determining the data type of a variable. The preprocessing unit150may determine the data types of variables in the binary code that is represented in the low-level intermediate language (IL).

The system of the BNIL includes a low-level IL, a medium-level IL, and a high-level IL. At a higher level in the BNIL, additional analysis and code optimization occurs, which is more user-friendly.

The preprocessing unit150may check arguments used in functions on the basis of decompiled code. When a variable in the decompiled code is not input as an argument but a result value of a function is directly input, a register may be seen as an argument or checked as the function in some cases. The preprocessing unit150may convert the decompiled code into a low-level IL, which accurately represents the data types of arguments, and determine the data types of variables.

FIG.7is a view of a result obtained by converting high-level code into low-level code according to various embodiments of the present disclosure.

Referring toFIG.7, the preprocessing unit150may check variables used as arguments in a “sprintf” function expressed at a high level. The variable “var_38” is used as “% S” and thus is a string variable. The value of the variable “rax_1” is checked not to be a stack variable. When the “sprintf” function is converted into a low level, the result value of a function “strlen” is used as “% d.” When arguments in the “sprintf” function are checked, it may be seen that “var_c_1” becomes “% d.” As a result, the preprocessing unit 150 may determine the data type of the variable “var_c_1” to be an int type variable.

Also, when the data type of a stack variable is not determined in the argument aspect or the return value aspect, the data type analyzer152may be further configured to analyze the stack variable in the format string aspect and determine the data type of the stack variable. Specifically, to determine the data type of the stack variable in the format string aspect, the data type analyzer152may search for strings having a format string among strings used in the target binary file to determine whether a string including a format string is used in the range of a function to which the stack variable is input, and when it is determined that a string including a format string is used in the range of the function to which the stack variable is input, match the format string used in the string to the stack variable to determine the data type of the stack variable.

The preprocessing unit150may convert the transmission information of the taint path into a data format corresponding to the vulnerability analysis unit170by processing the transmission information using the determined sizes and data types of variables. For example, in the data type information of a stack variable included in the transmission information of the taint path, the data type information of the stack variable is represented in the BNIL, but when the data type information of the stack variable is processed into a data type determined by the preprocessing unit150, the existing transmission information of the taint path is updated as transmission information in which the data type information of the stack variable is represented with “angr,” that is, new transmission information is generated. The transmission information updated through the preprocessing of the preprocessing unit150may be provided to the vulnerability analysis unit170.

The vulnerability analysis unit170is a component that performs a symbolic execution operation on the taint path on the basis of the taint path and the transmission information of the taint path to detect a vulnerability in the target binary file from which the taint path is provided.

When the preprocessed transmission information is received from the preprocessing unit150, the vulnerability analysis unit170may perform a symbolic execution operation on the taint path on the basis of the taint path and the preprocessed transmission information of the taint path to detect a vulnerability in the target binary file from which the taint path is provided.

The vulnerability analysis unit170includes an execution engine171that performs a symbolic execution operation and a vulnerability detector172that detects a vulnerability in the target binary file on the basis of the result of the symbolic execution.

The execution engine171may perform symbolic execution on the target binary file along the taint path generated by the taint analysis unit130on the basis of the transmission information related to the taint path. In some embodiments, the execution engine171may perform symbolic execution on the taint path on the basis of the transmission information preprocessed (i.e., processed) by the preprocessing unit150.

Symbolic execution is a binary static analysis technique in which values used in a binary file are replaced with symbols rather than concrete values to execute the binary file. The vulnerability analysis unit170designates an input value of the user as a symbol in the target binary file and analyzes the execution flow of the program to detect a vulnerability. The symbolic execution is similar to expanding a formula with unknown quantities in the formula.

The execution engine171may replace values in the target binary file with symbols to detect branching conditions based on the symbols in a conditional statement and the like included in the target binary file. The execution engine171may infer all paths that are actually searchable between the taint sink and the taint source using “SOLVER” and calculate the values of symbols according to each search path. One taint path may include one or more search paths.

To analyze the execution flow of the program based on the taint path through symbolic execution, the execution engine171may replace a specific value used in the taint source, which is the start point of the taint path, with a symbol and execute the target binary file. Here, the execution engine171starts a search from the end point of the taint path, that is, the taint source. In other words, the start point of a search path of the vulnerability analysis unit170is the end point of the taint path. Then, the execution engine171may calculate state information resulting from the symbolic execution of the target binary file. The state information may be expressed as the value of a symbol according to the search path. In some embodiments, the state information may include memory and register values.

In various embodiments of the present disclosure, the execution engine171may be configured to divide the taint path generated by the taint analysis unit130into blocks and calculate block-specific state information by performing a symbolic execution operation on the divided blocks. The blocks are obtained by grouping all instructions which are used in functions of a target of symbolic execution on the basis of branch points in a logical sequence. In other words, a block unit is defined as a pair of consecutive branch points in a taint path, and a block represents the path between a pair of branch points that define a corresponding block in a taint path.

In general, a developer sequentially inputs instructions of binary code, and thus instructions in the same block may be positioned in adjacent rows of the binary code. However, it is coincidental that instructions in the same block are positioned in adjacent rows, and the blocks are not to be understood herein as a grouping of adjacent instructions.

The blocks are linked together according to the logical order thereof in the target binary file. The execution engine171may calculate block-specific state information by searching for a taint path block by block and preserve the block-specific state information.

When symbolic execution is performed on the whole taint path without dividing the taint path into blocks, all possible paths are searched for in the event of a conditional branch during the search. Accordingly, all existing paths may be represented as “˜2{circumflex over ( )}(the number of branch points).”

On the other hand, the execution engine171does not search for some taint paths which are not included in the blocks, and thus the number of existing paths is reduced to “˜2{circumflex over ( )}(the number of branch points in a block).”

In various embodiments of the present disclosure, to calculate block-specific state information, the execution engine171may be configured to symbolize the taint path block by block and perform a symbolic execution operation on the taint path symbolized block by block.

The execution engine171may perform a symbolization operation of replacing a value positioned at the start point of a block with a symbol, on each block. For example, when the taint path includes a first block and a second block, the value of an instruction positioned at the start point of the first block and the value of an instruction positioned at the start point of the second block may be replaced with symbols, and a symbolic execution operation may be performed.

As a result, the execution engine171may calculate a set of state information of the blocks obtained by dividing the taint path as the state information of the taint path.

In some embodiments, when a search time for a block to be searched exceeds a preset threshold time or a search frequency of the block exceeds a preset threshold frequency while the block is searched along the taint path, the execution engine171may be further configured to stop searching the block along the taint path and continue searching the subsequent block along the taint path to calculate state information of the subsequent block. The execution engine171performs a symbolic execution operation on the taint path block by block. During the process, when the search time for a specific block is too long or overdetection is performed because a search path is lost at a specific block, it is determined that symbolic execution is not possible anymore in a portion of the specific block. Symbolic execution is omitted for the specific block including the portion in which symbolic execution is not possible anymore, and a symbolic execution operation is performed from the subsequent block of the specific block.

For example, when the taint path includes a first block, a second block, and a third block that are logically linked together, the execution engine171may be further configured to calculate state information from the first block. When a search time for the second block exceeds the preset threshold time or a search frequency of the second block exceeds the preset threshold frequency while the second block which is the subsequent block of the first block is searched along the taint path, the execution engine171may be further configured to stop searching the second block along the taint path and continue searching the third block along the taint path to calculate state information of the third block which is the subsequent block of the second block. Then, the analysis device100can reduce a very large number of search paths that are generated by repetitive statements, and even in the case of analyzing a very large function, it is possible to reach the end point of the search path in a much shorter time.

The state information resulting from the symbolic execution of the target binary file is provided to the vulnerability detector172and used for analyzing what kind of vulnerability the target binary file has. The execution engine171may provide the block-specific state information calculated through the symbolic execution to the vulnerability detector172.

The vulnerability detector172may determine whether the target binary file (or the corresponding firmware) has a vulnerability. The vulnerability detector172may analyze a vulnerability of the target binary file from which the taint path is provided on the basis of the block-specific state information resulting from the symbolic execution instead of state information resulting from the symbolic execution of the whole target binary file.

In various embodiments of the present disclosure, to determine a vulnerability in the target binary file on the basis of the calculated state information, the vulnerability detector172may be configured to compare the block-specific state information resulting from the symbolic execution with at least one preset vulnerable pattern, determine whether the block-specific state information corresponds to the compared vulnerable pattern, and determine that the state information has a vulnerability of the analyzed target binary file when the block-specific state information corresponds to the vulnerable pattern. When the program state information (e.g., memory and register values and the like) of each individual block matches the compared vulnerable pattern, it is determined that the vulnerable pattern matches the state information.

The vulnerable pattern is a base for determining whether the target binary file has a vulnerability. When state information of the taint path corresponding to a vulnerable pattern (e.g., the block-specific state information of the taint path) is checked in the target binary file, the vulnerability detector172may determine that the target binary file has a vulnerability indicated by the corresponding vulnerable pattern. The vulnerability represents whether at least a portion of the taint path is vulnerable during a runtime.

The vulnerability detector172may search a vulnerable pattern list prestored in the vulnerable pattern DB180. The vulnerable pattern DB180may store the vulnerable pattern list including one or more vulnerable patterns.

In various embodiments of the present disclosure, the vulnerable pattern list may be a CWE list. The CWE list may include vulnerable patterns related to CWE-identities (IDs) such as CWE-78, CWE-190, CWE-415, and the like.

As an example, the vulnerability detector172may detect a vulnerability of the target binary file using the vulnerable pattern of CWE-78. The vulnerable pattern of CWE-78 may be used for detecting an OS command injection attack.

The vulnerable pattern of CWE-78 represents that a user input value reaches a preset vulnerable function for executing an instruction such as a “system” function. Specifically, the vulnerability analysis unit170analyzes the transmission information and checks whether the taint path has a vulnerable function included in the preset vulnerable function list. To determine whether a target variable to be searched for from the start point of the taint path to the end point reaches the vulnerable function (e.g., “system,” “do_system,” or the like), the vulnerability analysis unit170registers the argument of the target variable as a symbol and checks whether the symbol or another variable referring to the symbol reaches the vulnerable function. When it is determined that the block-specific state information resulting from the symbolic execution represents that a user input value reaches a function for executing an instruction, the vulnerability detector172may determine that the block-specific state information corresponds to a vulnerable pattern of CWE-78, and as a result, determine that the target binary file has a vulnerability related to CWE-78.

As another example, the vulnerability detector172may detect a vulnerability of the target binary file using the vulnerable pattern of CWE-190. The vulnerable pattern of CWE-190 may be used for detecting integer overflows.

The vulnerable pattern of CWE-190 represents that the highest sign bit is changed. When the highest sign bit is changed, it is considered that an overflow occurs. Specifically, the vulnerability analysis unit170analyzes the transmission information and checks the highest sign bit of the taint path. The vulnerability detector172determines whether at least one sign bit in a block is changed during a runtime on the basis of the block-specific state information resulting from the symbolic execution. When it is determined that the highest sign bit is changed, the vulnerability detector172may determine that the block-specific state information corresponds to a vulnerable pattern of CWE-190, and as a result, determine that the target binary file has a vulnerability related to CWE-190. The vulnerability related to CWE-190 represents that an overflow occurs during the runtime of the target binary file.

As still another example, the vulnerability detector172may detect a vulnerability of the target binary file using the vulnerable pattern of CWE-415. The vulnerable pattern of CWE-415 may be used for detecting the double-free vulnerability.

The vulnerable pattern of CWE-415 represents that one variable is freed twice in a specific search path. Specifically, the vulnerability analysis unit170may search a specific path from the start point of the taint path to the end point using a dynamic memory allocation function and a dynamic memory return function. When state information resulting from the search represents that there are two frees in the specific search path, the vulnerability detector172may determine that the block-specific state information corresponds to the vulnerable pattern of CWE-415, and as a result, determine that the target binary file has a vulnerability related to CWE-415. The vulnerable pattern of CWE-415 represents the double-free vulnerability.

The vulnerability detector172may store the vulnerability analysis result in the vulnerable pattern DB180. The vulnerability analysis result may include a vulnerability type and a vulnerability position. The vulnerability position depends on a judging criterion. The vulnerability position may be specified on the basis of the taint path. Also, in some embodiments, the vulnerability analysis result may further include the taint path of which the vulnerability analysis result is provided, the corresponding transmission information, and/or the corresponding block-specific state information. The transmission information and the block-specific state information correspond to the same taint path.

As described above, the vulnerability analysis unit170may analyze whether the target binary file has a vulnerability on the basis of the result of performing a symbolic execution operation on each block.

As a result, the system1for detecting a vulnerability has a reduced number of paths to be searched in symbolic execution. Consequently, it is possible to prevent not only path explosion, in which there are too many paths to search, during symbolic execution but also a situation in which it is difficult to perform symbolic execution in an acceptable amount of time.

Although the taint analysis unit130, the function DB140, the preprocessing unit150, the vulnerability analysis unit170, and the vulnerable pattern DB180are integrated in one computing device inFIG.2, the implementation of the components130,140,150,170, and180is not limited thereto. The components130,140,150,170, and180may be configured as exclusive computing devices that are physically separated from each other, or at least some of the components130,140,150,170, and180may be integrated in one computing device in the form of a software module and/or a hardware module.

It is obvious to those of ordinary skill in the art that the system1may include other components. For example, the system1may include other hardware elements required for the operations described herein such as an input device for data entry and an output device for printing or other data display.

A method of analyzing a vulnerability of software installed on an IoT device according to another aspect of the present disclosure may be performed by the analysis device100.

FIG.8is a flowchart illustrating a method of analyzing a vulnerability in software installed on an IoT device according to the other aspect of the present disclosure.

Referring toFIG.8, the method includes operation S100of acquiring a target binary file extracted from firmware of the IoT device10and operation S300of generating a taint path and transmission information related to the taint path by performing taint analysis on the target binary file.

In various embodiments of the present disclosure, operation S100may include an operation in which the user terminal50connected to the IoT device10extracts the target binary file from the firmware of the IoT device10and an operation in which the analysis device100receives the target binary file from the user terminal50.

In operation S300, the taint path representing the propagation of a taint is generated through taint analysis. The taint path may include a user function, which may be a user input function that is an internal function of the software or a user library function based on an external library of the software. The user function may be designated as a taint source, which will be described below.

FIG.9is a detailed flowchart of operation S300ofFIG.8according to various embodiments of the present disclosure.

Referring toFIG.9, operation S300of generating the taint path includes operation S310of specifying a taint sink in the target binary file, operation S320of generating a tracking graph by tracking a parameter from the taint sink, operation S330of determining whether a taint source is in the tracking graph and specifying a taint source corresponding to the taint sink, operation S340of generating a taint path for the target binary file including the taint sink and the taint source, and operation S350of generating transmission information of the taint path. Operation S300may further include operation S360of removing the tracking graph when it is determined that there is no taint source in the tracking graph.

In some embodiments, operation S300may further include, before operation S310, operation S301of converting a data expression in the original target binary file extracted from the IoT device10into an expression format which is preset for taint analysis.

FIG.10is a view of a result of converting intermediate representation code into the SSA form according to various embodiments of the present disclosure.

As shown inFIG.10, in operation S301, the binary code of the target binary file having the original format may be converted into intermediate expression code having a data format based on the SSA form.

In operation S310, the taint sink is the start point of the taint path and may be the start point of the tracking graph. When the taint sink is specified in operation S310, the position of the taint sink in the target binary file is also specified.

In operation S310of specifying the taint sink, when it is determined that a vulnerable function included in a prestored vulnerable function list is used in the target binary file, an instruction in which the checked vulnerable function is used may be designated as the taint sink. The position of the instruction in which the vulnerable function is used in the target binary file is designated as the position of the taint sink. As described above, the vulnerable function list prestored in the function DB140may include, for example, system, execl, execlp, execv, execvp, execle, execve, popen, and do_system.

Operation S320of generating the tracking graph may include a first operation of processing the instruction corresponding to the position of the taint sink to divide the instruction into a left term and a right term, a second operation of processing one of the left and right terms including an operator to divide the left or right term into the operator and an argument, a third operation of processing the argument included in the left or right term to determine whether the argument is a variable or constant, an operation of searching, when the argument is a variable, the target binary file for at least one instruction in which the argument is used as a variable, and an operation of repeating the first operation to the third operation with each found instruction applied to the instruction analyzer to generate the tracking graph using the instruction having the argument of which analysis has been completed up to an argument level.

In the process of repeating the first operation to the third operation in operation S320, additional analysis is omitted for instructions and arguments that have already been processed. In other words, in the process of repeating the first operation to the third operation, only instructions and arguments that are not in the analysis log are processed. As a result, the taint sink may be analyzed on an instruction-by-instruction basis, an operation-by-operation basis, and an atom-by-atom basis, and parameters logically connected to the taint sink to generate the tracking graph. The tracking graph may be extended when an instruction of which analysis has been completed up to an argument level is added to the tracking graph. When an instruction related to a target of analysis has been analyzed up to an argument level, tracking in a direction related to the target of analysis may be finished in the tracking graph.

Since the process of generating a tracking graph has been described above with reference to the analyzers132,133, and134, the detailed description thereof will not be repeated.

In operation S300, when a parameter is not trackable from the taint sink (S320), the analysis device100checks whether a taint source is included in the tracking graph that has been generated until then (S330).

A taint source specified in operation S330may be a user function. It may be determined whether the user function exists in the tracking graph, and the user function may be designated as a taint source corresponding to the taint sink (S330). The user function may be a user input function that is an internal function of the software or a user library function based on an external library of the software.

Operation S330of specifying the taint source may include an operation of designating the user function as the taint source corresponding to the taint sink on the basis of a call function for calling the taint sink and the tracking graph. When the taint source is specified in operation S330, the position of the taint sink in the target binary file is also specified.

In various embodiments of the present disclosure, the operation of designating the user function as the taint source corresponding to the taint sink on the basis of a call function for calling the taint sink and the tracking graph may include an operation of comparing all call instructions in the function for calling the taint sink with call instructions in the tracking graph and an operation of specifying the taint source corresponding to the taint sink on the basis of the comparison result of the call instructions.

It is checked whether the user function, that is, the taint source, is in the tracking graph by comparing the call instructions.

In some embodiments, operation S330of may further include an operation of respecifying the taint source on the basis of a preset blacklist. Then, operation S330may further include an operation of regenerating the taint path on the basis of the taint sink and the respecified taint source.

The operation of respecifying the taint source on the basis of the preset blacklist may include an operation of canceling the designation of the taint source when the designated taint source includes at least one function in the preset blacklist after the taint source corresponding to the taint sink is designated, an operation of determining whether the tracking graph includes a different taint source from the canceled taint source, and an operation of redesignating the different taint source as the taint source corresponding to the taint sink when it is determined that the tracking graph includes the different taint source.

As described above, the blacklist may include one or more of, for example, “abs,” “acos,” “asin,” “printLine,” “atan,” “atof,” “atoi,” “atol,” “bsearch,” “calloc,” “ceil,” “clearerr,” “cos,” “cosh,” “creatnew,” “creattemp,” “_C_Quickpool_Int,” and “_close” functions as a list of functions that are not allowed to be designated as taint sources.

Whether there is another taint source may be checked on the basis of the comparison result of the call instructions as described above to initially specify a taint source.

In operation S330, when there is no taint source in the tracking graph from the beginning or a taint source is initially checked to exist and specified and then canceled on the basis of the blacklist, it is considered that no taint source exists in the tracking graph as a result. Accordingly, the tracking graph is removed and excluded from targets of symbolic execution because it is determined that no vulnerability is detected in the tracking graph.

In operation S340, a taint path including an instruction between the taint sink and the taint source may be generated using the taint sink and the taint source as the start point and the end point of the taint path, respectively.

As described above in operation S350, the transmission information including one or more of a call function of the taint sink, an address of the call function of the taint sink, a risk stage based on a taint analysis result, risk information based on the taint analysis result, an address of the taint source, an argument number of a decimal portion, an address of the taint sink, an argument number of the taint sink, and a size of the argument of the taint sink may be generated.

FIG.11is a schematic view illustrating generation of a taint path in the intermediate representation code ofFIG.10, andFIG.12is a schematic diagram illustrating a process of generating a taint graph from a tracking graph acquired from the intermediate representation code ofFIG.10.

Referring toFIGS.11and12, a vulnerable function1110(“system( )” ofFIG.11) in the binary code ofFIG.10is designated as a taint sink (S310), and the flow of tainted data is tracked on the basis of a parameter111(“rdi_3#5” ofFIG.11) to generate a tracking graph (S320). When a user input function1130(“fgets( )” ofFIG.11) exists in the tracking graph as a call function for calling the taint sink, the user input function1130is designated as a taint source (S330), and a taint path is generated in the tracking graph (S340). Then, a taint path including the taint sink1110, the taint source1130, and instructions1140ato1140etherebetween is generated. The generated taint path may be stored in the server100.

In some embodiments, operation S350may include an operation of generating a risk stage of the taint path on the basis of a preset whitelist and generating risk information of the taint path on the basis of the generated risk stage.

As described above, the whitelist is a list including one or more user input functions in the system1. For example, the whitelist may include one or more user input functions among “recv,” “fgetc,” “fets,” “fgetwc,” “fscanf,” “fwscanf,” “fread,” “read,” “getc,” “gets,” “getch,” “getche,” “getchar,” “getenv,” “getwc,” “getwchar,” “scanf,” “sscanf,” “swscanf,” and “vscanf.” The whitelist may include a risk stage pre-related to each user input function.

In operation S350, it is checked whether any function in the preset whitelist matches the function designated as the taint source in the taint path, and a risk stage pre-related to the function in the whitelist matching the taint source is generated as a risk stage of the taint source included in the whitelist.

In some embodiments, before operation S700to be described below, the method may further include operation S500of processing at least some of the transmission information related to the taint path generated in operation S300into a symbolic execution data format.

Operation S500may include operations S501and S510of, when the taint path includes a stack variable, calculating the size of the stack variable and adding the size information of the stack variable to the transmission information of the taint path, operations S521to S527of determining the data type of the stack variable and adding the data type to the transmission information, and an operation of converting at least some of the transmission information including the size information and the data type into the symbolic execution data format.

The symbolic execution data format may be, for example, the JSON format, but is not limited thereto. Final transmission information obtained by converting the data format includes the size information and the data type.

FIG.13is a detailed flowchart of operation S500ofFIG.8according to various embodiments of the present disclosure.

Referring toFIG.13, operation S500includes operation S501of determining whether variables in functions of the taint path of the target binary file include a stack variable. When the taint path includes a stack variable, processing operations S510to S527may be performed.

Operation S500includes operation S510of analyzing the size of the stack variable in the taint path. Operation S510may include an operation of calculating the size of the stack variable on the basis of the offset of the stack variable in the target binary file and an operation of processing the expression data of the stack variable in the transmission information into a preset data format on the basis of the calculated size of the stack variable.

In operation S510, the operation of calculating the size of the stack variable in the taint path on the basis of the offset of the stack variable may include an operation of calculating the offset between a stack variable in the taint path and another variable at a position next to the position of the stack variable in the target binary file.

Also, in some embodiments, operation S500may further include operation S520of analyzing the data type of the stack variable in at least one of the argument aspect, the return value aspect, and the format string aspect of a function and determining the data type of the stack variable. Specifically, operation S520may include operation S521of determining whether the stack variable is an argument which is input to a function in a prestored function data list to analyze the data type of the stack variable in the argument aspect of a function, operation S522of determining, when the stack variable is checked as an argument which is input to a function in the prestored function data list, the data type of an argument related to the function (i.e., the function to which the checked argument is input) in the function data list as the data type of the stack variable, operation S523of determining whether the stack variable is a return value which is input to a function in the prestored function data list to analyze the data type of the stack variable in the return value aspect of a function, operation S524of determining, when the stack value is checked as a return value which is input to a function in the prestored function data list, the data type of the return value related to the function in the function data list as the data type of the stack variable, and an operation of determining, when the data type of the stack variable is not determined in the argument aspect and the return value aspect, the data type of the stack variable in the format string aspect. In some embodiments, the operation of determining the data type of the stack variable in the format string aspect may include operation S525of searching for a string having a format string among strings used in the target binary file and determining whether a string including a format string is used in the range of a function to which the stack variable is input and operation S526of matching, when it is determined that a string including a format string is used in the range of a function to which the stack variable is input, the format string used in the string to the stack variable to determine the data type of the stack variable.

In some embodiments, operation S520may further include operation S527of determining, when it is checked in operation S525that no string including a format string is used in the range of a function to which the stack variable is input, the most frequent one of checked data types as the data type of the stack variable.

The size information and data type of the variable obtained through operations S501to S527may be included in the transmission information of which the data format has been converted, and used for a symbolic execution operation in operation S700.

In addition, the method may include operation S700of performing symbolic execution on the target binary file on the basis of the taint path and the transmission information to analyze a vulnerability in the target binary file.

FIG.14is a detailed flowchart of operation S700ofFIG.8according to various embodiments of the present disclosure.

Referring toFIG.14, operation S700may include operation S710of dividing the taint path generated by the taint analysis unit130into blocks before a symbolic execution operation, operation S720of performing symbolic execution on the taint path generated by the taint analysis unit130block by block on the basis of the transmission information related to the taint path to calculate state information of each block in the taint path, and operation S730of analyzing the block-specific state information to determine a vulnerability of the target binary file.

In operation S710, the taint path may be divided into blocks by defining the intervals between branch points in the taint path as blocks, and state information of the divided blocks may be calculated.

FIG.15is a schematic view of a result of dividing a taint path into blocks according to various embodiments of the present disclosure.

The entire taint path ofFIG.15includes the taint path ofFIG.11.

Referring toFIG.15, blocks1510to1550may be formed by dividing the taint path into blocks. The block1510includes 34thto 44thlines ofFIG.11, and the block1550includes 23rdto 33rdlines ofFIG.11. Although not shown inFIG.11, the blocks1520,1530, and1540are formed on the basis of binary code included in the target binary file.

In various embodiments of the present disclosure, operation S720may include an operation of replacing a value at a start point of a block with a symbol to symbolize the taint path block by block and an operation of performing a symbolic execution operation on the taint path symbolized block by block.

State information generated in operation S720may be stored in the server100. In some embodiments, the state information may include memory and register values.

According to some embodiments, in the operation of performing a symbolic execution operation on the taint path symbolized block by block in operation S720, when the search time for the block to be searched exceeds a preset threshold time or the search frequency of the block exceeds a preset threshold frequency while the block is searched along the taint path, searching the block along the taint path may be stopped, and searching the subsequent block along the taint path may continue to calculate the state information of the subsequent block. For example, the taint path may include a first block, a second block, and a third block that are logically linked together in sequence. Here, state information is calculated from the first block, and when the search time for the second block exceeds the preset threshold time or the search frequency of the second block exceeds the preset threshold frequency while the second block which is next to the first block is searched along the taint path, searching the second block along the taint path may be stopped, and searching the third block along the taint path may continue to calculate the state information of the third block which is next to the second block.

Also, operation S700includes operation S740of determining whether the block-specific state information calculated as an analysis result through the symbolic execution in operation S730corresponds to a vulnerable pattern and operation S750of determining that the target binary file of which the state information has been analyzed has a vulnerability when the block-specific state information corresponds to the vulnerable pattern.

In operation S740, the block-specific state information resulting from the symbolic execution may be compared with at least one preset vulnerable pattern, and it may be checked whether the block-specific state information corresponds to the compared vulnerable pattern on the basis of the comparison result. When the program state information of each individual block matches a compared vulnerable pattern, it is determined that the vulnerable pattern matches the state information.

When it is determined in operation S750that the target binary file has a vulnerability, block-specific state information that causes the determination may be stored in the vulnerable pattern DB180as a vulnerable case.

In various embodiments of the present disclosure, the vulnerable pattern may be a vulnerable pattern related to CWE-IDs. For example, the vulnerable pattern may be CWE-78, CWE-190, CWE-415, or the like.

In various embodiments of the present disclosure, operation S740may include an operation of determining whether the block-specific state information resulting from the symbolic execution corresponds to a first vulnerable pattern indicating a first vulnerability, an operation of determining whether the block-specific state information resulting from the symbolic execution corresponds to a second vulnerable pattern indicating a second vulnerability, and/or an operation of determining whether the block-specific state information resulting from the symbolic execution corresponds to a third vulnerable pattern indicating a third vulnerability.

In operation S750, the target binary file may be determined to have a vulnerability that has been checked to correspond in operation S740.

The operation of determining whether the block-specific state information resulting from the symbolic execution corresponds to the first vulnerable pattern indicating the first vulnerability may include an operation of registering the argument of a target variable to be searched for as a symbol to determine whether the target variable from the start point of the taint path to the end point reaches a preset vulnerable function (e.g., “system,” “do_system,” or the like), an operation of determining whether the symbol or another variable referring to the symbol reaches the vulnerable function, and an operation of determining, when it is determined that the block-specific state information resulting from the symbolic execution represents that a user input value reaches a function for executing an instruction, that the block-specific state information corresponds to the first vulnerable pattern (e.g., the vulnerable pattern of CWE-78) indicating the first vulnerability. The preset vulnerable function is a function included in the vulnerable function list.

When the block-specific state information is determined to correspond to the first vulnerable pattern (S740), the target binary file is determined to have the first vulnerability (S750).

The operation of determining whether the block-specific state information resulting from the symbolic execution corresponds to the second vulnerable pattern indicating the second vulnerability may include an operation of determining whether a sign bit in the block is changed during a runtime on the basis of the block-specific state information resulting from the symbolic execution and an operation of determining that the block-specific state information corresponds to the second vulnerable pattern indicating the second vulnerability when it is determined that a highest sign bit is changed. When the block-specific state information is determined to correspond to the second vulnerable pattern (S740), the target binary file is determined to have the second vulnerability (S750). The second vulnerability represents that an overflow occurs during the runtime of the target binary file.

The operation of determining whether the block-specific state information resulting from the symbolic execution corresponds to the third vulnerable pattern indicating the third vulnerability may include an operation of searching a specific path from the start point of the taint path to the end point using a dynamic memory allocation function and a dynamic memory return function and an operation of determining that the block-specific state information corresponds to the third vulnerable pattern (e.g., the vulnerable pattern of CWE-415) indicating the third vulnerability when state information resulting from the search represents that there are two frees in the specific search path. When the block-specific state information is determined to correspond to the third vulnerable pattern (S740), the target binary file is determined to have the third vulnerability (S750). The third vulnerability represents the double-free vulnerability.

In addition, operation S700includes an operation S760of removing the taint path when no vulnerable pattern is checked to correspond to the block-specific state information. When there is no data to be additionally analyzed after operations S750and S760, the vulnerability detection operation is finished.

The system1and method for detecting a vulnerability in a program installed on an IoT device can automatically examine a vulnerability on the basis of a static binary analysis method without executing a program of the IoT device, and thus it is possible to not depend on an execution environment. Also, the vulnerability detection system may include any external function, which is implemented in the form of a library by a developer, as a target of analysis, which allows more universal analysis.

According to embodiments of the present disclosure, vulnerabilities can be automatically examined on the basis of a static binary analysis method without executing a program of an IoT device, and thus it is possible to not depend on an execution environment.

Also, the vulnerability detection system may include any external function, which is implemented in the form of a library by a developer, as a target of analysis, which allows more universal analysis.

According to embodiments, it is possible to prevent not only path explosion, in which there are too many paths to search, during symbolic execution but also a situation in which it is difficult to perform symbolic execution in an acceptable amount of time. As a result, it is possible to increase examination efficiency during the same examination time compared to other examination methods.

When embodiments of the present disclosure are implemented using hardware, application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), or the like configured to perform the present disclosure may be included in the processor of the present disclosure.

Meanwhile, the foregoing method can be implemented as a program executable in a computer and executed in a general-use digital computer that executes the program using a computer-readable medium. The structure of data used in the foregoing method may be recorded on a computer-readable storage medium in various ways. It should be understood that program storage devices that may be used for describing a storage device including executable computer code for performing various methods of the present disclosure do not include temporary objects such as carrier waves or signals. The computer-readable storage medium includes a storage medium such as a magnetic storage medium (e.g., a read-only memory (ROM), a floppy disk, a hard disk, or the like) or an optical medium (e.g., a compact disc (CD)-ROM, a digital versatile disc (DVD), or the like).

The embodiments described above are constructed by combining components and features of the present disclosure in certain forms. Each component or feature should be considered selective unless explicitly mentioned otherwise. Each component or feature may be implemented without being combined with other components or features. In addition, some components and/or features may be combined in an embodiment of the present disclosure. The sequences of operations described in embodiments of the present disclosure may be changed. Some elements or features of an embodiment may be included in another embodiment or replaced by corresponding elements or features of another embodiment. It is obvious that claims not explicitly recited may be combined into an embodiment or included as a new claim by amendment after filing.

Those skilled in the art will appreciate that the present disclosure may be implemented in other specific forms without departing from the technical spirit or essential features thereof. Therefore, the above embodiments are to be construed as illustrative rather than restrictive in all aspects. The scope of the present disclosure should be determined by a reasonable interpretation of the appended claims and all possible variations within the scope of the present disclosure or an equivalent thereof.

One or more of the embodiments described herein can be combined in whole or in part with the embodiments described in co-pending U.S. Patent Application Ser. Nos. 18/673,062, entitled “SYSTEM AND METHOD FOR ANALYZING CONTAMINATION PATHS TO ANALYZE VULNERABILITIES IN IoT DEVICES,” and 18/673,066, entitled “SYSTEM AND METHOD FOR ANALYZING VULNERABILITIES IN IoT DEVICES THROUGH PREPROCESSING IDENTIFICATION INFORMATION OF CONTAMINATION PATHS,” filed on even date herewith. For instance, embodiments of the aforementioned U.S. applications can be combined in whole or in part with embodiments of the subject disclosure. For example, one or more features and/or embodiments described in the aforementioned U.S. applications can be used in conjunction with (or as a substitute for) one or more features and/or embodiments described herein, and vice versa. Accordingly, all sections of each of the aforementioned U.S. applications are incorporated herein by reference in their entirety.