KR100875997B1 - Network Fuzzing Using Windows Sockets Application Program Hooking - Google Patents

Abstract

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a network fuzzing system and a method using a Windows Sockets Application Programming Interface (API) hooking. The present invention relates to a dynamic linked library injection for a network program running on an MS Windows operating system. By inserting the socket API hooking function into the network program, the network program intercepts packets to and from the other network program using the socket API function, and then adds various fuzzing data sets to the data in the packet. By manipulating the packet or sending it as an abnormal packet, network fuzzing is performed not only for the general protocol but also for an unknown protocol.

According to the present invention, network fuzzing is not only possible through socket API hooking through DLL injection using a network program using an arbitrary protocol, but also through network fuzzing, without going through conventional protocol analysis and fuzzing. In order to solve the conventional problem that consumes a lot of manpower and time from protocol analysis to the manufacture of the fuzzer.

Description

METHODO FOR NETWORK FUZZING APPARATUS USING WINDOWS SOCKET API HOOKING}

1 is a block diagram illustrating a network fuzzing system using a window socket application program hooking in accordance with the present invention.

2 is a flow chart illustrating a network fuzzing method using window socket application program hooking in accordance with the present invention.

<Explanation of symbols for main parts of the drawings>

10: DLL file module 12: network program module

12a: Socket API 14: main program module

14a: packet handler 16: database module

20: network program module 20a: socket API

The present invention relates to network fuzzing, and more particularly, to a network fuzzing method using a Windows Socket Application Programming Interface (API) hooking.

Fuzzing is a technique for generating various inputs and injecting them into a particular target to find vulnerabilities from that particular target.

Network fuzzing is one of the most common ways to find vulnerabilities in any network program by generating and injecting all kinds of abnormal packets targeting specific protocols used by networked programs, or by disrupting the communication order of specific protocols. It mimics the protocol on the network and sends various packets to the network program to test for the presence of the vulnerability.

Network fuzzing requires the creation of a separate program called a fuzzer that adheres to the protocol used by the network program.

In general, fuzzers that perform network fuzzing prioritize protocol analysis for a program that uses the target protocol for fuzzing. That is, a rough communication order and packet configuration of the protocol are examined, and a network fuzzing order or packet is generated accordingly. Based on this process, a suitable fuzzer is generated for the protocol, and the process from protocol analysis to fuzzer production takes more effort and time than actual network fuzzing.

There are many different types of network fuzzers, but the method they use is to emulate well-known protocols, and most of them are designed to manipulate the already analyzed protocols.

In addition, when attempting to purge an unknown protocol, the protocol analysis must be performed first, and the communication order and packet structure for the protocol must be newly created.

On the other hand, many fuzzing tools in the form of a network fuzzer framework are also known, and they provide a standardized packet transmission and reception technique for fuzzing for new protocols, but protocol analysis is entirely up to the user. The creation of the structure also depends entirely on the user. As a result, currently available network fuzzers can only purge on well-known protocols. Fuzzing of unknown protocols is only possible when new types of fuzzers are produced.

SUMMARY OF THE INVENTION The present invention has been made to solve the above-mentioned conventional problems, and an object of the present invention is a dynamic linked library injection (hereinafter referred to as a DLL injection) for a network program running on an MS Windows operating system. By inserting the socket API hooking function into the network program through the network program, the network program uses the socket API function to intercept packets to and from the other network program, and then adds various fuzzing data sets to the data in the packet. It provides a network fuzzing method using the Windows Socket API hooking that performs network fuzzing for unknown protocols as well as general protocols by manipulating or sending them as abnormal packets.

In order to achieve the above object of the present invention, a network fuzzing method using the window socket API hooking according to the present invention includes a window socket API hooking including a main program module, a DLL file module, and a database module in which a packet handler module is embedded. A network fuzzing system, comprising: a first step of injecting the DLL file module into the network program when the network program is executed in a Windows operating system; Hooking, by the DLL file module, a socket API of the network program according to a command of the main program module; And a third step of the database module storing and analyzing the transmission and reception packets of the network program in a database.

In one example, the injection of the DLL file module is performed by a DLL injection method using the CreateRemoteThread () function.

