 capacity of covert channels and limiting it by introducing noise [Gligor93, Gray94, Wray91, McHugh95, Giles03] or by using related mechanisms such as network pumps [Kang95]. However, the reality is that mandatory access control systems are rarely deployed. Even in government systems, which were the target of original research on mandatory access control, Windows clients and servers are prevalent and they do not use mandatory access control. In the commercial world, almost all systems use discretionary access control and yet there is strong interest in protecting confidential information, such as intellectual property, financial data, and customer records.
Often, corporate servers are well-protected from direct attacks on their databases. Instead, a more common mode of attack is to compromise a client machine. Often, the data in corporate databases must be accessible to employees from their desktop machines. Therefore, the potential of leakage of data from an employee's machines is high. These machines often provide client applications, such as web browsers, email clients, and instant-messaging tools, because employees may need them to work effectively. Thus, for many businesses, a big worry is finding ways to prevent or detect information leakage from these non-server machines that are used by their employees.
At present, organizations have a difficult time stopping information leaks from client computers. One line of defense is to disseminate policies and maintain audit logs for access to critical data. The University of Michigan hospital, for example, posts a warning on all desktop machines in patient rooms stating they are intended for doctor use only and they maintain an audit trail for all access to medical records. These verbal out-of-band policies and the legal ramifications associated with their violation are not likely to be enough to deter remote attackers and all malicious insiders, especially if there is a possibility of financial gain [Randazzo04].
We are primarily concerned about two information leakage channels. The first is direct transmission of data by hiding or tunneling it within an existing protocol. Here we are concerned about HTTP in particular because it is available even in the most locked-down network environments. The second type of channel that we investigate herein is a covert network channel. Normally, direct transmission is easier and more convenient, but an attacker who is especially worried about avoiding detection may use a covert channel, such as adjusting the timing of individual packets.
Little work has been done on measuring the amount of data that one can send directly within various protocols, though there is a great deal of awareness about hiding data in covert channels for these protocols. Some examples of prior work on constructing convert channels include embedding data in IP fields [Abad01, Cabuk04], TCP fields [Rowland97, Ahsan00, Servetto01, Ahsan02], HTTP protocol headers [Castro06, Dyatlov03], and DNS fields [Heinz04]. In contrast to this earlier work on hiding data in covert channels, we are interested in measuring the maximum amount of data that such channels could contain. Our results aim to provide a theoretical upper-bound, and thus will work irrespective of the data-hiding scheme.
Products exist that give raw bandwidth measurements [RSAMonitor08], [FirewallAnalyzer08]. They can be used for tracking network usage on a personal machine or for an enterprise network. It would be relatively straightforward to augment these with IDS rules, using a system such as Snort [Roesch99] or OSSEC [Cid08], so as to raise alerts if aggregate bandwidth within a given time-period exceeds some threshold. Indeed, our communications with an IT security administrator at a major bank indicates that they do use such rules to help detect naïve insider attacks, presumably because the raw amount of data sent with legitimate network usage is so large that most insider leaks would not affect the raw outbound bandwidth measurement. The algorithms presented herein for fine-grained information leak measurement provide a much smaller and more accurate bandwidth measurement and are better at isolating information leaks in outbound network traffic.
More recently, there has been a growing interest in Data Loss Prevention (DLP) systems [Proctor07]. The current state-of-the-art solutions focus on content matching; none attempt to control bandwidth. Several products in the marketplace, such as Tablus [RSA07] and Vontu [Vontu08], allow their users to tag certain files as sensitive or define regular expressions for sensitive content, such as credit card numbers. They then create content filters that examine flows within specific protocols, such as SMTP and FTP, for any matching content. If the flow contains matching bytes, the system will raise an alert or block the flow. Companies are increasingly deploying these systems as part of a layered defense strategy. However, DLP solutions have a major limitation: spyware or insiders can bypass them by simply encoding or encrypting content so that it does not match the filters. As a result, DLP products are primarily useful for accidental leaks. Another limitation of DLP systems is that one must correctly tag all sensitive content ahead of time. If non-sensitive information is tagged by accident, or if sensitive data is not tagged, then false positives or false negatives may result. Our work presented here is complimentary to DLP systems because it can process network messages and identify fields that contain information from the client. This would help reduce DLP software false positives by filtering out data that cannot contain sensitive information, and increase overall security by putting an upper limit on the amount of encoded or encrypted content that an attacker could leak to the Internet.
Our work draws upon work on reverse engineering protocols [Caballero07], as well as static and dynamic code analysis techniques for analyzing security properties [Foster02, Christodorescu05, Newsome05, Brumley06]. In [Nguyen-Tuong05], code analysis was suggested for automatically finding vulnerabilities (such as SQL injection or cross-site scripting) in web applications. However, as far as we are aware, prior work has not explored the problem of identifying constrained fields in network messages by analyzing HTML web pages and Javascript code.
I—The set of previous network inputs to the application.
O—The set of network outputs from the application.
A—The application representation, which is a mapping: U×I→O of UI-layer input combined with network input to yield network output.
Furthermore, one should be able to reconstruct the exact network output O given A, U, and I. By definition, the set I cannot contain new information from the client because it is generated by the server. The application representation A is fixed and also cannot contain information from the client. Therefore, the information content from the client in set O can be reduced to the information in the set U. Iinput supplied to an application from all sources other than the network is considered part of U. This includes file uploads/attachments, system information such as the operating system version, and values from the random number generator.
Timing information that results from user action is part of the set U. Here, we measure the bandwidth of timing channels for HTTP traffic. Previous research has been done on constructing and measuring timing channels in general network traffic. In [Cabuk04], the authors describe an IP packet timing channel in which time is divided up into equal-length slots that either contain 0 or 1 IP packet. With the HTTP protocol, timing channels can be more complex. Individual messages are often different from one another and multiple messages could occur at the same time, leading to a vector where each entry may contain multiple non-binary values. We build upon prior covert timing channel research herein to quantify the maximum amount of information associated with the timing of each network request.
There are two main types of HTTP requests, GET and POST. GET is typically used to obtain resources and POST is used to send data to the server. An example of a HTTP POST request can be seen in FIG. 6. This request is comprised of three distinct sections: the request line, headers, and the request body. GET requests are very similar except that they do not have a body. The request line contains the path of the requested file on the server, and, for GET requests, it may also have script parameters. The path in the request line is one place where data can easily be hidden. The next part of the HTTP request is the header field portion, which consists of “<field>: <value>” pairs separated by new lines. Header fields hold information such as the browser version, preferred language, and cookies. Finally, the HTTP request body follows the headers and may consist of arbitrary data. In the example message, the body contains an encoded name and e-mail address that was entered into a form.
The first method we present for measuring information flow in HTTP traffic calculates coarse-grained bandwidth by discounting header fields that are not meant to convey information from the user to the web server. This approach has the advantage of being very fast and not requiring any state to be kept during a browsing session. However, a large portion of measured data may still be repeated or constrained, leading to a larger result. For example, if a user visits a link with a path that is 100 bytes long but the link came from another website, then the web browser is not really sending 100 bytes of information from the client. However, a coarse-grained approach would still count the full 100 bytes. Another limitation of coarse-grained measurement is its vulnerability to data hiding in header fields. For example, because it does not keep session state, a coarse-grained algorithm has no way of knowing whether an HTTP cookie is actually echoing back data from the server. The cookie could instead contain hidden information from a malicious client that violates the HTTP protocol. These limitations affect the coarse-grained algorithm's accuracy. Nevertheless, it is still an effective means for identifying information leaks in many cases and serves as a reasonable approximation for the finer-grained methods presented herein.
The coarse-grained measurement algorithm