Vulnerability Testing of HTTP based on Vulnerability-testing Oriented Petri Net (VOPN)

Transcription

1 Vulnerability Testing of HTTP based on Vulnerability-testing Oriented Petri Net () Li Weihai 1,2, Ma Yan 1,2, Huang Xiaohong 1 1 Research Institute of Networking Technology, Beijing Key Laboratory of Intelligent Telecommunications Software and Multimedia, Beijing, P.R.China 2 School of Electronic Engineering, Beijing University of Posts and Telecommunications, Beijing, P.R.China Abstract: Vulnerability-testing Oriented Petri Net (), a vulnerability testing model for communication protocol is brought forward first, which is combined Petri Net system with protocol Syntax analysis. Then vulnerability testing of implementation of HTTP protocol based on is made and the process is analyzed to prove the feasibility of the model. Key words: vulnerability testing; testing model; HTTP; Petri net I. introduction In computer network and protocol engineering, protocol testing has become the most active research field. Robustness testing and Interoperability testing are the important part of the protocol testing. And Robustness testing consists of performance testing and security testing[1]. The vulnerability testing, which is also an important kind of Robustness testing is made to find the weakness in a protocol implementation that allows an attacker to violate the integrity of the system in the internet. Collecting of vulnerability of a protocol implementation is very important, but unfortunately in vulnerability testing, the disclosure and fixing of vulnerabilities are expensive and inconvenient[2]. This paper introduces a systematic approach of vulnerability testing, brings up a model which combines Petri net and syntax analysis in vulnerability analysis. Then vulnerability testing of implementation of HTTP (Hyper Text Transfer Protocol) is made and the process is introduced in detail. II. Syntax Testing and its Extension Syntax testing is a kind of method for finding possible weakness in protocol implementation. In syntax testing, the test-cases, i.e. the to the software, are created based on the specifications of protocols realized by the interfaces of software[3]. Interfaces have many formats: command-line prompts, files, environment variables, pipes, sockets, etc. An interface has a specification which defines what is legal to the interface and what is not. The meaning of specification may be hidden

2 Broadband Network 宽带网络 or open. The motivation for testing based on the syntax analysis of this interface definition language springs from the fact that each interface has a specification, whether its meaning was hidden or open, from which effective vulnerability test cases can be created with a relatively small effort[3]. To find weakness in protocol implementation, fault injection is the main method to execute test in syntax testing. The selection of test cases could be single-error sentences, also could be proceed to pairs of errors, three errors combination, and so on. There are at least five kinds of error that can be produced in syntax analysis, which are Syntax error, Delimiter error, Field-value errors, Contextdependent errors, State dependency error[3]. Although having the advantages of low cost and high reliability, syntax testing has these shortcomings: a) Only the error in the implementation level can be detected by syntax testing. b) Not all of the part of the software can be detected, for there is no limit for errors. And because syntax testing focuses on protocol specifications analysis, it has the shortcoming in protocol analysis, especially in the state transition analysis. On the other hand, as a good protocol analysis tool, there are many new kinds of Petri net and it plays a more and more important role in protocol vulnerability analysis. The paper[4] brought an advanced Petri net for protocol conformance testing. But due to many differences between conformance testing and vulnerability testing, such as different perspectives, having or not having redundant element, this advanced Petri Net and many other similar kinds of Petri Net can t be directly used in vulnerability testing. To take advantage of Petri net in protocol state analysis, a new extended syntax testing method called (Vulnerability-testing Oriented Petri Net), which combined Petri net and syntax testing is brought forward here. It can compensate for lacking of protocol analysis in the former syntax testing method. III. MODEL OF EXTENDED SYNTAX ANALYSIS 3.1 Method flow The flow of the consists of three steps: Modeling, Analysis, and Fault injection (test cases running), which is explained in Figure 1. Modeling means to construct an extended Petri net model based on the text description of protocol to be tested. After this step, a of protocol was constructed; Analysis means to analyze the Petri net and design test cases from it; Fault Injection means to put data or message in test cases into the system under test (SUT), and to create the test report. Protocol Description Model Test cases Test Report Documents Fig.1 Flow of the Constructing Analysis Fault Injection(Test cases running) Steps 3.2 constructing In the stage of Constructing, e.g. Protocol Modeling, an extended Petri net was constructed according to the text protocol description. The was defined below The static structure of. Definition 1: The extended Petri net for vulnerability testing has eight members. P S =(P, T; F, A, X, C, t, M 0 ). 1) (P, T; F)is essential Petri net. P is place. T is transition. F is flow. 2) A is a non-empty limited set of resource. Resource can be variable, const or timer; 3) X is a limited set of fault, consisting of all possible types of fault, it must cling to A, and the element relation between A and X is one on multiple. When one resource a in A was