The DLL file module may block transmission / reception packets of the network program or decompose the data into fields to insert arbitrary data in a specific field, and transmit the data to the outside.

Preferably, the database module generates and stores a set of fuzzable data that can be inserted into the specific field.

If packets of the appropriate level determined by the user are collected, the main program module may further generate abnormal packets through the packet handler module and then transmit them to the outside to determine whether there is a problem in the purging target network program. do.

The fourth step may include transferring information about a fuzzing data set stored in the database module and a data region of the analyzed packet to a packet handler module in the main program module, and the packet handler module purging the data. And inserting a data set into the data region of the analyzed packet as appropriate, and transmitting the analyzed packet to the DLL file module by the main program module to transmit to the outside through a normal socket API. do.

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

First, before describing the embodiment of the present invention in detail, the DLL injection and API hooking applied to the present invention will be described.

DLL injection is a technique used to inject arbitrary dynamic library files into a program running on the MS Windows operating system.

API hooking is a technique used to change certain library functions defined in the MS Windows operating system in a way that a user wants. It is a mechanism that intercepts an API call in an application and executes a function of a separately developed program. Say. You can use many different languages or tools to develop any Windows application. Many languages and tools exist, including Visual Basic, Visual C ++, Delphi, C ++ Builder, and Power Builder. Although the methods used to perform certain tasks in applications written using these tools are different, when you go inside, you will eventually call APIs provided by the Windows operating system. For example, if you want to print a string to the screen, you use CDC :: DrawText in MFC (Microsoft foundation class) and TCanvas :: TextOut in Delphi. Each development tool uses a different format, but in the end, it calls the TextOutA / W API provided by the Windows operating system. The TextOutA / W API is a function implemented in gdi32.dll and is an API provided by the Windows operating system. Windows basically provides most of the APIs in three DLLs (kernel32.dll, user32.dll, and gdi32.dll), and the application maps these DLLs to their process address space during execution.

API hooking refers to the interception of API functions inside a DLL that is used in this way. The object to be hooked does not necessarily need to be a Windows API. API hooking is possible only if the function is implemented by providing a DLL.

API hooking can be applied to programs developed in any language, and can be used for debugging, bug tracking, monitoring, and for adding functions to programs without source code.

There are three main ways of hooking APIs: using the Registry, using System-wide Windows Hooks, and injecting DLLs using the 'CreateRemoteThread ()' function. .

API hooking using the Registry is only possible in very limited cases. This method is only applicable to applications that use USER32.DLL. This is because USER32 reads the value of a specific registry key and calls the 'LoadLibrary ()' function on these DLLs in DllMain. Another limitation is that this mechanism is only supported for NT and 2K operating systems. In addition, enabling and disabling API hooking requires a reboot of the Windows operating system, and API hooking for all applications can result in overhead.

The use of the system-wide Windows hooks is a very popular technique for infiltrating DLLs into the target process. As detailed in the Microsoft Developer Network (MSDN), hooks are an interception of message handling mechanisms on a system. Applications can install custom filter functions to monitor message exchanges in the system and to process certain types of messages before they reach the target window. Windows hooks here are completely different terms from API hooks, meaning the message hooks described in MSDN. Unlike the registry mechanism, the method of using the system-wide Windows hook is that the hook server determines that the DLL is no longer needed, and when the 'UnhookWindowsHookEx ()' function is called, the DLL can be unloaded. However, the window hook increases the processing of the message that the system should perform, which has the disadvantage of significantly deteriorating the performance of the entire system. Debugging system-wide hooks also requires a lot of effort.

The DLL injection method using the 'CreateRemoteThread ()' function is the most common method of infiltrating a DLL using a remote thread. This method is the idea of Jeffrey Ritcher and is best described in his article "Load Your 32-bit DLL into Another Process's Address Space Using INJLIB." Any process can load the DLL dynamically by calling the LoadLibrary () API. The question is how to make the external process call the 'LoadLibrary ()' function appropriately without accessing the thread of the process at all. The answer is 'CreateRemoteThread ()', which creates a single remote thread. Here is a little trick. In the prototype of the thread function, a pointer to this function is passed as a parameter (LPTHREAD_START_ROUTINE) to the 'CreateRemoteThread ()' function:

