KR20200080541A - Apparatus and method for detecting vulnerability of software - Google Patents

Abstract

The present invention relates to an apparatus for detecting the vulnerability of software based on a program path and to a method thereof. The method for detecting the vulnerability of software comprises the steps of: randomly selecting one seed from a seed pool; generating a test input by applying a preset attack rule with respect to the selected seed; inputting the test input into target software; determining whether a new program path of the software has been searched by the test input; and adding the test input to the seed pool when the new program path is searched.

Description

Apparatus and method for detecting software vulnerability based on program path{APPARATUS AND METHOD FOR DETECTING VULNERABILITY OF SOFTWARE}

The present invention relates to an apparatus and method for detecting a software vulnerability based on a program path.

Among the bugs in which the software does not operate as intended, there may be a bug that causes damage such as information leakage or data modification, and this exploitable bug is called a software vulnerability, Attacks used may include'Buffer Overflow' attacks,'SQL injection', and'Cross Site Scripting', which typically execute the desired code by overwriting the memory.

In general, a fuzzing technique for detecting a vulnerability in software refers to a method of inducing errors by passing valid, unexpected, abnormal or random data to the software. These purging techniques can be divided into mutation-based, grammar-based, black-box purging, and white-box purging depending on the type of information used to generate test input.

In particular, as the Internet of Things (IoT) technology gradually develops, software or libraries for providing new IoT services are being developed, and vulnerability analysis of these software or libraries is also essential. In particular, if a vulnerability exists in a software product used in an IIoT (Industrial Internet of Things) environment, an accurate vulnerability detection method is required because physical damage may occur through an attack using the vulnerability remotely.

However, software and libraries for use in such IoT devices are often not available, so efficient white box-based testing is impossible.

In addition, even in the case of the existing black box-based vulnerability analysis method, since the source code information of the target software cannot be utilized, a vast amount of test cases are required, so the efficiency is limited.

The background technology of the present application is disclosed in Korean Patent Publication No. 10-1857289.

The present application is intended to solve the above-mentioned problems of the prior art, and generates a test input based on a seed, and predicts that other elements of the target software are searched by monitoring some elements in the test process, not just performing a test. The purpose is to provide a device and method for detecting software vulnerability based on a program path as a fuzzing technique using a seed extension technique that adds the corresponding test input as a new seed.

However, the technical problems to be achieved by the embodiments of the present application are not limited to the technical problems as described above, and other technical problems may exist.

As a technical means for achieving the above technical problem, a software vulnerability detection method based on a program path according to an embodiment of the present application comprises: randomly selecting one seed from a seed pool, and a predetermined attack on the selected seed Generating a test input by applying a rule, inputting the test input into a target software, determining whether a new program path of software has been searched by the test input, and when a new program path has been searched, the And adding a test input to the seedpool.

In addition, the software vulnerability detection method based on the program path may further include determining whether a test input can be generated using the selected seed.

Further, the seed may be normal input data or abnormal input data of the target software.

Further, the preset attack rule may be at least one of random bit operation, application of border values, and field size change.

Further, the step of determining whether the new program path has been searched may include determining whether a new source code region included in the target software has not been executed by inputting a preceding test input to the target software. May be

In addition, determining whether the new source code area has been executed analyzes at least one of code coverage change amount, input/output response time change, output value change, memory utilization amount, and other system information of the target software. Can be done by

In addition, the software vulnerability detection method based on the program path may further include detecting a crash after inputting the test input to the target software.

In addition, when the crash occurs in the target software due to the step of inputting the test input to the target software, the detecting of the crash may be to store the corresponding test input as a log.

On the other hand, as a technical means for achieving the above technical problem, the software vulnerability detection device based on the program path according to an embodiment of the present application, the first storage for storing information about the seed of the normal or abnormal input of the target software An input generating unit for receiving a seed information from the first storage unit and generating a new test input based on the seed information, a test unit for inputting the test input to the target software and analyzing the response of the target software, and the test It may include a program path detection unit for detecting whether a new program path of the target software is searched by input.

In addition, the software vulnerability detection apparatus based on the program path may further include a second storage unit that stores information about the corresponding test input in a log form when a crash occurs in the process of analyzing the response of the software by the test unit.

In addition, the program path detection unit, with respect to the response of the software according to the test input, the code coverage (Code Coverage) change amount, the change in the input and output response time, the change in the output value, memory By analyzing at least one of utilization amount and other system information, it is possible to detect whether a new program path of the target software has been searched.

