CHAPTER 4 HTTP INTRUSION DETECTION SYSTEM USING PROTOCOL ANALYSIS

Transcription

1 73 CHAPTER 4 HTTP INTRUSION DETECTION SYSTEM USING PROTOCOL ANALYSIS Application level Intrusion Detection System detects intrusions that are found at the application layer of the network. Most of the commercially available IDSs work at the network level, paving way for attackers to intrude at other layers. Traffic flowing through the internet is mostly transferred over the HTTP protocol (Lee et al 1996). Most security infrastructure allows HTTP traffic and considers the port used for its transactions (port 80) to be carrying genuine traffic thus making it difficult to curb attacks that comes via HTTP. This is the reason why firewalls and other application layer security devices fail to a large extent. This gives the motivation for a HTTP based Application level Intrusion Detection System. Commercially available IDSs are signaturebased where the attacks are identified by matching each input text or pattern against predefined signatures that model some malicious activity. The pattern matching process is time consuming since each input pattern is compared with the signature in the IDS sequentially. This is not an efficient method for detecting intrusions. Moreover, intrusion detection may not be possible if the intruder knows how to evade from the pattern matching check. This requires analyzing the application level data and for a proof of concept, messages in HTTP protocol are considered for identifying attack traffic. Therefore IDS architecture with protocol analysis is implemented, with HTTP protocol taken as the protocol of interest. The HTTP headers and payload are analyzed and a stateful analysis is done using the Rules BNF specially developed for the IDS.

2 FUNCTIONAL BLOCKS OF THE HTTP IDS Modern network intrusion detection systems inspect the contents of packets to identify attacks (Roesch 1999). Application level IDS works with the data in the application layer and identifies anomalies in the network traffic. Application level IDSs can be classified based on the method used for detecting the intrusions as semantic and non-semantic IDS. A non-semantic IDS is one which hunts for the patterns in the input traffic and if a pattern matches then an intrusion alert is raised. An intelligent hacker may intrude the system by simply avoiding common patterns used by the non-semantics based IDS. In such cases a non-semantics based IDS fails miserably. A semantics based IDS will define a rule such that an approximate occurrence of a pattern in the network traffic definitely indicates a malicious activity. Moreover, the time taken for detecting an attempt is lesser than the time taken in a nonsemantic based IDS because the search space is reduced. Network traffic HTTP Data capture HTML parser Header parser Payload parser javascript parser IDS Interpreter Console to add rules and notify alerts Figure 4.1 Block diagram of HTTP IDS The block diagram view above (Figure 4.1) shows the sequence in which the incoming data is processed. The HTTP data capture block captures the data from the network which is then separated into header and payload parts and forwarded to separate buffers. The Header parser module reads the header and prepares a list of the objects in the HTTP packets. Each object is a five tuple <message-line, section, feature, operator, content> representing a

3 75 field of the HTTP protocol (Mogul et al 1999). This is passed to the IDS interpreter which consults the rule-base and correlates the different objects to trigger the corresponding rules. During the same time, the payload parsers strip off the HTML part and javascript part to search for misappropriate tag or attribute usage and various scripting attacks respectively. The outcome of this module is given as input to the IDS interpreter which flags the alerts to the administrator through the console. The connection on which an intrusion is found that lead to triggering the alert, can be blocked by closing the corresponding TCP connection. The IDS Interpreter receives data from the HTTP parser block in the form of tokens. Each token is a 3 tuple <message-line, section, content>. The IDS Interpreter has several objects that mark the occurrence of patterns as regular expressions and are identified by object numbers. When a token that is passed by the parser matches one of the object s regular expressions the respective number is assigned to the token and the state of the IDS Interpreter is updated. A rule is fired when all the object numbers that are contained in it are matched. An object number in a rule identifies a specific characteristic or feature in the traffic of that session. Since the IDS Interpreter is stateful, features of the data occurring over multiple requests and also multiple page loads can be recognized. Object numbers are assigned based on the statefulness and the regular expression match of patterns that occurs in the traffic. i.e., object numbers change with the position of occurrence of a particular entity in the traffic. Thus semantics are maintained in identifying the objects that are used to trigger a rule. The rules thus formed specify occurrences of objects in both the requests and the corresponding responses. The Data capture block forwards the request and the response headers along with the corresponding payload for analysis. Thus it is possible to write rules which checks for attack features in the request response sequence thereby identifying newer types of attacks. Thus complete semantics of the HTTP data