3 injected into SUT, it may have many corresponding x in X, which was denoted as a(x). 4)C is resource function, C:P U T P(A), P(A) is power set of resource set A. 5) Transition set T = T s U T r U T t, and T s T r T t =, T s is sending transition, denote sending operation, T t is receiving transition, denote receiving operation transition, and T t is timeout transition. 6) t is timeout function, t: T t 0 U N +, N + denote positive rational number. 7) M 0 is initialization identifier, M 0 :P A MS. Explanation of Definition 1:1) This is based on the essential Petri net. 2) When modeling the protocol, the resource set A in company with fault set X describe all the data, timer data and fault data that would be injected into SUT. 3) Resource function C defines the resource that belongs to every position p i P and every transition t i T. For p i P, C(p i ) means the resource set belong to it. For t i T, C(t i ) means all the resources that the transition needed, which is the necessary condition for the transition. 4) Transition set T denotes communication operation or timeout event. State of SUT will change when these events happen. 5) t defines the time limit of each timeout. 6) M 0 denotes the initialization state of the system Dynamic behavior A model s dynamic behavior regulated by these rules: 1) If all the positions of send transitions have at least a token, then this transition can take place. 2) If all of the position of receive transitions have at least a token, and the received resource is equal to the resource which belongs to the transition, then these transitions can take place. 3) If all the position belong to a timeout transition have at least one token, and the time is beyond the limit, the timeout transition can take place Denotation method The figure and table denote the model for. In the figure of, symbol based on that of Petri net was used to denote the dynamic behavior of protocol. Broken line denotes fault injection. Tables in explain the meaning of resource and fault. There will be four tables which are table of S 0 a 0 t1 S 1 a 0(x 0) Fig.2 A simple example of extended Petri net place, transition, resource, and fault. In the example in Figure 2, a client that in initialization state (s 0 ) transfers to the state of waiting for connection (s 1 ) by sending a connect request. The broken line denotes that the resource a 0 was injected fault of x 0 in sending transition. The client should keep staying at the initialization state and discard the fault connection request. 3.3 analysis After the construction of the, test cases could be got from the analysis of the model. In, the symbols that denote the state and the transition are the same to that in the essential Petri net. The element T denotes transition and the resource function denotes the resource related to transition. The element S denotes place, and place that has one or more states. Vulnerability X denotes types of all possible errors. The analysis rules were explained below. Seeking all transitions that describe communication. This type of transition is potential fault injection point. In Figure 2, t 1 denotes the client communicates with the server by sending a request to it. Choosing of fault type. The set of vulnerability defines the fault that could be injected into SUT. In syntax testing, there are five types of faults. Each place could be injected one or multiple fault. By the increasing of types of fault, the number of test cases will increase at exponential level. Expanding of table. Resource, fault type could be added continuously, and then numbers of test cases will increase. Thus the test will be more exhaustive. 3.4 Fault injection In the step of fault injection, the test case which generated in the stage of model analysis would be executed by a fault injector. The fault injector sends the fault data to the SUT by UDP, TCP, or