The above-described problem solving means are merely exemplary and should not be construed as limiting the present application. In addition to the exemplary embodiments described above, additional embodiments may exist in the drawings and detailed description of the invention.

According to the above-described problem solving means of the present application, the software vulnerability detection apparatus and method according to the present application can have excellent vulnerability detection performance even when the user incorrectly generates the initial seed because the seed is expanded according to whether or not the program path is searched. .

According to the above-described problem solving means of the present application, the software vulnerability detection device and method based on the program path, the program of the target software by each test input through the change amount of the code coverage in connection with the white box test method accessible to source code information It can be determined whether the route has changed.

According to the above-described problem solving means of the present application, the software vulnerability detection apparatus and method based on the program path, among black box test methods that cannot utilize source code information, among input/output response time differences, output value changes, and other system information By using at least one piece of information, it is possible to determine whether the program path of the target software has been changed by each test input, thereby overcoming the limitations of the existing black box-based test.

1 is a schematic block diagram of a software vulnerability detection apparatus based on a program path according to an embodiment of the present application.
2 is an operation flow diagram of a software vulnerability detection method based on a program path according to an embodiment of the present application.
3 is an operation flow chart for determining whether it is possible to generate a test input using a selected seed according to an embodiment of the present application.
4 is an operation flow chart for detecting a crash according to an embodiment of the present application.
5 is a diagram illustrating an operation of a program path detection unit according to an embodiment of the present application.

Hereinafter, embodiments of the present application will be described in detail with reference to the accompanying drawings so that those skilled in the art to which the present application pertains may easily practice. However, the present application may be implemented in various different forms and is not limited to the embodiments described herein. In addition, in order to clearly describe the present application in the drawings, parts irrelevant to the description are omitted, and like reference numerals are assigned to similar parts throughout the specification.

Throughout this specification, when a part is "connected" to another part, this includes not only "directly connected" but also "electrically connected" with another element in between. do.

Throughout this specification, when one member is positioned on another member “on”, “on top”, “top”, “bottom”, “bottom”, “bottom”, it means that one member is on another member This includes cases where there is another member between the two members as well as when in contact.

Throughout the present specification, when a part “includes” a certain component, it means that the component may further include other components, not to exclude other components, unless specifically stated to the contrary.

The present invention relates to a method and apparatus for detecting a software vulnerability based on a program path.

1 is a schematic block diagram of a software vulnerability detection apparatus 100 based on a program path according to an embodiment of the present application.

Meanwhile, the software vulnerability detection window 100 based on the program path is mounted on industrial equipment including a server, a desktop PC, a laptop, a smart phone, a tablet PC, and other central processing devices to detect the vulnerability of software operating on each device. can do.

Referring to Figure 1, the software vulnerability detection apparatus 100 based on the program path according to an embodiment of the present application, the first storage unit 110, the input generation unit 120, the test unit 130, the program path detection The unit 140 and the second storage unit 150 may be included.

Referring to FIG. 1, the first storage unit 110 may store information about a seed that is a normal input or an abnormal input of the target software, and the seed pool refers to a set of seeds consisting of one or more seeds.

According to one embodiment of the present application, the initial seed pool information of the first storage unit 110 may be defined by a user, and the seed may have various forms, such as packets and files, according to the type of target software.

According to an embodiment of the present disclosure, when the first storage unit 110 receives the seed addition command 54 from the program path detection unit 140, the information on the corresponding test input is the first storage unit as new seed information. It can be added to 110. In other words, the number of seeds stored in the first storage unit 110 may be variable.

In addition, the software vulnerability detection apparatus 100 based on the program path according to an embodiment of the present application detects a vulnerability when all the seeds stored in the first storage unit 110 are converted into test inputs to complete a test process input to the software. It can be made as a termination condition.

Also, the input generating unit 120 may receive seed information from the first storage unit 110 and generate a new test input based on the seed information.

According to one embodiment of the present application, the input generation unit 120 may select and receive only the seed information that has not been tested among the seeds of the first storage unit 110.

According to an embodiment of the present application, the input generating unit 120 performs a step of determining whether a test input can be generated using the selected seed prior to the step of generating a test input based on the seed information. Can.

According to one embodiment of the present application, the input generation unit 120 generates a test input candidate group to which at least one preset attack rule is applied to the selected seed, and all of the test input candidate groups are input to the test in the existing vulnerability detection process Can be used to determine if it has been used.

According to one embodiment of the present application, as a result of determining whether the new test input can be generated, if there is a record that all the test input candidate groups based on the seed information are input to the target software, the corresponding seed is not used to generate the test input In this case, in this case, the input generating unit 120 may receive other seed information from the first receiving unit 110.