4 76 transfer (request-response) is maintained which provides a better way to identify attacks than an IDS which checks each incoming packet individually for attack patterns. Apart from the above fact, as the IDS processes the actual responses generated for a request it is possible to identify an attack even if it uses evasion techniques. Figure 4.2 HTTP state diagram Protocol analysis is the process of reconstructing the protocol context of communication sessions from an ongoing network stream or trace. Intrusion detection systems (IDS) employ protocol analysis in order to understand the traffic and supervise the execution of some selected protocols (Abbes et al 2004), thereby employing more specific attack signatures. This involves translating a sequence of packets into protocol messages, grouping them into sessions and modeling each state transition in the protocol s state machine similar to the one shown in figure 4.2. The protocol context extracted by a protocol analyzer refers to a particular traversal of the state-machine for a communication session, similar to the one discussed by Ramanujam and Suresh (2001). Protocol analysis is crucial to IDSs because precise

5 77 reconstruction of the protocol context significantly reduces the number of false alarms. Another advantage of protocol analysis is to label network traffic with more semantics of the protocol facilitating network monitoring and distributed system debugging. Some immediate consequences of such an analysis are reduction of attacks search space, immunity to evasion attempts and decrease in the rate of false positives. Protocol analysis involves many phases like session dispatching, state machine operations, message parsing, protocol layering and handling out-of-order or fragmented messages. The approach is to extract data from each individual fields of the protocol in the received packet, and then traverse down a decision tree for the corresponding protocol to determine which protocol field data to check for the current pattern. A decision tree is constructed by analyzing the specification of the protocol, as given below in this case HTTP. The specification gives the rules and individual patterns which will be matched in the corresponding fields of the protocol (Anitha et al 2006). Variable represents each individual pattern that is henceforth called as object in this chapter. Thus every rule consists of several objects that hold the various patterns to be matched. Given a rule, the objects are classified according to the protocol fields in which they appear as shown below. This reduces the search space to a subset of patterns upon scanning the contents of the protocol field. Rules *(variable) Variable message-line section feature operator value This chapter explores the consequences of using the message-line and section as features for classifying intrusions using the decision tree. A variable specifies the field of the protocol and the value it has to take to form a feature for the attack. This provides additional benefits of specifying attack signatures in terms of the actual protocol operations. These signatures can be

6 78 used to specify the security policies for the protocol. The choice of features used to split a subset has an important impact on the shape and the depth of the resulting decision tree (Krugel et al 2003). As each node on the path from the root to a leaf node accounts for a check that is required for every input element, it is important to minimize the depth of the decision tree. An optimal tree will consist of only two levels - the root node and the leaves, each with only a single rule. This would allow the detection process to identify a matching rule by examining only a single feature. Hence, feature selection is very important for building efficient decision trees. Figure 4.3 Formation of a part of the HTTP Decision tree The decision tree structure will be evaluated be as follows. When the input reaches a node in the decision tree, the IDS interpreter computes and sends across a decision to specify the subset of objects through which the decision tree has to be traversed. The input of the parser is thus matched with a specific node in the tree. The subsections to follow explain more details about every block of the IDS given in figure 4.1 and the role played by each module in analyzing the protocol context to traverse the decision tree.

7 HTTP Data Capture The data capture block is a proxy, through which all the requests and the responses are directed. This block makes a local copy of each client s request before forwarding them. This request is solicited with a series of response messages from the host server. This request response sequence repeats several times when the web page loads. These individual sequences are called as threads, comprising of atomic HTTP transactions on which protocol analysis is made. Justifications behind analysis of payload for exactly one thread at a time are given in the forthcoming sections of the chapter. The figure 4.4 shows the logical view of HTTP Data capture. for header analysis for payload analysis Header buffer Payload buffer Client Request Response Proxy component Request Response Server Figure 4.4 Logical view of HTTP Data capture As depicted in figure 4.4, the Data capture block consists of three main components namely Proxy, Header buffer and the Payload buffer. The dotted boxes represent components to which the Data capture block interacts with. Proxy component is the basic functional block in the Data capture block. As mentioned before all HTTP transactions take place through this component. It not only provides a proxy support but also helps as a data logger. The requests from the clients are logged into the Headers buffer. The payload obtained for a thread of HTTP transaction is buffered and is separated

