General vulnerability test tool design

Author: Yuan Ge [yuange@nsfocus.com]
Home: http://www.nsfocus.com
Date: 2002-3-12

Currently, information security has become a hot industry, and program vulnerabilities play an important role in information security. Therefore, we need to study how to study vulnerabilities and find bugs in programs.
In my summary of vulnerability research methods, I have summarized some experiences in establishing security models, source code, binary code analysis, and other research methods. However, in general, I am still searching for vulnerabilities manually, this is also highly demanding for researchers. Nowadays, a large number of service software are available, and there are basically loopholes. It is obvious that the analysis code tests by personnel alone cannot meet the requirements, therefore, we need to design a testing tool that is more automated and suitable for most servers. I have also compiled test tools to assist with research. However, the previously written getiisfile is still highly targeted. It can only be used for some research on web services and is not automated enough.
How can we design a general testing tool? Different services have different protocols, and many vulnerability studies are also highly relevant. Therefore, we often study a Service Vulnerability first to study its protocol and familiarize ourselves with its software, then study the vulnerability. This is obviously a long process, so our testing software cannot follow this path. If we also need to "master" the protocol knowledge of each service in our testing software, we obviously cannot achieve good universality, so we need to extract some service commonalities. Think about it. Most of the current service models are a server and a client. The two use the communication protocol to communicate, so the common feature of the service is data packet communication. What is the content of each data packet, that is, the Protocol adopted by each service. Our test procedure cannot involve specific protocols. Think about it, like IIS. the HTR overflow packet is the request "Get/AAA. "AAA. the HTR domain is long. The iis ipp overflow package is the request "Get/. printer HTTP/1.1/R/n HOST: host "the" host "domain is long and does not exceed a range. Isn't the problem that the data in a certain field in the package is too long or the value is incorrect? Therefore, the main task of our vulnerability testing tool is to construct and automatically send problematic packages of data in a specific domain. How to construct such a package? We can use the script method to specify how to construct and construct a package. To test different services, you only need to write a simple script for the service, so that the program can be universal. Different services adopt different protocols, and the packages they receive must have certain protocol requirements. How can we solve the Protocol problem. We can use the sample package method, that is, the script provides a sample package. The construction package is based on the sample package, so that the Protocol requirements of the package can be met, we also need to understand the Protocol requirements for testing each service.
In fact, there are two main good ideas for our design: script, which makes our program more generic and flexible. Another is the solution of the sample package. This shields the specific protocol, so our test is basically unrelated to the Protocol. For example, to test a new database software vulnerability, you do not need to analyze its protocol and package format before starting.