Conversely, as a result of determining whether the new test input can be generated, if there is a test input candidate without a record input to the target software among test input candidate groups based on seed information, a test input without a record input to the target software The candidate may be determined as a test input, and information on the test input may be transmitted to the test unit 130.

According to one embodiment of the present application, the preset attack rule may be at least one of random bit operation, application of border values, and field size change.

According to one embodiment of the present application, the preset attack rule can be directly written by the user by various heuristic methods.

However, random bit operations among attack grammars, application of border values, and field size changes are only illustrative examples to help understanding, and examples of modifications to other input data are applied to this idea. It should not be construed as limiting or limiting what is to be done.

In addition, the test unit 130 may input the test input generated and transmitted from the input generation unit 120 to the target software and analyze the response of the target software.

According to an embodiment of the present application, the response of the target software may include an exception situation such as a collision, a failure of built-in code verification, a potential memory leak discovery, etc. in addition to a response that outputs a normal output value.

In addition, the program path detection unit 140 may detect whether a new program path of the target software has been searched by a test input in parallel with the operation of the test unit 130.

5 is a diagram for explaining the operation 140 of the program path detection unit according to an embodiment of the present application.

Referring to FIG. 5, the program path detection unit 140 includes a code coverage change amount, an input/output response time change, an output value change, and a memory. When it is determined that the new source code area has been executed by analyzing at least one of the utilization amount and other system information, a seed addition command 54 may be transmitted to the first storage unit.

Referring to FIG. 5, when the analysis result of the program path detection unit 140 corresponding to the test input 51 applied to the target software is executed, only the source code area 52 generally executed in the existing test is executed. The seed addition command 54 may be transmitted only when the extended source code region 53 is executed than that executed in the existing test without transmitting the command.

According to one embodiment of the present application, the seed addition command 54 may include information of the test input 51. In other words, according to an embodiment of the present application, the vulnerability detection device 100 may add a test input 51 that has executed the expanded source code area 53 as a new seed.

According to an embodiment of the present application, the source code (Source Code) may refer to a text or a computer program written in a programming language. It is mainly used to input the process of creating an executable program, and can also be used as a method of exchanging algorithms.

According to one embodiment of the present application, code coverage is a number of how much the source code itself was executed when the software test was performed. In other words, as a result of the test, the execution part and the non-execution part may be included, and the percentage of the execution part of the entire code may be defined as code coverage. As a result, the increase in the code coverage value by a specific test input may be a direct proof that the source code included in the target software has been executed more in the existing test, and the program path has changed accordingly.

According to one embodiment of the present application, the software vulnerability detection apparatus 100 based on a program path utilizing code coverage may be associated with a white box based fuzzing technique capable of direct access to source code.

According to one embodiment of the present application, a change in input/output response time may be defined as a time taken by a target software to provide an output value by a test input 51, and two functions that play different roles in the source code are built-in. Assuming that, the execution time of the two functions may be different, so the input/output response time may increase when a function that has not been executed by the existing test input is executed.

According to one embodiment of the present application, when the program path is changed even for the entire source code area, a difference in input/output response time due to the existing test input may occur as the unexecuted source code area is executed.

According to an exemplary embodiment of the present application, when a different output result is obtained in comparison with an output value provided by the target software in a normal situation, it can be inferred that the target software has searched for a different program path in relation to the change of the output value have. In addition, in order to easily measure the change in the output value, the input / output can be reviewed as a pair.

According to one embodiment of the present application, the output value provided by the target software in the normal situation may be a set of output values provided by the target software by existing test inputs.

According to an embodiment of the present application, as an example of other system information, a Page Reference Bit may be used.

According to one embodiment of the present application, a change in input/output response time, a change in output value, memory Utilization and other system information can function as indirect evidence of changes in the program path even in connection with a black box-based fuzzing technique where direct access to source code is not possible.

However, the amount of code coverage change, the change in input/output response time, the change in output value, and memory Utilization and other system information are merely illustrative examples for ease of understanding and should not be construed as limiting or limiting the application of the information that can be used to infer changes in other program paths to apply to the present idea.

According to one embodiment of the present application, the seed addition command 54 is transmitted from the program path detection unit 140 to the first storage unit 110, and the current path information stored in the first storage unit 110 of the program path The test input 51 that caused the change can be added as a seed so that it can be considered once again in a subsequent vulnerability detection process.