DWORD WINAPI ThreadProc (LPVOID lpParameter);

And here is the prototype of the LoadLibrary API.

These two functions have the same form. These functions use the same calling convention WINAPI, take a single parameter and return a value of the same size. These matches give you a hint that you can use the 'LoadLibrary ()' function as a thread function to run after the remote thread is created.

hThread = :: CreateRemoteThread (hProcessForHooking, NULL, 0,

pfnLoadLibrary, "C: \\ MyHook.dll", 0, NULL);

Specify the full path name of the DLL as a parameter to the thread function and cast to LPVOID. When the remote thread starts, the name of the DLL is passed as a parameter to the thread function (LoadLibrary).

In other words, 'CreateRemoteThread' is a function that creates a thread in another process, which takes the address of ThreadProc, a callback function for initialization, as a parameter. However, since the prototype of this callback function is very similar to LoadLibrary, and ThreadProc executes only once when created, passing the LoadLibrary address to ThreadProc will eventually cause the target process to call LoadLibrary to load the DLL into the process's address space. .

In the present invention, using these two techniques, it is possible to perform network fuzzing by generating / blocking / modifying network packets by attaching additional functions of socket API functions to a DLL file to be injected into a specific program.

1 is a block diagram illustrating a network fuzzing system using a window socket application program hooking according to the present invention.

Referring to FIG. 1, the DLL file module 10 hooks a socket API to a network program that runs on a Windows operating system with socket functions defined separately therein, for example, by a DLL injection method using a 'CreateRemoteThread ()' function. By injecting the DLL file with the built-in function, the packets transmitted and received by the socket APIs 12a and 20a of the different network program modules 12 and 20 are hooked and sent to the following main program module 14, or the following main program The module 14 transmits the desired specific packets to the outside through the socket APIs 12a and 20a of the different network program modules 12 and 20, and to each other according to the rules defined by the main program module 14 below. The socket APIs 12a and 20a of the other network program modules 12 and 20 block packets transmitted and received, or decompose packets transmitted and received for each field. Data is inserted and modulated and transmitted to the outside.

The main program module 14 collects and displays a list of network programs operated by the different network program modules 12 and 20 in the current Windows operating system via the DLL file module 10 and displays the DLL file module 10. Controls the loader to inject DLL files into the network program selected by the user, and to view and modify the packets of the send / receive network program sent and hooked by the DLL file module 10 for network fuzzing, or automatically by a specific rule. By modifying the packet, or by separately specified rule, the DLL file module 10 blocks the packet or decomposes the transmitted / received packet into each field so that arbitrary data can be inserted into a specific field and modulated. The packet handler 14a which also has the function of doing so is incorporated.

The database module 16 stores the packets of the transmit / receive network program collected by the main program module 14 into a database and performs packet analysis, and generates and stores a set of fuzzing data that can be inserted into each field in the packet for network fuzzing. The stored fuzzing data set contains contents defined by the user and is sequentially inserted into each field of the packet handled by the main program module 14 according to a rule set by the user.

When the main program module 14 performs automated network fuzzing, the database module 16 sequentially passes the set of fuzzing data inserted into each field of the packet to the packet handler 14a in the main program module 14. .

The network fuzzing system using the window socket API hooking according to the present invention configured as described above operates as follows by the method shown in FIG.

Referring to FIG. 2, a network program operated by a network program module 12 included in a network fuzzing system according to the present invention in a Windows operating system is connected by a network program module 20 connected to a network and communicating with a predetermined protocol. There is a working network program.

Here, the target of network fuzzing is the protocol used by these two network programs, but the actual target is the above-mentioned network program.

The two network programs may play the same role with the same interface, such as P2P or messenger program, or they may be programs with separate interfaces that play the role of server and client, respectively.

For reference, according to the present invention, the network fuzzing method using the Windows socket API hooking is not limited to such a program role, and simply selects a target of network fuzzing.

As described above, there is a network program operated by the network program module 20 connected to the network program operated by the network program module 12 included in the network fuzzing system according to the present invention and communicating with a predetermined protocol. At this time, the network program module according to the present invention first executes its own network program after the other network program, ie, the fuzzing target network program, which operates in the Windows operating system (S10).