8 80 into HTTP response headers and the payload. The HTTP response headers are appended to the Headers buffer, and the payload is dumped to the Payload buffer. The proxy is programmed to operate in two modes vis-à-vis 1. Data Logger mode where the proxy dumps the data and continues with the next thread of that client connection and 2. Inline mode in which the proxy waits for a continue signal from the analysis block to process the next thread of if an alert is received, the connection with the client is closed. Headers buffer contains the HTTP request headers and the response headers of a single thread. Once a thread has been buffered in the ongoing session it is sent for Header analysis to the IDS Interpreter. Payload Buffer contains the payload which can either be a HTML page or an Image or a script that is to be executed when the page loads. On completion of a thread the payload is sent to the payload analysis block. To summarize, clients connect to the proxy and submit their requests. These requests and their corresponding responses are buffered for each thread. When analysis of a thread is completed, a message is sent to the next analysis block, viz. HTTP Parser, for the Headers data analysis and the Payload Analysis block for the Payload analysis, using UNIX message queues. If the proxy is operating inline then the Data capture block waits for the return messages from the analysis blocks. Upon receiving the return messages as continue, the proxy services the next thread for that client connection, and clears the buffers for the next thread, otherwise the connection is closed. If the mode of operation is set to logger, then after sending the messages to the next analysis blocks, the buffers are cleared and the next thread is serviced HTTP Parser and IDS Interpreter Information about the protocol (HTTP) and its attacks are to be fed to detection system in the form of protocol fields by identifying the

9 81 components that form the protocol grammar. Given a HTTP session, there can be a persistent TCP connection such that a number of requests are transmitted in the same connection, or newer connections can be opened. The protocol parser parses the HTTP messages, and for each field makes a structure of the form, Structure: message-line_section <contents of the protocol field>. These structures are stored in a buffer sequentially as they appear in the application data packets. For each message the parser forms the parsed output, and forwards it to the IDS interpreter. Another way by which the data from the parser can be operated upon is by passing the content of every protocol field as it is to the IDS interpreter, which also receives the state information as to which protocol field the parser is in. This makes the IDS interpreter chose the subset of objects that match the current data. The interpreter receives the input from the parser, in the form of the above structures which describes the protocol field values. The decision tree is traversed down using the message-line first and then the section provided in the structure and determines the subset of objects that are to be compared. It is evident that a rule consists of more than one variable. Each variable is considered as an object and a rule is represented as a union of several features represented by these objects. The IDS interpreter reads the input from the protocol buffer and for each structure, it decides the subset of objects which are to be matched by traversing down the decision tree. Whenever any object matches the contents in the field, a state is maintained for the object and the rules associated with it. With a in-flow the traffic more than one object matches and when all the objects of a particular rule are observed in a flow then the rule is triggered. Situations arise where objects may be a part of more than one rule and those that arrive out-of-order. IDS interpreter solves these issues by maintaining states of every rule s arrived and remaining objects.