Now the basic design scheme is clear, and the rest is to consider what content the script contains to perform tests more effectively.
We can put some related parameters provided by the script into a section, so that our program can read the script parameters and write and read the script by ourselves. In addition, it is better to support annotations.
1. test objectives;
1. Target IP address;
2. Protocol; the protocol here is of course UDP, TCP, ICMP, etc;
3. Port; some protocols do not have the port concept;
4. These items may be provided directly through the sample package.
Ii. Sample packages;
1. the method provided by the sample package; for more effective testing, we need to provide the sample package in multiple ways. For example, the sample package is directly provided in the script, which requires processing the input of the package. For example, if our script separates various script variables with line breaks by carriage return, the sample package obviously needs to process line breaks by carriage return, there is still a problem of 0, and the character input cannot be displayed, so basically a hexadecimal input and a mixed input method of direct character INPUT are required. A sample package is provided through a sample package data file. Sample packages are provided by capturing packets. This capture package provides a sample package, which allows us to test in a specific application environment, because the test result of this testing tool is obviously dependent on the sample package to be a benchmark for problematic packages, therefore, the richer the sample package, the more tests will be performed. Another test goal that can be the first item can also be provided through the sample package.
3. Testing package assembly;
1. Fixed messages sent before sending packets. For example, for some FTP tests, authentication may be required, but the command processing after the test and authentication is required. You can send the authentication content before each package, so that you can pass the authentication.
2. The separator of the sample package. It is used to separate the fields of the sample package. multiple separators can be specified. For example, the request "Get/a. HTR? A = var1 & B = var2 HTTP/1.1/R/nhost: Host/R/n/R/N ", there may be spaces "","?" , "=", "&", "/R", "/N", ":", etc., of course, the hexadecimal input must also be handled.
3. Test domain range. Test the range from the nth to nth fields after the packages are separated, or test the offset from the offset of the sample package.
4. Test type. Common Errors in a package processed by the service software are packet string processing errors and numerical errors.
For string testing:
5. The added domain prefix and suffix. For example, to test CGI, you may need a fixed string ". cgi" after the URL domain ".
6. Start length, end length, and step size of the domain string test;
7. Fill in the characters used. Generally, the test may be filled with "A". However, if you want to test whether the processing of that field has a format string, you may need to fill in strings such as "% s" and "% N.
For numerical testing:
8. Unit of Value Field (byte, word, dual-word), start, end, and step size;
4. Send the test package;
1. Whether the blocking mode is used;
2. Whether to reconnect each packet sending;
3. Wait time between two packages;
4. Number of sent packets per package;
5. Return information processing;
1. Whether to receive the returned information;
2. Whether the returned information is recorded;
3. Search and alarm processing for the returned information feature string. For example, if IIS returns "The Remote Procedure Call failed", an error occurs in the RPC service, which is generally caused by overflow or vulnerabilities, logs can be recorded in alarms or logs.
4. analyze and process returned information to identify service problems. This may be difficult at the moment.
For example:
Getiisfile www.iis.com 80 "Get/" 1 A. Ida
"The IDQ file C:/inetpub/wwwroot/a. IDA is not found ."
Getiisfile www.iis.com 80 "Get/" 10 a. Ida
"The IDQ file C:/inetpub/wwwroot/aaaaaaaaaa. IDA is not found." is returned ."
Getiisfile 61.132.55.67 80 "Get/" 239 A. Ida
Return "C:/inetpub/wwwroot/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
Bytes
Bytes
Aaaaaaaaaaaaaaaaaaaaaaaaaaaaa. I ????? R. The system cannot find the specified path ."
Obviously, an error has occurred in this program. The 239 "A" requests are different from one or 10 "A" requests, there is an additional tail "????? R ". In fact, the strncpy call does not end with a string, which leads to the leakage of stack content. To automatically identify these problems based on the returned information, it may be difficult to implement the algorithm. We still need to use manual identification to solve this problem.
Vi. log;
1. log of the test status to facilitate continued testing after the test is stopped.
2. The status of each test and the log of the returned information;

In this way, we can construct and send various packages. Obviously, we still have to know the effect of these packages, and there is no problem with the service software. Currently, it is not enough to judge the problem mainly based on the returned information. Only a few pieces of information can be collected, and the main information is obviously on the server, therefore, we also need software running on the server to check the status of the service software. You can start from the following aspects:
I. memory usage monitoring. This can be used to monitor existing software or write software to detect vulnerabilities in which memory is not released.
Ii. Abnormal monitoring; for example, memory access due to overflow or invalid values may lead to some exceptions, and the CPU in this protection mode may cause an abnormal interruption, in Windows, the program will return NTDLL. DLL extraction function "kiuserexceptiondispatcher" entry, so you can write software to intercept this entry or set this breakpoint under soft-ice, and then according to the data structure provided by calling this entry, obtain the EIP and other register content when an exception occurs, and determine whether the program is actually faulty. * In a nix system, you can use the loadable kernel module (lkm) to intercept abnormal system interruptions and perform comprehensive judgment. If you write a program, the difficulty lies in the algorithm used to determine whether the program is wrong or vulnerable. However, it seems that the program is still optimistic, and there is a problem in the case of exceptions. * The nix system basically does not have the concept of structure exception. Therefore, generally, when a program error occurs, the process will basically die, so it is well judged. The memory is switched out. If the Windows system recognizes the exception, it will not return to this entry. If Windows finishes a thread, it may enter this entry, but basically, the EIP with an exception is relatively fixed, so it is well ruled out. However, Windows programming has the concept of structural exceptions, so if exceptions are not intercepted, many program errors may not be exposed.
3. Monitoring of Service Process status. For example, if many service programs have problems, the system may kill the service process, and the iis5 system will automatically restart the service process, * systems such as nix may generate dump operations. Therefore, we can determine whether the service software has Errors Based on the information.