More specifically, the software vulnerability detection device 100 based on the program path according to an embodiment of the present application, when an area that has not been executed by an existing test input among source codes included in the target software is executed, the corresponding test The input 51 is regarded as a case where the potential for detecting a vulnerability is high, and the seed can be extended during the software vulnerability detection process by adding it as a new seed.

As a result, since the seed can be extended, even if the user sets the initial seed information inappropriately, vulnerability detection can be easily performed, and as much as possible of the source code of the target software can be considered.

In addition, when the crash occurs in the process of analyzing the response of the software by the test unit 130, the second storage unit 150 may store information on the corresponding test input in a log form.

According to one embodiment of the present application, a crash may include exceptions such as crashes, failed built-in code verification, and potential memory leak detection.

According to one embodiment of the present application, the second storage unit 150 may detect a vulnerability in the target software when an abnormal situation expressed as a crash occurs while the test input is input to the target software and provides an output value. Considering that the potential is high, a log can be generated for further analysis.

According to one embodiment of the present application, the log may include information on the test input 51 that caused the crash or system information at the time.

2 is an operation flow diagram of a software vulnerability detection method based on a program path according to an embodiment of the present application.

The software vulnerability detection method based on the program path illustrated in FIG. 2 may be performed by the software vulnerability detection apparatus 100 based on the program path described above. Therefore, even if omitted, the description of the software vulnerability detecting apparatus 100 based on the program path can be applied to FIG. 2 as well.

Referring to FIG. 2, in step S210, the input generation unit 120 may randomly select one seed from the seed pool stored in the first storage unit 110.

According to one embodiment of the present application, the seed may be normal input data or abnormal input data of the target software, and the seed pool may be a set of seeds consisting of one or more seeds.

Next, in step S220, the input generator 120 may generate a test input by applying a preset attack rule to the selected seed.

According to one embodiment of the present application, the preset attack rule may be at least one of random bit operation, application of border values, and field size change.

According to one embodiment of the present application, the preset attack rule can be directly written by the user by various heuristic methods.

Next, in step S230, the test unit 130 may input the test input to the target software.

According to one embodiment of the present application, as input of the test input, the target software may output a normal output value or react abnormally, such as a collision, a failure of built-in code verification, and a potential memory leak discovery.

Next, in step S240, the program path detector 140 may determine whether a new program path of the software has been searched by a test input.

According to an embodiment of the present application, in step S240, the program path detection unit 140 has been executed by the step of inputting the preceding test input to the target software, the new source code region included in the target software has not been executed. Can determine whether

According to one embodiment of the present application, determining whether the new source code area has been executed is selected from among changes in code coverage of the target software, changes in input/output response time, changes in output values, memory utilization, and other system information. It can be performed by analyzing at least one piece of information.

Next, in step S250, if the first storage unit 110 is analyzed that a new program path is found as a result of the analysis of the program path detection unit 140, the test input can be added to the seed pool as a new seed. have.

In the above description, steps S210 to S250 may be further divided into additional steps or combined into fewer steps, according to an embodiment of the present application. In addition, some steps may be omitted if necessary, and the order between the steps may be changed.

3 is an operation flow chart for determining whether it is possible to generate a test input using a selected seed according to an embodiment of the present application.

Referring to FIG. 3, in step S310, the input generator 120 may select a seed.

Next, in step S320, a test input candidate group to which at least one preset attack rule is applied to seed information received by the input generator 120 may be created.

Next, in step S330, the input generator 120 may determine whether all of the test input candidate groups have a record input as a test input to the target software.

Next, in step S340, the input generation unit 120, if there is a test input candidate that has no record input as a test input in the target software among the test input candidate groups, it is determined as a test input to test the test input ( 130).

Conversely, if all of the test input candidate groups have records input as test inputs to the target software, all of the test input candidate groups are discarded and the input generation unit 120 can receive new seed information from the first storage unit 110. have.

In the above description, steps S310 to S340 may be further divided into additional steps, or combined into fewer steps, according to embodiments herein. In addition, some steps may be omitted if necessary, and the order between the steps may be changed.

4 is an operation flow chart for detecting a crash according to an embodiment of the present application

Referring to FIG. 4, a method for detecting a software vulnerability based on a program path according to an embodiment of the present application may further include detecting a crash after inputting the test input to the target software. The step of detecting the crash may be to store the corresponding test input as a log when a crash occurs in the target software due to the step of inputting the test input to the target software.

Referring to FIG. 4, in step S410, the test unit 130 may input a test input to the target software.