10 Payload Analyzer Payload analysis, also called as deep packet analysis is not a feature of most commercially available IDSs. It is well known that pattern matching does not expose most of the real-time attacks and becomes inefficient with more number of patterns. Protocol analysis comes in handy by identifying the specific part of the packet in which pattern matching is to be done. Thus, online processing of live traffic is possible leading to immense reduction in the amount of storage space used and time taken for analysis. Payload analyzer plays a major role in identifying the portion of the payload to which a subset of objects matches the current transaction. Section discussed about the Data capture block in which the payload in each thread is stored in a buffer for Payload analysis. The payload in individual threads can either be HTML documents or scripts or images in the web pages that are possibly compressed (using gzip). If the payload is compressed, a decompression mechanism (gunzip) is used and later parses the payload to strip off the scripts from the HTML content. An HTML parser and a script analyzer are then employed for identifying specific attacks. This method of decompressing before payload analysis overcomes the disadvantages of most pattern matching techniques which skip encrypted and compressed content without scanning. Upon triggering a rule, the IDS interpreter reports back to the console with information related to attacks and the objects that caused the alerts. 4.2 MESSAGE PASSING AND SYNCHRONIZATION This section discusses about the messages that are exchanged across various blocks for a synchronized operation. The Data capture block acts as a proxy through which the clients connect so that the HTTP data is available readily for analysis. It also provides buffering capability for the data to be

11 83 analyzed and interpreted. As the HTTP data arrives at Data capture block, the request header and the response header are combined as one thread and stored in the buffer for analysis. The Data capture block receives parts of an HTTP transaction as threads and forwards it to the HTTP parser with a message to initiate parsing. Then it waits for a message from the IDS Interpreter about completion of the parsing, analysis and interpretation of the thread. The parser tokenizes the data available in the thread and forwards them to the Interpreter along with a message where stateful analysis of the data and identification of objects are carried out. Upon identifying the objects, messages are sent to HTTP parser and to the Data capture block indicating that it is ready to process the next thread and an indication if the client connection can continue respectively. If there were no attacks reported by the IDS Interpreter, the proxy i.e., Data capture block continues to serve the client. As mentioned in section 4.1.1, there are two modes of operations viz. Data Logger mode and Inline mode. The sequence of operations and message passing varies for each of these modes as explained below Data Logger mode In this mode the various messages passed are SENDP, SENDPA, SENDIDS and SENDD. The steps involved in detecting intrusion using the message passing mechanism are as below. a) Once the data is received in the thread, the Data capture block sends two messages, 1. SENDP to the HTTP parser and 2. SENDPA to the Payload analyzer. These messages carry the location in the buffer where data for the current thread is stored. b) Upon arrival of the SENDP message, the HTTP parser parses the request and response headers in the buffer whose location was obtained and stores

12 84 the tokens into another temporary buffer whose address will be passed on to the IDS interpreter. The old buffer that was sent by the Data capture block is now released by the parser. c) The SENDPA message also functions in a very similar manner the same way. It triggers the Payload analysis block to analyze the payload that is stored in the buffer, parses the contents and releases the buffer. d) The HTTP Parser block, after tokenizing passes SENDD, to the IDS Interpreter. The IDS Interpreter then identifies the objects in the tokens obtained through the buffer. It maintains details regarding the occurrences of certain features in terms of object numbers incrementally, over multiple threads and also over multiple web page loads or sessions. e) After analyzing the current thread, the IDS Interpreter sends a SENDIDS message back to the HTTP parser which then receives the next message from the SENDP queue and parses the data. f) Both IDS Interpreter and the Payload Analysis block, on identifying a rule match, fires an alert of intrusion Inline mode Inline mode uses SENDP, SENDPA, SENDINT, SENDIDS and SENDD messages along with the SIGINT signal for synchronization across all the modules. The sequence of message passing is as discussed below. a) Once the data in the thread is being received, the Data capture block sends SENDP to the HTTP parser and SENDPA to the payload analysis modules. These SENDP and SENDPA carry the address of the buffer in which the current thread is stored. The Data capture block then waits for the SENDINT message from the IDS Interpreter. b) The HTTP parser parses the request and response headers in the buffer when the SENDP message is received. Once parsing is done, the tokens

