|Informative Information for the Uninformed|
Next: Implementation: PassiveX Up: Post-Exploitation on Windows using Previous: Foreword   Contents
The emphasis in exploit development tends to lean more towards the techniques used to successfully execute code on a target machine rather than the code, or payload, that will actually be executed once an exploit has taken advantage of a vulnerability. While such an emphasis is an obvious and warranted pre-requisite, it is also just as important to identify and refine the techniques that can be used once it is possible to execute arbitrary code on a target machine. In general, most published exploits include a finite set of payloads that are themselves only capable of performing a small set of actions, such as connecting back to the attacker and providing them with a command interpreter or allowing the attacker to connect to the target machine to gain access to a command interpreter2.1. Payloads such as these are indeed quite useful but are prone to failure under conditions that cannot always be predicted by an attacker.
For instance, an attacker could be exploiting a software vulnerability in an HTTP server that only permits connections to port 80. In this case, if an attacker were to use a payload that binds to a port on the target machine, the attacker would soon find that it would be impossible to connect to the bound port, regardless of whether or not the exploit actually succeeded2.2. The same case applies to payloads that establish a connection to the attacker on an arbitrary port. If the service being attacked is on a machine that has restrictive outbound filters or has a personal firewall installed that restricts specific types of internet access for certain applications, the attacker may find it impossible to use either of the two common payloads.
With that said, the majority of computers connected to the internet do not have highly restrictive outbound filters. The reason this is the case is because many home users simply plug their computer directly into the internet via their cable modem, DSL router, or phone line instead of a network firewall device. Furthermore, the level of understanding required to competently manage outbound filters is generally not something that is a strong desire or possibility for the average computer user. For the sake of discussion, however, these users will be disregarded due to the fact that currently employed payloads are sufficient to establish a communication channel between the attacker and a target machine. Instead, the focus will be put upon those machines that make use of outbound filters that are capable of preventing the two aforementioned payloads from being used.
There are three types of outbound filters that can be differentiated by the OSI layer at which they filter and by the physical location at which they reside. The first type of outbound filter is the network-based filter which operates at the network and transport layer by filtering connections based on information that is required to communicate with a host, such as the destination IP address or port of a packet. The second type of outbound filter is the application-based filter which operates at the application layer by filtering network traffic to certain destinations based on the application that is performing the network action2.3. The third type of outbound filter operates transparently at various layers of the OSI model as a type of protocol form validation, such as a transparent HTTP proxy. These three filters can be combined to create a robust and dynamic method of filtering outbound connections that, while not perfect, does indeed lend itself well to helping ensure the integrity of a network.
The reason these three outbound filters are not perfect is because of the fact that they still allow outbound communication. Though this may seem like a paradox, it is actually a real problem. Take for instance a scenario where a corporation's workstation is being exploited through a client-side chat client vulnerability. In this scenario, the corporation has configured their network firewalls to allow communication to internet addresses on port 80 only. All other outbound ports are filtered and cannot be communicated with. Given these restrictions, an attacker might simply instruct his or her payload to connect back to the attacker on port 80, thus bypassing the other outbound restrictions altogether. While this would indeed work, there are steps that the corporation could take to help prevent this approach. For instance, if the same corporation were to force all HTTP traffic through a transparent or true HTTP proxy, the attacker would be unable to simply pipe a command interpreter through a connection on port 80 since the data would not be well-formed HTTP traffic.
This is where things begin to get interesting and the inherent flaw of generic outbound filters begins to come to light. Under the aforementioned condition, a corporation has their network configured to permit outbound communication on port 80 only and furthermore requires all port 80 communication to pass through a transparent HTTP proxy. As such, it is a requirement that all traffic passing through port 80 to internet hosts be well-formed HTTP requests and responses, else the transparent proxy will not permit it to pass. The obvious thing for an attacker to do, then, is to tunnel or encode their communication in valid HTTP requests and responses, thus bypassing all of the restrictions that the corporation has put in place. Hope is not yet lost for the corporation, however, for they could deploy a personal firewall, such as ZoneAlarm, that is capable of doing per-application outbound filters. This would allow the corporation to make it so only a browser, such as Internet Explorer or Mozilla, is capable of connecting to internet hosts on port 80. All other applications, such as the chat client that is being exploited in this scenario, would be unable to connect to internet hosts on port 80 in the first place.
It may seem like this would be enough to stop an attacker from being able to build a communication channel between themselves and the target machine, but the fact is that it is not, and thus the inherent flaw in generic outbound filters is realized: If a user is capable of communicating with hosts on the internet, so too is an attacker capable of doing so from the user's computer. In this case, an attacker could simply inject code into a trusted browser process that then constructs an HTTP tunnel between the target machine and the attacker, thus bypassing both the application layer,network layer, and transparent outbound filters that the corporation has put into place.
The example of the HTTP tunnel is just one of many protocols that can be used or abused to tunnel arbitrary data through restrictive outbound filters. Other protocols that can, and have, been used in the past for arbitrary data tunneling are DNS, POP3, and SMTP. These protocols are also likely, though some of them less than others, to be ones that a corporation or a user are likely to permit both at the network layer and at the application layer. For the purpose of this paper, only the implementation of the HTTP tunnel will be discussed for it is the most likely of all others to be capable of passing transparently through outbound filters2.4. The following chapters will discuss the implementation of a payload that is capable of bypassing the scenario discussed in this introduction on the Windows platform. From there, a number of potential uses, both legitimate and otherwise, will be discussed to give a sense of severity for the problem at hand. Finally, some suggestions will be made on how payloads of this sort might be prevented from being leveraged by an attacker in the future.