Fuzzing platform device and fuzzing control method

Abstract

To reduce execution cost and personal dependency required for fuzzing.SOLUTION: A fuzzing platform device that controls fuzzing for an object program includes one or more calculators, one or more memory resources, and one or more storage devices, wherein the calculators execute pre-fuzzing for the object program subsequently using a plurality of fuzzing engine candidates, and select a fuzzing engine used in the fuzzing for the object program among the plurality of fuzzing engine candidates, on the basis of the result of the pre-fuzzing.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a fading platform device and a fading control method.

Background Art

[0002] Cyber security damage caused by attacks exploiting vulnerabilities is increasing and becoming serious, and countermeasures are necessary. In such a situation, there are services that detect program vulnerabilities and bugs using fuzzing technology. Fuzzing is a technology for inspecting bugs and vulnerabilities in a program by trying various inputs against the program. By detecting bugs and vulnerabilities in the program by fuzzing and fixing them, it is expected to prevent the exploitation of bugs and vulnerabilities and the damage caused by them.

[0003] On the other hand, systems that execute fuzzing (hereinafter referred to as fuzzing engines) differ in usage methods and targets, and it is difficult to use them uniformly. It is necessary to be familiar with the usage method for each fuzzing engine and the program targeted for fuzzing. In addition, each fuzzing engine has its own strengths and weaknesses and differences in functions, so it is not easy to determine which fuzzing engine should be used for the program targeted for fuzzing.

[0004] Currently, since various systems are connected to the network, it is desirable that not only security experts but also all developers can perform fuzzing as before. Therefore, the current situation where a certain level of expertise and proficiency is required for using a fuzzing engine as described above is not desirable. Also, even after selecting and acquiring a fuzzing engine, the fuzzing technology has problems such as high execution costs and dependency, which hinder the expansion of the target range and business scale of the fuzzing service.

[0005] Regarding fuzzing, for example, Patent Document 1 describes "a method for analyzing the vulnerability of a deployed program, comprising the steps of: receiving a binary program under analysis (BPUA) derived from the deployed program; analyzing the input / output (I / O) behavior of the deployed program; discovering inputs to the deployed program based on the application of two or more investigation techniques to the BPUA and the analysis of the I / O behavior; determining which of the inputs is a negative input, wherein the negative input includes a portion of the input that triggers a response containing a vulnerability in the deployed program; developing a patch for the deployed program to handle at least some of the negative inputs without modifying the deployed program to trigger a response containing a vulnerability, based on the negative inputs and the triggered response; and automatically dispatching the patch to the deployed program."

[0006] Furthermore, Non-Patent Document 1 describes a method for automatically tuning a fuzzing engine to improve performance such as coverage.

[0007] Furthermore, Non-Patent Document 2 describes a tool that allows fuzzing to be easily performed from a GUI (Graphical User Interface). [Prior art documents] [Patent Documents]

[0008] [Patent Document 1] Japanese Patent Publication No. 2016-167262 [Non-patent literature]