13 85 are stored in a new buffer space and set the old buffer free to be used by the Data capture block. c) SENDPA message also functions the same way. The Payload analysis block receives the data, parses its content and releases the buffer. If the Payload Analysis block identifies an alert then it immediately sends a SIGINT signal to the IDS Interpreter. d) The Interpreter, upon catching the interrupt executes the corresponding actions and analyses the current Headers buffer, and then sends a SENDINT message to the Data capture block along with the result of analysis of the current thread. If no alerts were raised during analysis of the header and if the Payload analysis modules doesn t send a SIGINT, then the Interpreter sends a CONTINUE message or else it sends an INTRUSION message back to the Data capture block, which then closes the connection of the corresponding client. e) After analyzing the current thread, IDS Interpreter sends a SENDIDS message back to the HTTP parser to receive the next message from the SENDP queue and the process is repeated. 4.3 IMPLEMENTATION OF THE RULE BASE For each incoming thread, the HTTP parser sends the tokens to the IDS Interpreter where it generates objects of the form <message-line, section, feature> and updated in a table. Objects that arrive out of order are automatically rearranged before interpretation. The following subsections detail about the various data structures and methods used to hold the rules and detecting intrusions by matching the objects in these rules Structure of the Rule base and Object matching The IDS Interpreter holds the set of rules in a Rule table where each rule consists of the 1. Rule_number indicating a distinct number for every

14 86 rule, 2. No_of_objects, a variable indicating the number of objects contained in the rule, 3. Object_list, an array containing the list of objects to be matched for the rule to trigger and 4. In_order, a variable holding status if the objects are expected to arrive in order. When the analyzers sends every thread of HTTP data in the form of objects to the IDS Interpreter, a lookup table is dynamically generated for detecting intrusions. The table consists of three attributes namely, Rule_number, Count and Unmatched_Object_list. The Rule_number holds the rule number from the rule base that is currently getting matched. Count consists of the number of objects that are to be matched in each row for the rule to hold good when the Unmatched_Object_list specifies a list of all the specific object numbers to be matched. This table is initialized with every rule in the rule base holding a row. As the objects arrive, this table is dynamically updated by removing the object numbers that are matched by the current thread whose instances may be found in more than one rule. When the Count of a row becomes reaches 0, it indicates that the rule is matched thereby triggering an alert. For In_order rules, the Count is used for holding the number of objects that are to be matched in the exact order, i.e., the incoming object is expected to match the n th object if the count is n Authoring rules The BNF grammar of the rule language is as shown below : Rules *(variable) Variable message-line section feature operator value Message-line start-line header body Start-line Request-line Status-line Header Generic-hdr Request-hdr Response-hdr Entity-hdr Body HTML XML Section Method Uri Version Statuscode <all the generic header fields> <all the request header fields> <all the response header fields> <all the entity header fields>

15 87 <all the tags in the HTML doc or other HTTP payload> Feature parameter size regex occurrence Operator = > < Value 1*(Alpha Digit) Alpha [a-za-z] Digit [1-9] Figure 4.5 BNF Grammar of the HTTP IDS Rule language It is evident from the grammar that a rule consists of more than one variable where each one of them represents an object denoted by <messageline section feature operator value>. A pseudo-rule is as shown below which goes inline with the BNF grammar : MESSAGE-LINE <message-line of object 1> SECTION <section of object 1> FEATURE <feature of object 1> <actual content to be checked for> < feature of object 2>.... <section of object 2>.... <message-line of object 2>.... Figure 4.6 Snapshot of a HTTP IDS Pseudo rule

16 88 A sample rule following the pseudo rule given in figure 4.6 is as given below. Two objects with the same message-line parameters as Requestline are considered. These objects differ in the Section with one of them having method and the other uri as parameters. MESSAGELINE Request SECTION method FEATURE GET uri FEATURE /bin/ps COMMENT Probably a command attempt attack Figure 4.7 A sample HTTP IDS Pseudo rule 4.4 EXPERIMENTS AND RESULTS Common internet traffic consisting of HTTP data exposes various information like the client / browser s specification, the server s specification, the file requested, the script contained it, etc. HTTP exploitation is more of an enabling class of exploit with such information than a specific bug.