Subsequently, the main program module 14 controls the DLL file module 10 to find a network program executed by the network program module according to the present invention, and injects a DLL file having a Windows socket API hooking function (S20). ).

At this time, the DLL file module 10 is a socket API function used by the network program executed by the network program module 12 according to the present invention, for example, Winsock 1.1 functions (send, sendto, recv, recvfrom) and Winsock 2. Hook the functions (WSASend, WSASendto, WSARecv, WSARecvFrom) and the like, and replace them with socket functions defined separately (S30). The separately defined socket functions may allow / modify / block packets transmitted and received by the network program executed by the network program module 12 according to the present invention according to the command of the main program module.

When the socket API hooking is performed as described above, before performing network fuzzing, the DLL file module simply stores packets of the network program to be transmitted and received in the middle according to the instructions of the main program module 14, and stores these packets in the main program. The packet handler 14a in the module 14 is transmitted to the packet handler 14a. Accordingly, the packet handler 14a sends the collected packets to the database module 16, stores them in a database, and analyzes them to generate a purging data set (S40). .

After the appropriate level of protocol packets determined by the user are collected and analyzed for the transmission / reception network program stored in the database, separately from the packets transmitted and received by the network program executed by the network program module 12 according to the present invention. The main program module 14 forcibly transmits abnormal packets using the packet handler 14a to determine whether there is a problem in the fuzzing target network program that receives the abnormal packets (S50).

Abnormal packet transmission proceeds as follows.

The database module 16 delivers the information about the purging data set and the data area of the analyzed packet to the packet handler 14a in the main program module 14 to perform automated network fuzzing. 14a appropriately inserts the purging data set into the data area of the analyzed packet. The main program module 14 then causes the DLL file module 10 to take the packet and transmit it to the outside via the normal socket APIs 12a and 20a. At this time, the database module 16 transfers the fuzzing data set inserted into each field of the packet to the packet handler 14a in the main program module 14 in order.

When the other party, i.e., the fuzzing target network program, responds to the forcibly sent packet, control thereof is also possible by the main program module 14 controlling the DLL file module 10. The packet handler 14a in the main program module 14 may allow / modify / block all transmitted and received packets.

The network fuzzing system and the method using the window socket API hooking according to the present invention described above are not limited to the service according to the above embodiment, and the present invention without departing from the gist of the present invention as claimed in the following claims. Anyone with ordinary knowledge in this field will have the technical spirit of the present invention to the extent that it can be variously modified and implemented.

According to the network fuzzing system and the method using the Windows socket API hooking according to the present invention as described above, through a DLL injection using a network program using any protocol, without going through the conventional protocol analysis and fuzz production Socket API hooking frees network fuzzing.

In addition, it is possible to completely solve the conventional problem that requires a lot of manpower and time from the protocol analysis to the manufacture of the fuser to perform the network purging.

Claims (6)

In the network fuzzing system using the Windows socket API hooking, including the main program module, DLL file module and database module with a built-in packet handler module, A first step of injecting the DLL file module into the network program by the main program module when a network program is executed in a Windows operating system; Hooking, by the DLL file module, a socket API of the network program according to a command of the main program module; And a third step of the database module generating and storing a set of fuzzable data insertable in a specific field and storing and analyzing the transmitted and received packets of the network program into a database. The method of claim 1, Injection of the DLL file module is a network fusing method using the Windows Socket API hooking, characterized in that performed by the DLL injection method using the CreateRemoteThread () function. The method of claim 1, The DLL file module is a method of network fuzzing using the Windows Sockets API hooking, which blocks or transmits and receives packets of the network program, or decomposes each field to insert and modulate arbitrary data in a specific field and transmit the data externally. delete The method of claim 1, If packets of the appropriate level determined by the user are collected, the main program module may further generate abnormal packets through the packet handler module and then transmit them to the outside to determine whether there is a problem in the purging target network program. Network fuzzing method using the Windows Sockets API hooking, characterized in that. The method of claim 5, The fourth step, Passing information about a purging data set stored in the database module and a data region of the analyzed packet to a packet handler module in the main program module; The packet handler module properly inserting the fuzzing data set into a data region of the analyzed packet; And the main program module forwarding the analyzed packet to the DLL file module to transmit to the outside through a normal socket API.

Images