Next, in step 420, the second storage unit 150 may determine whether a crash has occurred in the target software by a test input.

Next, in step 430, when the crash occurs, the second storage unit 150 may include information about the test input and store it as a log for in-depth analysis.

According to one embodiment of the present application, the log may include information on a test input that caused a crash or system information at the time.

In the above description, steps S410 to S430 may be further divided into additional steps, or combined into fewer steps, according to an embodiment of the present application. In addition, some steps may be omitted if necessary, and the order between the steps may be changed.

A software vulnerability detection method based on a program path according to an embodiment of the present application may be implemented in a form of program instructions that can be executed through various computer means and recorded in a computer readable medium. The computer-readable medium may include program instructions, data files, data structures, or the like alone or in combination. The program instructions recorded on the medium may be specially designed and configured for the present invention or may be known and usable by those skilled in computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs, DVDs, and magnetic media such as floptical disks. Includes hardware devices specifically configured to store and execute program instructions such as magneto-optical media, and ROM, .RAM (RAM), flash memory, and the like. Examples of program instructions include high-level language code that can be executed by a computer using an interpreter, etc., as well as machine language codes made by a compiler. The hardware device described above may be configured to operate as one or more software modules to perform the operation of the present invention, and vice versa.

In addition, the software vulnerability detection method based on the above-described program path may be implemented in the form of a computer program or application executed by a computer stored in a recording medium.

The above description of the present application is for illustrative purposes, and a person having ordinary knowledge in the technical field to which the present application belongs will understand that it is possible to easily change to other specific forms without changing the technical spirit or essential characteristics of the present application. Therefore, it should be understood that the embodiments described above are illustrative in all respects and not restrictive. For example, each component described as a single type may be implemented in a distributed manner, and similarly, components described as distributed may be implemented in a combined form.

The scope of the present application is indicated by the following claims rather than the above detailed description, and all changes or modifications derived from the meaning and scope of the claims and equivalent concepts should be interpreted to be included in the scope of the present application* .

100: software vulnerability detection device based on program path
110: first storage unit
120: input generation unit
130: test unit
140: program path detection unit
150: second storage unit

Claims (10)

In the software vulnerability detection method based on the program path,
Randomly selecting one seed from the seed pool;
Generating a test input by applying a preset attack rule to the selected seed;
Inputting the test input into a target software;
Determining whether a new program path of software has been searched by the test input; And
If a new program path is found, adding the test input to the seedpool,
Software vulnerability detection method based on the program path including the. According to claim 1,
Determining whether a test input can be generated using the selected seed,
The method further comprising, software vulnerability detection method based on the program path. According to claim 1,
The seed is normal input data or abnormal input data of the target software, software vulnerability detection method based on the program path. According to claim 1,
The preset attack rules,
A software vulnerability detection method based on a program path that is at least one of random bit operations, application of border values, and field size changes. According to claim 1,
The step of determining whether the new program path has been searched for is
A method of detecting a software vulnerability based on a program path, which determines whether a new source code region included in the target software that has not been executed by inputting the preceding test input to the target software has been executed. The method of claim 5,
Determining whether the new source code area has been executed is
A method for detecting a software vulnerability based on a program path, characterized in that it is performed by analyzing at least one of a code coverage change amount of a target software, a change in input/output response time, a change in output value, memory utilization, and other system information. According to claim 1,
After the step of inputting the test input to the target software,
Further comprising the step of detecting a crash,
The step of detecting the crash is a method for detecting a software vulnerability based on a program path that, when a crash occurs in the target software due to the step of inputting the test input into the target software, stores the corresponding test input as a log. In the software vulnerability detection device based on the program path,
A first storage unit for storing information on a seed that is a normal input or an abnormal input of the target software;
An input generating unit receiving seed information from the first storage unit and generating a new test input based on the seed information;
A test unit that inputs the test input into the target software and analyzes the response of the target software; And
Program path detection unit for detecting whether a new program path of the target software is searched by the test input,
Software vulnerability detection device based on the program path including the. The method of claim 8,
If a crash occurs in the process of analyzing the response of the software by the test unit, a second storage unit that stores information on the corresponding test input in a log form,
Software vulnerability detection device based on the program path, characterized in that it further comprises. The method of claim 8,
The program path detection unit,
Regarding the response of the software according to the test input, a code coverage change amount, a change in input/output response time, a change in output value, memory A software vulnerability detection device based on a program path, characterized in that it detects whether a new program path of the target software has been discovered by analyzing at least one of utilization amount and other system information.

Images