17 HTTP exploits Material (code and/or data) injection is the heart of HTTP header exploitation (Bellamy 2002). There are many attack vectors available to achieve a goal of sending material into a system. The primary motivation of most attackers is to make the web servers (typically the daemon like httpd) accept and process the malicious material which is most likely to succeed (cgisecurity 2002). The various ways of exploiting the HTTP data by an attacker are as discussed below : 1. HTTP Header fields: Any header field value which is logged can be used to store injected material. In the example below, Hobbit's netcat (nc) program used to build and send a raw HTTP request. the header is "Referer:" and its value is <!-- #exec cmd="copy global.asa global.txt" -->, which is the the injected malware. C:\>nc GET /default.asp HTTP/1.0 Referer: <!-- #exec cmd="copy global.asa global.txt" --> 2. Query string portion of the URL: Values passed to a Common Gateway Interface (CGI) application are usually hard coded in a hyperlink's URL, or being supplied by an HTML form using the GET method. The intent of the example given below is to make the command interpreter read the log file entry later and be tricked into executing the OS command del c:\*.* del c:\*.* 3. HTML Form attacks: HTML web form attacks involve values oriented with the same HTML form hosted by a web server, but are submitted using a forced HTTP POST method rather than the GET method. The aim of the example below is to inject a Unicode string %255c..%255c and trick the search service to function outside the allowed filing system.

18 90 <form name="f1" action=" method=post> input type="text" name="authorrestriction" value=""> <input type="hidden" name="colchoice" value="1"> <input type="hidden" name="scope" value="%255c..%255c"> </form> 4. SQL Injection: Structured Query Language (SQL), the native programming language of most database systems can use HTTP as a transport facility for executing queries over Internet. SQL injection is aimed at injecting malicious SQL queries targeted at the database associated with the web server. In the example below, a SELECT statement that could be a part of the HTTP data can be used to invoke the cmdshell and execute the net command. SELECT * FROM mytable WHERE sometext ='' exec master cmdshell net user testpass test add The above mentioned methods use HTTP as a vehicle to carry malicious material (data or code) to the web server and trick it to execute them. The most common methods used to launch these kinds of exploits is either by using tools like netcat to craft the requests manually or to script the attack using a language. When the crafted HTTP request arrives at the web server, it is validated for syntax, parsed to understand the various components and executes it irrespective of the type of content. The HTTP IDS comes in handy at this place to identify the type of data that the web server is expected to handle and alerts the administrator if any malicious content is found Performance Analysis The time taken for complete analysis of a single atomic HTTP transaction was measured by calculating the time taken for the IDS interpreter to understand the semantics of the HTTP request and response. Various factors involved in variation of time are size of headers, match of various objects in the interpreter, time taken for message exchange between various modules, number of rules and number of objects in each rule, etc. Due to

19 91 minute variations of the processing time due to the above factors, the mean of a set of values are considered for comparisons. Figure 4.8 Response time with increasing number of objects Figure 4.8 depicts a plot of the average response time including the message passing time based on the number of objects that are processed by the IDS Interpreter. It is found that the response time saturates at 80 objects and hence in the ideal case, the IDS is expected to perform better for when more than 80 objects are encountered. The reason behind saturation in response time is that repeated occurrence of objects in the incoming payload are marked only during the first time by the IDS Interpreter and are ignored during the subsequent occurrences.

20 92 Figure 4.9 Response time with varying number of maximum objects Figure 4.10 Detection ratio with various components of the IDS

21 93 Figure 4.9 is plotted by fixing the maximum number of objects that can be a part of a protocol field thereby restricting the attack s search space. Figure 4.10 gives a clear picture of employing the various components of IDS. Given a set pattern of incoming HTTP data and the number of attacks in it, when the IDS was tuned to work in three modes 1. to detect only HTTP header attacks using only the Header analyzer. 2. to detect the header attacks along with the payload attacks with only HTML parser in place and 3. all types of attacks where HTTP header analysis, HTML analysis and script analysis works together with the maximum number of attacks were found with the given number of rules in the rulebase. 4.5 DISCUSSION The HTTP based intrusion detector discussed in this chapter was designed using Protocol analysis shows an efficient way of analyzing the HTTP traffic coming into a server or on a network. The setup can correlate data over multiple page requests by clients and identify attacks not only on the basis of the requests submitted but also the corresponding responses by the server. Very few IDS architectures provide for combined analysis of both the requests and corresponding responses. Also the semantics play an important role in the object identification and in the tokens passed by the HTTP parser to the IDS Interpreter.