[0009] [Non-Patent Document 1] Yuki Koike, Hiroyuki Katsura, Hiromu Yakura, and Yuma Kurogome: SLOPT: Bandit Optimization Framework for Mutation-Based Fuzzing, In Proceedings of the 38th Annual Computer Security Applications Conference (ACSAC '22), pp. 519-533 (2022), https: / / dl.acm.org / doi / abs / 10A145 / 3564625.3564659 [Non-Patent Document 2] Miyagi R, Yoshida N, Fujiwara K, Tsuzuki N, Yamamoto R, Takada H: Fuzz4B: A support tool for using the fuzzing tool AFL, Computer Software, Vol. 39, No. 2, pp. 124-142 (2022), https: / / doi.org / 10A1309 / jssst.39.2_124 [Overview of the project] [Problems that the invention aims to solve]

[0010] According to the technology described in Patent Document 1, vulnerabilities in a target program can be automatically discovered by combining fuzzing. However, its use requires expertise, and there are challenges in terms of usability and scalability.

[0011] The technology described in Non-Patent Document 1 differs from the present invention in terms of scope (effective range of variables and functions).

[0012] The technology described in Non-Patent Document 2 has limitations in the available fuzzing engines, which in turn restricts the available fuzzing methods and target programs.

[0013] As mentioned above, while technologies exist to enhance and support fuzzing, challenges remain, such as the high cost and reliance on individual expertise in fuzzing execution.

[0014] The present invention has been made in view of the above points, and an object thereof is to reduce the execution cost and personal nature required for fuzzing.

Means for Solving the Problems

[0015] This application includes a plurality of means for solving at least a part of the above problems. For example, they are as follows.

[0016] To solve the above problems, a fuzzing platform device according to an aspect of the present invention is a fuzzing platform device that controls fuzzing for a target program, and includes one or more computers, one or more memory resources, and one or more storage devices. The aforementioned memory device holds information about the fuzzing engine, The computer From the retained fuzzing engines, those that can be used for fuzzing the target program are selected as fuzzing engine candidates, and the selected performs pre-fuzzing for the target program by sequentially using fuzzing engine candidates, For each of the aforementioned fuzzing engine candidates and based on the result of the pre-fuzzing Based on the number of execution paths, crashes, bugs, and CVSS score. selects a fuzzing engine to be used for the fuzzing of the target program from among the plurality of fuzzing engine candidates.

Effects of the Invention

[0017] According to the present invention, it is possible to reduce the execution cost and personal nature required for fuzzing.

[0018] Problems, configurations, and effects other than those described above will be clarified by the description of the following embodiments.

Brief Description of the Drawings

[0019] [Figure 1] FIG. 1 is a diagram showing a configuration example of a fuzzing platform system according to a first embodiment of the present invention. [Figure 2] FIG. 2 is a diagram showing an example of a fuzzing task list. [Figure 3] FIG. 3 is a diagram showing an example of a fuzzing engine list. [Figure 4]FIG. 4 is a diagram showing an example of a list of execution environments. [Figure 5] FIG. 5 is a diagram showing an example of a list of fuzzing results. [Figure 6] FIG. 6 is a flowchart for explaining an example of fuzzing engine recommendation processing. [Figure 7] FIG. 7 is a flowchart for explaining an example of a series of processes after fuzzing engine recommendation processing. [Figure 8] FIG. 8 is a flowchart for explaining an example of fuzzing task registration processing. [Figure 9] FIG. 9 is a flowchart for explaining an example of fuzzing execution processing. [Figure 10] FIG. 10 is a flowchart for explaining an example of fuzzing result registration processing. [Figure 11] FIG. 11 is a flowchart for explaining an example of UI screen generation processing. [Figure 12] FIG. 12 is a diagram showing an example of the display of a UI screen. [Figure 13] FIG. 13 is a flowchart for explaining an example of fuzzing engine registration processing. [Figure 14] FIG. 14 is a flowchart for explaining an example of execution environment registration processing. [Figure 15] FIG. 15 is a flowchart for explaining a modified example of fuzzing execution processing. [Figure 16] FIG. 16 is a diagram showing a configuration example of a fuzzing platform system according to the second embodiment of the present invention. [Figure 17] FIG. 17 is a diagram showing an example of a list of additional functions. [Figure 18] FIG. 18 is a flowchart for explaining an example of function addition processing. [Figure 19] FIG. 19 is a flowchart for explaining an example of vulnerability supplement processing. [Figure 20] FIG. 20 is a flowchart for explaining an example of priority setting processing. [Figure 21]Figure 21 is a flowchart illustrating an example of the correction patch generation process. [Modes for carrying out the invention]

[0020] Hereinafter, several embodiments of the present invention will be described with reference to the drawings. In all drawings used to describe each embodiment, the same reference numerals are used for identical components, and repeated descriptions are omitted. Furthermore, in the following embodiments, the components (including element steps, etc.) are not necessarily essential unless specifically stated, or unless they are clearly essential in principle. Also, when referring to "consisting of A," "being made of A," "having A," or "including A," other elements are not excluded unless specifically stated to refer only to that element. Similarly, in the following embodiments, when referring to the shape, positional relationship, etc., of components, etc., it includes those that are substantially similar or approximate to their shape, etc., unless specifically stated, or unless it is clearly not the case in principle.

[0021] <Example of configuration of fuzzing platform system (hereinafter referred to as fuzzing PF system) 10-1 according to the first embodiment of the present invention> Figure 1 shows an example configuration of a fuzzing PF system 10-1 according to the first embodiment of the present invention.

[0022] The fuzzing PF system 10-1, for a program that inspects for bugs and vulnerabilities by fuzzing (hereinafter referred to as the target program), identifies the optimal fuzzing engine from among several different fuzzing engines that have been pre-registered in a single environment, and then executes fuzzing using the identified fuzzing engine.

[0023] The fuzzing PF system 10-1 comprises a fuzzing platform device (hereinafter referred to as the fuzzing PF device) 100, and user terminals 20a to 20c connected to the fuzzing PF device 100 via a network 12.

[0024] Network 12 is a bidirectional communication network such as a LAN (Local Area Network), WAN (Wide Area Network), or the Internet. User terminals 20a to 20c are general computers such as personal computers. Hereafter, when it is not necessary to distinguish between user terminals 20a to 20c individually, they will simply be referred to as user terminal 20.

[0025] The fuzzing PF device 100 consists of a general computer such as a server computer or personal computer, equipped with a processor 101 such as a CPU (Central Processing Unit), memory 102 such as DRAM (Dynamic Random Access Memory), storage 104 such as an HDD (Hard Disk Drive) or SSD (Solid State Drive), communication interface 105 such as an Ethernet® card or Wi-Fi® adapter, and input / output devices 106 such as a keyboard, display, and media drive. The processor 101 corresponds to the computer of the present invention.

[0026] The processor 101 executes the program 103 stored in memory 102 to realize the following functional blocks: the fuzzing engine recommendation unit 111, the fuzzing task registration unit 112, the fuzzing execution unit 113, the fuzzing result registration unit 114, the UI screen generation unit 115, the fuzzing engine registration unit 116, and the execution environment registration unit 117.

[0027] The program 103 may be stored in memory 102 in advance, or it may be read from storage 104, input from input / output device 106, or downloaded from another device via communication IF 105 and stored in memory 102 when needed.

[0028] The fuzzing engine recommendation unit 111 performs a fuzzing engine recommendation process to recommend a fuzzing engine to be used for fuzzing the target program. The fuzzing task registration unit 112 performs a fuzzing task registration process to register the fuzzing task with the fuzzing PF device 100. The fuzzing execution unit 113 performs a fuzzing execution process to perform fuzzing on the target program. The fuzzing result registration unit 114 performs a fuzzing result registration process to generate fuzzing results. The UI screen generation unit 115 performs a UI screen generation process to generate a UI screen to present the results of each of the above processes to the user. The fuzzing engine registration unit 116 performs a fuzzing engine registration process to register the fuzzing engine with the fuzzing PF device 100. The execution environment registration unit 117 performs an execution environment registration process to register the execution environment for running the target program with the fuzzing PF device 100. Details of each process will be described later.

[0029] Storage 104 stores the fuzzing task list 131, the fuzzing engine list 132, the execution environment list 133, and the fuzzing result list 134.

[0030] The fuzzing task list 131 records information about the fuzzing task. The fuzzing engine list 132 records information about the fuzzing engine. The execution environment list 133 records information about the execution environment. The fuzzing results list 134 records the fuzzing results.

[0031] Next, Figure 2 shows an example of a fuzzing task list 131. The fuzzing task list 131 records information for each item associated with the task ID, including registration date and time, start date and time, completion date and time, target program, execution environment ID, fuzzing engine ID, status, and result storage path. However, the items recorded in the fuzzing task list 131 are not limited to the example described above.

[0032] The Task ID is identification information used to uniquely identify the fuzzing task. The Registration Date and Time is the date and time the fuzzing task was registered. The Start Date and Time is the date and time the fuzzing task was started. The Completion Date and Time is the date and time the fuzzing task was completed. The data format for the Registration Date and Time, Start Date and Time, and Completion Date and Time is arbitrary; any data format that allows for the identification of a date and time, such as Unixtime, may be used. The same applies to the other date and time information described below.

[0033] The target program is information that identifies the program that the fuzzing task will fuzz. The execution environment ID is information that represents the execution environment of the target program corresponding to the fuzzing task, and is linked to a single record in the execution environment list 133 described later. The fuzzing engine ID is information that identifies the fuzzing engine used by the fuzzing task, and is linked to a single record in the fuzzing engine list 132 described later.

[0034] The status is information that indicates the execution status of the fuzzing task, and records such as "Completed," "In Progress," and "Not Executed." "Completed" indicates that the fuzzing execution process and the fuzzing result registration process corresponding to the fuzzing task have been completed. "In Progress" indicates that the fuzzing execution process has started (running or completed), but the fuzzing result registration process has not been executed. "Not Executed" indicates that neither the fuzzing execution process nor the fuzzing result registration process has been executed.

[0035] The result storage path represents the path to the result of the fuzzing execution process for the fuzzing task in question.

[0036] For example, in Figure 2, the task with task ID "2" indicates that the registration date and time is "2022 / 01 / 01 09:00:00", the start date and time is "2022 / 01 / 01 12:00:00", the completion date and time is "2022 / 01 / 02 23:50:00", the target program is "PUT / a.exe", the execution environment ID is "0", the fuzzing engine ID is "0", the status is "Completed", and the result storage path is "result / 0 / ".

[0037] Next, Figure 3 shows an example of the fuzzing engine list 132. The fuzzing engine list 132 records information for each item, such as registration date and time, name, execution path, and options, associated with the fuzzing engine ID. However, the items recorded in the fuzzing engine list 132 are not limited to the example described above.

[0038] The fuzzing engine ID is identification information used to uniquely identify the fuzzing engine. The registration date and time is the date and time the fuzzing engine was registered. The name is the name of the fuzzing engine. The execution path represents the path used to execute the fuzzing engine.

[0039] The options represent the options available when running the fuzzing engine. For example, the option "-o" allows you to specify the IP address and port number to be fuzzed by providing them in the format "IP_ADDR:PORT". The option "-E" allows you to specify the number of times to run fuzzing by providing the number of runs in the format "NUM_FUZZING". Note that for each run of fuzzing, the parameters (initial values ​​and input values) are changed.

[0040] For example, in Figure 3, the fuzzing engine with fuzzing engine ID "0" indicates that the registration date and time is "2019 / 01 / 01 14:30:00", the name is "Fuzzer_A", the execution path is "fuzzer / fuzzer_A", and the options are "-o" and "-E".

[0041] Next, Figure 4 shows an example of the execution environment list 133. The execution environment list 133 records information for each item, such as registration date and time, name, type, architecture, bit width, OS, and storage path, associated with the execution environment ID. However, the items recorded in the execution environment list 133 are not limited to the example described above.

[0042] The execution environment ID is identification information used to uniquely identify the execution environment. The registration date and time is the date and time the execution environment was registered. The name is the name of the execution environment. The type represents the type of the execution environment. Types recorded include "VM (VM Virtual Machine)", "Container", "Simulator", etc. The architecture represents the architecture (hardware configuration) of the execution environment. The bit width represents the bit width of the architecture of the execution environment. The OS represents the operating system of the execution environment. The storage path represents the path to this execution environment.

[0043] For example, in Figure 4, the execution environment with execution environment ID "0" represents an execution environment with a registration date and time of "2019 / 04 / 01 11:10:00", a name of "VM_A_64bit", a type of "VM", an architecture of "CPU A", a bit width of "64bit", an OS of "OS A", and a storage path of "exec / vm / exec_0".

[0044] Next, Figure 5 shows an example of a fuzzing results list 134. The fuzzing results list 134 records information for each item, such as task ID, completion date and time, execution time, result storage path, number of execution paths, number of crashes, and number of bugs, associated with the fuzzing result ID. However, the items recorded in the fuzzing results list 134 are not limited to the example described above.

[0045] The Fuzzing Result ID is identification information used to uniquely identify the fuzzing result. The Task ID is information used to identify the fuzzing task that obtained the fuzzing result, and is associated with a single record in the Fuzzing Task List 131. The Completion Date and Time is the date and time when the fuzzing task that obtained the fuzzing result was completed. The Execution Time represents the time required to execute the fuzzing task that obtained the fuzzing result. The Result Storage Path represents the path to the result of the fuzzing task (fuzzing execution process) that obtained the fuzzing result.

[0046] The number of execution paths represents the number of paths executed in the fuzzing task (fuzzing execution process) that obtained the fuzzing result. The number of crashes represents the number of crashes that occurred in the fuzzing task that obtained the fuzzing result. The number of bugs represents the number of bugs detected in the fuzzing task that obtained the fuzzing result.

[0047] For example, in Figure 5, the fuzzing result with fuzzing result ID "0" corresponds to the fuzzing task with task ID "0", and indicates that the completion date and time is "2022 / 01 / 01", the execution time is "24 hours", the result storage path is "result / 0 / ", the number of execution paths is "1000", the number of crashes is "150", and the number of bugs is "10".

[0048] <About the fuzzing engine recommendation process> Next, Figure 6 is a flowchart illustrating an example of the fuzzing engine recommendation process performed by the fuzzing engine recommendation unit 111.

[0049] As a prerequisite for the fuzzing engine recommendation process, it is assumed that the target program has already been determined, and that multiple fuzzing engines are already registered in the fuzzing engine list 132 stored in storage 104.

[0050] The fuzzing engine recommendation process is initiated, for example, in response to a predetermined start command operation performed by the user using the user terminal 20.

[0051] First, the fuzzing engine recommendation unit 111 selects fuzzing engines from the fuzzing engine list 132 that are suitable for the target program, one by one, as fuzzing engine candidates (Step S1). Next, the fuzzing engine recommendation unit 111 uses the fuzzing engine candidates selected in Step S1 to perform fuzzing on the target program for a predetermined time (hereinafter, fuzzing using fuzzing engine candidates is referred to as pre-fuzzing). Then, the fuzzing engine recommendation unit 111 analyzes the results of pre-fuzzing to obtain the number of execution paths, the number of crashes, the number of bugs, and the CVSS (Common Vulnerability Scoring System) score (Step S2).

[0052] Next, the fuzzing engine recommendation unit 111 determines whether there are any fuzzing engines registered in the fuzzing engine list 132 that have not yet been selected as fuzzing engine candidates (step S3). If it determines that there are still unselected fuzzing engines (YES in step S3), the fuzzing engine recommendation unit 111 returns to step S1 and repeats steps S1 to S3.

[0053] Subsequently, if it is determined that there are no unselected fuzzing engines remaining (NO in step S3), the fuzzing engine recommendation unit 111 then selects a candidate fuzzing engine capable of maximizing fuzzing results, based on the result of step S2, as the fuzzing engine to be used for the fuzzing execution process, and recommends it to the user (step S4).

[0054] The selection of a fuzzing engine to be used for fuzzing execution can be based on the purpose of fuzzing. For example, the fuzzing engine with the highest number of execution paths, crashes, bugs, or CVSS score can be selected to maximize future fuzzing results. For example, selecting the fuzzing engine with the highest number of bugs can ensure the security of the target program. For example, selecting the fuzzing engine with the highest number of crashes can ensure the security of the target program and also serve as an operational test of the target program, confirming its reliability. Furthermore, selecting the fuzzing engine with the highest number of execution paths can be particularly beneficial and effective for operational testing of the target program. Alternatively, the fuzzing engine may be selected comprehensively based on at least one of the following: number of execution paths, number of crashes, number of bugs, and CVSS score.

[0055] Alternatively, instead of recommending a single fuzzing engine, multiple fuzzing engines may be recommended. In this case, the user can be given more options for the fuzzing engine to use in the fuzzing execution process (described later). This can also increase the rate at which bugs and other issues are detected during the fuzzing execution process.

[0056] Furthermore, the predetermined time for performing prefabrication may be determined and fixed in advance, taking into account computing resources, etc., or it may be dynamically changed during prefabrication, taking into account the results achieved up to that point.

[0057] Furthermore, when recommending a fuzzing engine, it may also be possible to recommend the options that should be adopted within the fuzzing engine. This concludes the explanation of the fuzzing engine recommendation process.

[0058] <Regarding the series of processes after the fuzzing engine recommendation process> Next, Figure 7 is a flowchart illustrating an example of a series of processes to be executed after the fuzzing engine recommendation process described above.

[0059] As a prerequisite for this series of processes, it is assumed that the fuzzing engine recommendation process has already been executed and that at least one record has been registered in the execution environment list 133.

[0060] First, the fuzzing task registration unit 112 performs a fuzzing task registration process in response to a predetermined start instruction operation by the user using the user terminal 20 (step S11).

[0061] Figure 8 is a flowchart detailing an example of the fuzzing task registration process. First, the fuzzing task registration unit 112 accepts the user's specification of the target program (step S21). Here, the user specifies the same program as the one used in the previously executed fuzzing engine recommendation process as the target program.

[0062] Next, the fuzzing task registration unit 112 accepts the user's specification of the execution environment to be used when executing the target program (step S22). Here, the user specifies one execution environment from the execution environments registered in the execution environment list 133.

[0063] Next, the fuzzing task registration unit 112 accepts the user's specification of a fuzzing engine (step S23). Here, the user selects a fuzzing engine recommended by the completed fuzzing engine recommendation process from the fuzzing engine list 132.

[0064] Next, the fuzzing task registration unit 112 issues a task ID and registers the target program, execution environment, and fuzzing engine received in steps S21 to S23 in the fuzzing task list 131, associating them with the task ID. Furthermore, the fuzzing task registration unit 112 registers the current date and time in the registration date and time field and registers "Not executed" in the status field, associating them with the task ID (step S24). This concludes the explanation of the fuzzing task registration process.

[0065] Note that the fuzzing engine accepted in step S23 may be a single engine or multiple engines. For example, one could specify multiple fuzzing engines and register a task that deploys the replicated target program to multiple execution environments and performs fuzzing simultaneously and in parallel using different fuzzing engines.

[0066] Returning to Figure 7, the fuzzing execution unit 113 then executes a fuzzing execution process in response to a predetermined start command operation by the user using the user terminal 20, for example, and stores the result (for example, a combination of input data for the target program and output data output from the target program in response to the input data) in the storage 104 or the like (step S12).

[0067] Figure 9 is a flowchart detailing an example of the fuzzing execution process. First, the fuzzing execution unit 113 refers to the fuzzing task list 131 and selects a task whose status is "not executed" (step S31).

[0068] Next, the fuzzing execution unit 113 registers the current date and time in the registration date and time field of the selected task, registers "running" in the status field, and uses the registered fuzzing engine to perform fuzzing on the registered target program in the registered execution environment, and stores the result in the storage 104 or the like. After the fuzzing is performed, the fuzzing execution unit 113 registers the current date and time in the completion date and time field of the selected task, and registers the path to the result of the fuzzing execution process in the result storage path field (step S32). This concludes the explanation of the fuzzing execution process.

[0069] Return to Figure 7. Next, the fuzzing result registration unit 114 executes the fuzzing result registration process in response to a predetermined start command operation by the user using the user terminal 20 (step S13).

[0070] Figure 10 is a flowchart illustrating an example of the fuzzing result registration process. First, the fuzzing result registration unit 114 refers to the fuzzing task list 131 and sequentially selects tasks with a status of "running" one by one (step S41). Here, tasks with a status of "running" are tasks in which the fuzzing execution process (Figure 9) has started (running or finished) and the fuzzing result registration process has not yet been executed. If there are no tasks with a status of "running", the fuzzing result registration unit 114 terminates the fuzzing result registration process at this point.

[0071] Next, the fuzzing result registration unit 114 determines whether or not the fuzzing execution process for the task selected in step S41 has been completed (step S42). This determination is made, for example, by determining that the fuzzing execution process has been completed if a path is registered in the result storage path item corresponding to the task selected in step S41 in the fuzzing task list 131, and not completed if the path is not registered. If it is determined that the fuzzing execution process for the task selected in step S41 has not been completed (NO in step S42), the fuzzing result registration unit 114 skips steps S43 to S45 and proceeds to step S46.

[0072] Conversely, if it is determined that the fuzzing execution process for the task selected in step S41 has finished (YES in step S42), the fuzzing result registration unit 114 retrieves the results of the fuzzing execution process from the result storage path corresponding to the task selected in step S41 in the fuzzing task list 131 (step S43). Next, the fuzzing result registration unit 114 analyzes the results of the fuzzing execution process and obtains the number of execution paths, the number of crashes, and the number of bugs (step S44).

[0073] Next, the fuzzing result registration unit 114 issues a fuzzing result ID and registers the task ID of the task selected in step S41, the number of execution paths, the number of crashes, and the number of bugs obtained in step S44 in the fuzzing result list 134, associating them with the fuzzing result ID. The fuzzing result registration unit 114 also registers the current date and time in the completion date and time field, the elapsed time from the start date and time of the corresponding fuzzing execution process to the present in the execution time field, and copies the path from which the results of the fuzzing execution process were obtained in step S43 to the result storage path field. Furthermore, the fuzzing result registration unit 114 updates the status of the task selected in step S41 in the fuzzing task list 131 to "Completed" (step S45).

[0074] Next, the fuzzing result registration unit 114 refers to the fuzzing task list 131 and determines whether there are any unselected tasks remaining among those with a status of "running" (step S46). If it is determined that there are unselected tasks remaining (YES in step S46), the process returns to step S41 and steps S41 onward are repeated. Conversely, if it is determined that there are no unselected tasks remaining (NO in step S46), the fuzzing result registration unit 114 terminates the fuzzing result registration process. This concludes the explanation of the fuzzing result registration process.

[0075] Next, Figure 11 is a flowchart illustrating an example of the UI screen generation process by the UI screen generation unit 115.

[0076] The UI screen generation process can be executed separately and independently of the series of processes following the fuzzing engine recommendation process described above (Figure 7). The UI screen generation process is started, for example, in response to a predetermined start command operation by the user using the user terminal 20.

[0077] First, the UI screen generation unit 115 refers to the fuzzing result list 134 and displays a list of fuzzing result IDs on the user terminal 20 screen for the user to select one. Then, the UI screen generation unit 115 obtains information about the fuzzing result, fuzzing task, fuzzing engine, and execution environment associated with the fuzzing result ID selected by the user from the fuzzing result list 134, fuzzing task list 131, fuzzing engine list 132, and execution environment list 133 (step S51).

[0078] Next, the UI screen generation unit 115 generates a UI screen 1000 (Figure 12) composed of the various information acquired in step S51, and displays it on the user terminal 20 as a web screen, for example (step S52). This concludes the explanation of the UI screen generation process.

[0079] Next, Figure 12 shows an example of the UI screen 1000 display. The UI screen 1000 has display fields 1001 to 1005. Display field 1001 displays the fuzzing result ID selected by the user. Display field 1002 displays the fuzzing result associated with the fuzzing result ID. Display field 1003 displays information about the fuzzing task associated with the fuzzing result ID. Display field 1004 displays information about the fuzzing engine associated with the fuzzing result ID. Display field 1005 displays information about the execution environment associated with the fuzzing result ID. However, for illustrative purposes, the information displayed in display fields 1002 to 1005 has been omitted as appropriate.

[0080] Furthermore, UI screen 1000 may display information other than the information described above, as long as it is related to the fuzzing result ID.

[0081] <Regarding the fuzzing engine registration process> Next, Figure 13 is a flowchart illustrating an example of a fuzzing engine registration process that needs to be executed prior to the fuzzing engine recommendation process (Figure 6) described above, and the series of processes that follow the fuzzing engine recommendation process.

[0082] The fuzzing engine registration process is initiated, for example, in response to a predetermined start command operation by the user using the user terminal 20. First, the fuzzing engine registration unit 116 issues a fuzzing engine ID to a fuzzing engine specified by the user, for example, and registers it in the fuzzing engine list 132. It then registers the current date and time in the registration date and time field, associated with the fuzzing engine ID (step S61).

[0083] Next, the fuzzing engine registration unit 116 receives information about the fuzzing engine (name, execution path, options, etc.) from the user (step S62). Then, the fuzzing engine registration unit 116 registers the information about the fuzzing engine received in step S62 in the fuzzing engine list 132, associating it with the fuzzing engine ID issued in step S61 (step S63). This concludes the explanation of the fuzzing engine registration process.

[0084] <About the execution environment registration process> Next, Figure 14 is a flowchart illustrating an example of an execution environment registration process that needs to be executed prior to the series of processes following the fuzzing engine recommendation process.

[0085] The execution environment registration process is initiated, for example, in response to a predetermined start command operation by the user using the user terminal 20. First, the execution environment registration unit 117 issues an execution environment ID and registers it in the execution environment list 133, and registers the current date and time in the registration date and time field, associated with the execution environment ID (step S71).

[0086] Next, the execution environment registration unit 117 receives information about the execution environment from the user (name, type, architecture, bit size, OS, storage path, etc.) (step S72). Then, the execution environment registration unit 117 registers the information about the execution environment received in step S72 in the execution environment list 133, associating it with the execution environment ID issued in step S71 (step S73). This concludes the explanation of the execution environment registration process.

[0087] According to the fuzzing platform system 10-1 described above, it is possible to recommend a fuzzing engine suitable for each target program, regardless of the user's knowledge of fuzzing or the target program. Furthermore, multiple fuzzing engines can be transparently handled for various types of target programs through a common interface. This makes it possible to reduce the execution cost and reliance on individual expertise related to fuzzing.

[0088] <Variations of the fuzzing execution process> Next, Figure 15 is a flowchart illustrating a modified version of the fuzzing execution process. In this modified version, fuzzing is performed on the target program after reproducing various surrounding environments, in addition to the execution environment, using a simulator or similar tool.

[0089] The surrounding environment refers, for example, to connecting devices (hardware) capable of inputting and outputting data to the target program to the network 12, or to running other programs (software) capable of inputting and outputting data to the target program simultaneously with the target program.

[0090] This modified example adds step S101 between steps S31 and S32 of the example of fuzzing execution process described above (Figure 9).

[0091] This modified version is initiated, for example, in response to a predetermined start command operation performed by the user using the user terminal 20.

[0092] First, the fuzzing execution unit 113 refers to the fuzzing task list 131 and selects a task whose status is "Not Executed" (step S31). The fuzzing execution unit 113 then constructs, for example, the surrounding environment specified by the user (step S101). Next, the fuzzing execution unit 113 registers the current date and time in the registration date and time field of the selected task, registers "Executing" in the status field, and then uses the registered fuzzing engine to perform fuzzing on the registered target program in the registered execution environment. After the fuzzing is performed, the fuzzing execution unit 113 registers the current date and time in the completion date and time field of the selected task and registers the path to the result of the fuzzing execution process in the result storage path field (step S32). This concludes the explanation of the modified fuzzing execution process.

[0093] According to a modified version of the fuzzing execution process, it is possible to reproduce not only the single execution environment but also the surrounding environment during fuzzing execution. This makes it possible to perform fuzzing on the target program while eliciting behaviors that would not manifest in standalone operation.

[0094] Furthermore, the fuzzing engine recommendation process (pre-fuzzing) may also be designed to reproduce the surrounding environment.

[0095] <Example of configuration of fuzzing PF system 10-2 according to the second embodiment of the present invention> Next, Figure 16 shows an example configuration of a fuzzing PF system 10-2 according to a second embodiment of the present invention.

[0096] The fuzzing PF system 10-2 is a modified version of the fuzzing PF system 10-1 (Figure 1) with the addition of a function addition unit 118, a vulnerability detection unit 119, a priority setting unit 120, and a correction patch generation unit 121 to the functional blocks implemented by the processor 101 of the fuzzing PF device 100. Furthermore, the fuzzing PF system 10-2 adds an additional function list 135 as information stored in the storage 104 compared to the fuzzing PF system 10-1.

[0097] Of the components of the fuzzing PF system 10-2, those other than the function addition unit 118, vulnerability detection unit 119, priority setting unit 120, correction patch generation unit 121, and the additional function list 135 are common to the components of the fuzzing PF system 10-1 and are assigned the same reference numerals, so their explanation is omitted.

[0098] The function addition unit 118 performs a function addition process to register processes (additional functions) to be executed simultaneously with or after fuzzing. The vulnerability detection unit 119 performs a vulnerability detection process to provide the user with information about vulnerabilities in the target program. The priority setting unit 120 performs a priority setting process to set the priority for responding to vulnerabilities revealed by fuzzing. The patch generation unit 121 performs a patch generation process to generate a patch to address vulnerabilities revealed by fuzzing. The additional function list 135 records information about the additional functions.

[0099] Figure 17 shows an example of an additional function list 135. The additional function list 135 records information for each item, such as registration date and time, name, execution path, options, and description, associated with the additional function ID. However, the items recorded in the additional function list 135 are not limited to the example shown above.

[0100] The additional function ID is identification information used to uniquely identify the additional function. The registration date and time is the date and time the additional function was registered. The name is the name of the additional function. The execution path represents the path used to execute the additional function.

[0101] The options represent the options available when executing the additional function. For example, the option "-o" allows you to specify the IP address and port number to be monitored by providing the IP address and port number in the format "IP_ADDR:PORT". The option "-i" allows you to specify the interval time for the additional function by providing the number of seconds in the format "INTERVAL_SEC". The description is a description of the additional function.

[0102] For example, in Figure 17, the additional function with additional function ID "0" has a registration date and time of "2019 / 01 / 01 14:30:00", a name of "WatchDog", an execution path of "plugin / wd", options "-o" and "-i", and its content is health management of the target program (for example, restarting in case of a crash).

[0103] Next, Figure 18 is a flowchart illustrating an example of the function addition process performed by the function addition unit 118.

[0104] The function addition process is initiated, for example, in response to a predetermined start command operation by the user using the user terminal 20. First, the function addition unit 118 issues an additional function ID and registers it in the additional function list 135, and registers the current date and time in the registration date and time field, associated with the additional function ID (step S111).

[0105] Next, the function addition unit 118 receives information about the additional function (name, execution path, options, description, etc.) from the user (step S112). Then, the function addition unit 118 registers the information about the additional function received in step S112 in the additional function list 135, associating it with the additional function ID issued in step S111 (step S113). This concludes the explanation of the function addition process.

[0106] The added functionality allows, for example, the target program to be restarted if it crashes during the fuzzing execution process.

[0107] Next, Figure 19 is a flowchart illustrating an example of vulnerability detection processing by the vulnerability detection unit 119.

[0108] The vulnerability detection process is initiated, for example, in response to a predetermined start command operation by the user using the user terminal 20. First, the vulnerability detection unit 119 refers to the fuzzing result list 134 and the fuzzing task list 131, displays a list of target programs for which fuzzing results have already been obtained on the screen of the user terminal 20, and allows the user to select the target program to be targeted for the vulnerability detection process. Then, the vulnerability detection unit 119 obtains the result of the fuzzing execution process for the selected target program (step S121).

[0109] Next, the vulnerability detection unit 119 obtains relevant vulnerability information from the results of the fuzzing execution process (step S122). For example, the vulnerability detection unit 119 performs a web search using the manifested vulnerability or the input that induced the vulnerability as keywords and obtains the search results. Alternatively, instead of performing a web search, or in addition to doing so, a database may be prepared in advance and the system may refer to that database.

[0110] Next, the vulnerability detection unit 119 displays the search results obtained in step S122 on the screen of the user terminal 20 and presents them to the user (step S123). This concludes the explanation of the vulnerability detection process.

[0111] Vulnerability detection processing allows the user to receive information related to keywords, such as the number of execution paths, crashes, and bugs obtained by analyzing the fuzzing results, as well as the manifested vulnerabilities and the inputs that triggered them.

[0112] Next, Figure 20 is a flowchart illustrating an example of the priority setting process performed by the priority setting unit 120.

[0113] The priority setting process is initiated, for example, in response to a predetermined start command operation by the user using the user terminal 20. First, the priority setting unit 120 refers to the fuzzing result list 134 and the fuzzing task list 131, displays a list of target programs for which fuzzing results have already been obtained on the screen of the user terminal 20, and allows the user to select the target program to be targeted for the priority setting process. Then, the priority setting unit 120 obtains the results of the fuzzing execution process corresponding to each selected target program (step S131).

[0114] Next, the priority setting unit 120 assigns a priority to the multiple vulnerabilities revealed in the target program based on the results of the fuzzing execution process, indicating the order in which they should be addressed first (step S132). For example, the priority setting unit 120 obtains the CVSS scores of the vulnerabilities revealed in the target program and assigns a higher priority to the vulnerability with the higher CVSS score. However, depending on the program's operating environment, vulnerabilities that do not require action may be given a lower priority even if they are generally considered to be of high risk.

[0115] Next, the priority setting unit 120 displays the priority assigned in step S133 on the screen of the user terminal 20 and presents it to the user (step S133). This concludes the explanation of the priority setting process.

[0116] Prioritization processing allows the user to be presented with the order in which vulnerabilities should be addressed first, in cases where multiple vulnerabilities exist in the target program.

[0117] Next, Figure 21 is a flowchart illustrating an example of the correction patch generation process by the correction patch generation unit 121.

[0118] The correction patch generation process is initiated, for example, in response to a predetermined start command operation by the user using the user terminal 20. First, the correction patch generation unit 121 refers to the fuzzing result list 134 and the fuzzing task list 131, displays a list of target programs for which fuzzing results have already been obtained on the screen of the user terminal 20, and allows the user to select the target program to be targeted by the correction patch generation process. Then, the correction patch generation unit 121 obtains the results of the fuzzing execution process for the selected target program (step S141).

[0119] Next, the patch generation unit 121 generates a patch based on the results of the fuzzing execution process (step S142). For example, the patch generation unit 121 may perform a web search based on the revealed vulnerability information to obtain correction information, or it may generate a patch that rejects the input that induced the vulnerability.

[0120] Next, the correction patch generation unit 121 displays the correction patch generated in step S142 on the screen of the user terminal 20 and presents it to the user (step S143). This concludes the explanation of the correction patch generation process.

[0121] The patch generation process allows the user to be presented with a patch to fix vulnerabilities in the target program.

[0122] The Fuzzing PF System 10-2 offers the same functions and effects as the Fuzzing PF System 10-1, in addition to providing users with various supplementary and support functions. Therefore, the Fuzzing PF System 10-2 enables simpler or more advanced fuzzing, reducing the execution costs and reliance on individual expertise associated with fuzzing.

[0123] The present invention is not limited to the embodiments described above, and various modifications are possible. For example, the embodiments described above are described in detail to make the present invention easier to understand, and are not necessarily limited to those having all the configurations described. Furthermore, it is possible to replace or add to the configurations of one embodiment with those of another embodiment.

[0124] Furthermore, each of the above configurations, functions, processing units, and processing means may be implemented in hardware, either partially or entirely, by designing them as integrated circuits, for example. Alternatively, each of the above configurations and functions may be implemented in software by a processor interpreting and executing programs that implement each function. Information such as programs, tables, and files that implement each function can be stored in memory, recording devices such as hard disks and SSDs (Solid State Drives), or recording media such as IC cards, SD cards, and DVDs. Also, control lines and information lines are shown only if deemed necessary for explanation, and not all control lines and information lines are necessarily shown in the actual product. In practice, it can be assumed that almost all configurations are interconnected. [Explanation of symbols]

[0125] 10-1, 10-2...Fuzzing PF system, 12...Network, 20...User terminal, 100...Fuzzing PF device, 101...Processor, 102...Memory, 103...Program, 104...Storage, 106...Input / Output device, 111...Fuzzing engine recommendation unit, 112...Fuzzing task registration unit, 113...Fuzzing execution unit, 114...Fuzzing result registration unit 115...UI screen generation section, 116...Fuzzing engine registration section, 117...Execution environment registration section, 118...Function addition section, 119...Vulnerability detection section, 120...Priority setting section, 121...Correction patch generation section, 131...Fuzzing task list, 132...Fuzzing engine list, 133...Execution environment list, 134...Fuzzing result list, 135...Additional function list, 1000...UI screen

Claims

1. A fuzzing platform device that controls fuzzing on a target program, It comprises one or more computers, one or more memory resources, and one or more storage devices. The aforementioned memory device holds information about the fuzzing engine, The aforementioned computer is From the retained fuzzing engines, those that can be used for fuzzing the target program are selected as fuzzing engine candidates. Pre-fuzzing is performed on the target program using the selected fuzzing engine candidates in order. A fuzzing platform device characterized by selecting a fuzzing engine to be used for fuzzing the target program from among the plurality of fuzzing engine candidates based on the number of execution paths, number of crashes, number of bugs, and CVSS score based on the pre-fuzzing results for each of the fuzzing engine candidates.

2. A fuzzing platform apparatus according to Claim 1, The aforementioned computer is A fuzzing platform apparatus characterized by selecting one or more of the fuzzing engines.

3. A fuzzing platform apparatus according to Claim 1, The aforementioned computer is A fuzzing platform device characterized by performing the fuzzing on the target program using the selected fuzzing engine.

4. A fuzzing platform apparatus according to claim 3, The aforementioned computer is A fuzzing platform apparatus characterized by performing at least one of the fuzzing and pre-fuzzing by reproducing the surrounding environment.

5. A fuzzing platform apparatus according to claim 3, The aforementioned computer is A fuzzing platform device characterized by performing a function addition process to register additional functions to be executed simultaneously with or after the fuzzing.

6. A fuzzing platform apparatus according to claim 3, The aforementioned computer is A fuzzing platform device characterized by performing vulnerability detection processing that provides the user with information regarding vulnerabilities in the target program.

7. A fuzzing platform apparatus according to claim 3, The aforementioned computer is A fuzzing platform device characterized by performing a priority setting process to set priorities when addressing vulnerabilities revealed by the fuzzing process.

8. A fuzzing platform apparatus according to claim 3, The aforementioned computer is A fuzzing platform device characterized by performing a patch generation process to generate a corrective patch to address vulnerabilities revealed by the fuzzing process.

9. A fuzzing control method using a fuzzing platform device that controls fuzzing on a target program, From among the fuzzing engines stored in the memory device, those that can be used for fuzzing the target program are selected as fuzzing engine candidates. Pre-fuzzing is performed on the target program using the selected fuzzing engine candidates in order. A fuzzing control method characterized by including the step of selecting a fuzzing engine to be used for fuzzing the target program from among the plurality of fuzzing engine candidates based on the number of execution paths, number of crashes, number of bugs, and CVSS score based on the pre-fuzzing results for each of the fuzzing engine candidates.

Images