4 Broadband Network 宽带网络 other protocols, checks the result, and then generates the test report. IV. TESTING OF HTTP With the number of internet user increasing rapidly, and HTTP widely used[5], it is necessary to guarantee the robustness of HTTP client. Here the vulnerability testing of HTTP is brought. Figure 3 is a model of HTTP, and Table 1~4 describe the place, transition, resource and vulnerability of HTTP. According to the description of the protocol, the client of HTTP has four states, including No connection, Connected, Waiting for response, Response waiting close. These four states were denoted by four symbols from S 0 to S 3. In the state of No connection, the client transfers to Connected state by receiving request. In the state of connected, if the client sends the HTTP request according to the user action, it will transfer to the state of Waiting for response. These responses of the HTTP server trigger the transition if client state, so they could be denoted by transition. Table 2 explains the meaning of the transitions. s 0 t 3 s 3 a3 (x0, x1) t 0 s 1 Fig.3 of HTTP Client Places t 2 Table 1 Places of HTTP a0 (x1) t 1 s 2 meanings S 0 No connection S 1 Connected S 2 Waiting for response S 3 Response waiting close Table 2 Transitions of HTTP Transitions meanings t 0 Send connect.req t 1 Infomation.req t 2 Send/receive response t 3 Close connection Name type place meaning a 0 a 1 a 2 a 3 a 4 a 5 symbol Table 3 Example Resources of HTTP Version URI Time Char set Rep. line State line type, s 0,s 1,s 3 s 2 Table 4 Fault of HTTP HTTP version URI= http: // hostname.. Greenwich Time UTF-8 or GBK Request line in Request Msg. State line in Response Msg. meaning x 0 Delimiter errors Using other special symbol to substitute Delimiter in x 1 Char String errors Using other special string to substitute common string x 1 Length errors Using wrong length char string in message After the construction of the model, test cases can be got from the analysis of the model. In vulnerability testing, the fault injection was used to test the robustness of SUT. So adding fault in company with the sending transition and the resource can compose a test case. In Figure 3, a fault was injected into the transition of t 1, which was denoted by broken lines. And at the side of the broken line, the fault resource and the fault type were labeled. The label for the fault is a 0 (x 1 ), with a 0 explained in Table 3, and x 1 explained in Table 4. This fault is a CharString error injected into the URL in redirect request. The error message is: GET /test.htm HTTPxx1.1xxxxxxxxxxxxxxxxxxx In the fault injection stage, all the test cases were sent by UDP to the HTTP client. If the message sent is correct, the client way will transmit to the state of Waiting for response. If the Client received a wrong message it will reject the response and send back the corresponding message, while avoiding transmitting the wrong message to the

5 http server. Three type of fault were mostly used in the testing account for the characteristic HTTP: Char string abnormity: The abnormal char string consists of chars ASCII. In this example, we test many char numbers that can cause error. Length abnormity: Length abnormity means using integer of type of UINTVAR. Delimiter errors: Delimiter errors means puting wrong URL delimiter such as :+1000x /) into string to test the URL parser. V. RESULT OF TESTING We use the method of to test the open source HTTP client Maxthon For the 500 test cases, the Maxthon failed in 23. Among them, there are 0 length abnormity error, 13 Char string errors and 10 Delimiter errors, Every failure means a vulnerability that may be attacked by some methods, such as DOS. Mostly these failures may be caused by memory leak, stack overflow, or cache overflow. Of course, these test cases cannot find all of the possible vulnerability, and if time permits more and more test cases can be produced. Although it is believe that these test cases can cover all the transition, we hope more test cases and more elaborate model can be constructed to testing. Further works of may be computing of fault cover rate, simplification of the model, and test case autogeneration. Acknowledgments Specific thanks to Gang Liu, Bin Hou, Qing Ma, and Xing Zhao s help of completing the programme. Thanks also to Qiong Sun s advice for improving the paper. Finally, we acknowledge the valuable feedback provided by the anonymous reviewers and our colleagues at Beijing University of Posts & Telecommunication. References [1] DeVale J, Koopman P, Guttendorf D, The Ballista Software Robustness Testing Service, Testing Computer Software Conference, [2] Laakso M., Takanen A., Röning J.(1999). The Vulnerability Process: a tiger team approach to resolving vulnerability cases[eb/ol]. In proceedings of the 11th FIRST Conference on Computer Security Incident Handling and Response, Brisbane June, [3] Rauli Kaksonen, Marko Laakso, Ari Takanen. (2000). Vulnerability Analysis of Software through Syntax Testing [EB/ OL]. [ WP2000-robustness/] [4] Xiao Zheng, Feng Qin, (2006). Auto Generation of Test Case Based On Petri Net.Journal Of Central China Science University (4). [5] IETF. RFC Hypertext Transfer Protocol -- HTTP/ Biographies Li Weihai received his master degree of computer science from Beijing University of Posts & Telecommunication in He is now a Lecturer in School of Electronic Engineering in BUPT. His current research interests are protocol testing of computer networks. Prof. Ma Yan, Vice President of Network Information Center, doctoral supervisor in Computer Science and Technology Department and. His research includes network management technology in TCP/IP network, network security, mobile IP, IPv6, etc. Dr. Huang Xiaohong received her Ph.D degree from the school of Electrical and Electronic Engineering (EEE), Nanyang Technological University, Singapore in Since 2005, Dr. Huang is currently the Associate Professor in the Research Institute of Network Technology at BUPT. She has published more than 30 academic papers in the area of WDM optical networks, IP networks, Grid computing and other relevant fields. Her current research interests are performance analysis of computer networks, QoS management, service classification, grid computing etc