Implementation: PassiveX

Implementing a payload that is capable of bypassing restrictive outbound filters, such as those outlined in the introduction, requires that the traffic produced by the payload be, for all intents and purposes, indistinguishable from normal user traffic. The protocol that should be used to encapsulate the attacker's arbitrary data, such as the input and output from the command interpreter, should also be one that is likely to be permitted by the various types of outbound filters, whether they be network or application based. One of the protocols capable of fulfilling both of these requirements is HTTP. By making use of HTTP requests and responses, it is possible for an attacker to create a bidirectional tunnel between the target machine and the attacker's machine that can be used to pass arbitrary data.

The way in which the tunnel can be constructed using HTTP is to create two logical channels, similar to that of a bidirectional pipe. The first channel, Tx, would be used to transmit data from the target machine to the attacker's machine by making use of an HTTP POST request. The content of the POST would be the data that should be handed to the attacker. The second channel, Rx, would be used to transmit data from the attacker's machine to the target machine. The problem is, however, that the data cannot be directly transmitted from the attacker's machine to the target machine while still staying within the parameters of well-formed HTTP traffic^3.1. One way of getting around this fact would be to use a polling model whereby the target machine sends polling HTTP GET or POST requests to the attacker's machine to see if there is any data available that should be handed to the target machine's half of the tunnel. Once there is data available it can be included in the content of the HTTP response to the target machine's HTTP request. This approach is one that is commonly used and employed as a tunneling mechanism[3].

The first step in the building of an HTTP tunnel between the target machine and the attacker's machine is to implement the payload that will be executed after a given exploit succeeds. There are a number of ways in which such a payload could be written with the most obvious being a payload that directly builds and maintains the bidirectional HTTP tunnel between the attacker and the target machine. While this approach may sound good in principal, it is not entirely practical. The reason for this is that the payload must be written in assembly or in a language that is capable of producing position independent code. This fact alone would make the implementation of a payload that accomplishes HTTP tunneling tedious but is in itself not necessarily enough to make it impractical. What does make it impractical, however, is the fact that implementing such a payload in a portable and position independent fashion would lead to a very large payload. The size of a payload tends to be rather important as it directly determines whether or not it can be employed under certain conditions, such as where a vulnerability only has a limited amount of room in which to store the payload that will be executed. In scenarios such as these it is preferable to have a payload that is as small as possible and yet still capable of performing the task at hand.

Even if it were possible to implement a small payload that were capable of managing the HTTP tunneling, it alone would not be enough to satisfy the requirements for the payload described in the introduction. The reason it is not enough is because such a payload would not necessarily be capable of bypassing application-based outbound filters due to the fact that the application being exploited, such as a chat client, may not itself be directly capable of communicating with hosts on the internet over port 80. Instead, it becomes necessary to run the code that performs the actual HTTP tunneling in the context of a process that is most likely trusted by the target machine, such as Internet Explorer. With this in mind it seems clear that a technique other than implementing the entire HTTP tunneling code in position independent assembly is necessary, both from a practical and functional standpoint.

An alternate technique that can be used is to implement a payload that is itself not directly responsible for managing or initializing the HTTP tunnel, but rather facilitates the execution of the code that will be responsible for doing so. It's important to note, however, that such a payload must do so in a fashion that does not require network access due to the fact that ignoring such a requirement would defeat the entire purpose of the HTTP tunneling payload that it would be trying to load. With this in mind, it becomes necessary to look towards other approaches that are capable of facilitating the execution of code that will build an HTTP tunnel between the target machine and the attacker's machine and, furthermore, will do so using a medium that is compatible with the various types of outbound filters.

As luck would have it, a solution to this problem can be found in Internet Explorer's ability to download and execute plugins. These plugins, which are more commonly known as ActiveX controls, are a means by which programmers can extend or enhance features in Internet Explorer in a generic fashion^3.2. Though ActiveX controls do have merit, many computer users tend to be familiar with them not for the benefits they bring, but rather for the spyware and other malicious content that they seem to provide or be associated with. Due to this fact, it has become common practice for computer's to be configured with ActiveX support either completely disabled or conditionally permitted based on Internet Explorer's built-in zone restrictions[5].

Zone restrictions are a way in which Internet Explorer allows a user to control the level of trust that is given to various sites. For instance, sites in the Trusted Sites zone are considered to have the highest level of trust and are thus capable of executing ActiveX controls and other privileged content without necessarily requiring input from the user. On the other hand, the Internet zone represents the set of sites that exist on the internet and are not expressly trusted by the user. The Internet zone typically defaults to prohibiting the downloading and execution of unsigned ActiveX controls. If an ActiveX control is signed, the user will be prompted to determine whether or not they wish to allow the signer of the ActiveX control to execute code on the user's machine.

With this knowledge of Internet Explorer's zone restrictions and its built-in ability to download and execute ActiveX controls, it is possible to construct a payload that can facilitate the establishing of an HTTP tunnel between the target machine and the attacker, regardless of whether or not outbound filters exist. One way that this can be accomplished is by implementing a payload that first modifies the zone restrictions for the Internet zone to allow the downloading and execution of all ActiveX controls, thus allowing it to work in environments that have explicitly disabled ActiveX controls. The payload can then execute a hidden instance of Internet Explorer and direct it at a URL on the internet that is controlled by the attacker. The content of the target URL, in this scenario, would contain an embedded ActiveX control that Internet Explorer would download and run without question. As such, the code that would be responsible for building the HTTP tunnel could be implemented in the context of the ActiveX control that is downloaded, thus allowing the attacker to write the tunneling code in his or her language of choice due to the fact that ActiveX controls are language independent, so long as they conform to the necessary COM interfaces.

Before describing the implementation of the payload and the respective ActiveX control, it is first important to understand some of the negative aspects of using such an approach. One of the most obvious cons is that such a payload is capable of, in the worst case scenario, leaving a user's computer completely open to future infection by way of untrusted ActiveX controls if the zone restrictions on the Internet zone are not restored. This can be solved by making the payload itself more robust in the way it handles the restoration of the zone restrictions, but it comes at the cost of size which isn't always something that can be conceded. Another negative aspect of this approach is that it will not function when used against a user that does not have administrative privileges on the target machine. The reason for this is that Internet Explorer is hard-coded to prevent the downloading and execution of ActiveX controls that are not already registered and installed on the target machine. Under scenarios where it is known that a limited user account is being exploited, it may be possible to modify the payload to inject a secondary payload into the context of an Internet Explorer process that then downloads and registers the control manually^3.3. Regardless of the payloads deficiencies, it should nonetheless be consider a viable approach to the problem at hand.

The payload itself has two distinct stages. The first stage is the payload that the exploit will send across that will be responsible for making modifications Internet Explorer's zone restrictions and executing a hidden Internet Explorer to a URL that is controlled by the attacker. The second stage starts once the ActiveX control that was embedded in the attacker controlled URL is loaded into the hidden Internet Explorer. Once loaded, the ActiveX control can simply build an HTTP tunnel between the two machines due to the fact that it's running in the context of a process that should be trusted. This document's implementation of the payload will henceforth be referred to as PassiveX^3.4.

• The ActiveX Injection Payload
• HTTP Tunneling ActiveX Control