Idea for a new payload : Manipulate Internet Explorer with OLE AUTOMATION

[mmiller at hick.org (mmiller at hick.org)]

On Thu, Feb 17, 2005 at 02:51:30PM +0100, Thierry Haven wrote:
> Hi,
>
> To get a cmd.exe shell or to create a networkbridge, you need a 
> permanent bidirectionnal channel between the hacked computer and your 
> management console.
> Thus, you need two sockets : one for the upload, the other one for the 
> download. It's due to the way proxies handled response. (like with 
> QuicktimeVR).

This is correct, however, you also need a stream-based abstraction layer
if you wish to not have to write custom payloads that are specific to
the explicitly dual channel design.  For instance, if you did not create
a stream-based abstraction layer you would have to use pipes for the
standard I/O handles when executing cmd.exe such that when data comes in on
read half of the standard out pipe it results in a POST and when data 
comes in from a GET it is written to the write half of the standard in 
pipe.  This would work fine, but it becomes more complicated when you
start dealing with things like VNC and meterpreter.  While it's possible
to modify them both to be aware of the read/write channels, it is
better, in my opinion, to create an abstraction layer that is truly
streaming.  There are a few ways that this can be accomplished (as I
pointed out in a previous E-mail), but the easiest is likely to be by
using a local TCP listener.  The connection management half of the
payload would bind to a port and wait for a connection from the client
half of the payload.  Once established, the payload would pass the
client file descriptor to be used as the standard I/O handles for
cmd.exe.  The server half of the payload would then watch for data on
the server half of the local connection and read from and write to it
appropriately, thus causing data to be read from and written to
cmd.exe's standard I/O handles.  This would also work with meterpreter
and VNC, in theory, though the use of threading would likely be
necessary.

The major downside to the local TCP listener is that it isn't entirely
stealthly (even though it would only be bound to localhost), but I
imagine that can be overcome with a little more extra thought.

> The client tries to establish a communication between the local 
> (infected) computer and your remote console through a proxy server.
>
> The idea is to create two outbound sockets from the hacked computer: one 
> for a HTTP GET like http://you/get.jsp, and a second one with a 
> never-ending HTTP POST.

One method by which you can make sending of commands "real time" is to
use chunked encoding on the server side.  msfweb uses this to create a
realtime console in the context of the web-browser.

> Once established, the client sends a "GET" HTTP requests via the proxy, 
> and wait the "200 OK" from the server. It's like a big file download.
> Commands from the console are sent through the GET response (200 OK).
>
> When a command is received, a response (data) may be sent with "POST" 
> channel to the remote console.
>
> Consequently, in our case here, the console behaves like an HTTP server.
>
> Depending on the actual setup, proxies and firewalls are usually 
> bypassed with a such trick because we use a trusted component to 
> communicate.

Indeed, this technique is a well known method by which standard
transparent proxy and outbound firewall rules can be bypassed.  However,
it is not possible, via any methods that I'm aware, to create a
post-exploitation payload that is capable of doing HTTP tunneling that
wont be incredibly large in size.  From previous implementations of HTTP
tunneling systems that I've seen and implemented (C/C++), it doesn't seem
feasible, though I would love to be proven wrong (perhaps some API I'm
not aware of that could be taken advantage of on Windows).  I outlined
some of the reasons that it would be large in a previous E-mail.

> Integrating the malicious code in a browser may be achieved by creating 
> a browser helper object (like spywares/adwares usually do; see 
> http://securityresponse.symantec.com/avcenter/venc/data/adware.browseraid.html) 
> or by injecting a DLL into a network process 
> (http://www.codeguru.com/Cpp/W-P/dll/article.php/c105/). Hard patching by 
> modifying the IAT may also be done, but in this case, the Windows File 
> Protection (WFP) has to be disabled or hooked.
>
> Using OLE, there is a good PoC: http://nicob.net/jab/JAB-0.5.tgz. Please 
> refer to http://www.nicob.net/jab/Presentation-SSTIC.pdf (French) for 
> the presentation.
>
> Another problem then comes : the proxy credentials (NTDLM, AD or Basic 
> Authent). Nowadays, proxies needs authentification and the agent must 
> use them.

Using the WININET API as I described previously allows you to avoid
caring about the specific proxy authentication method being used, although 
you still need to acquire the authentication credentials by one way or
another (sniffing key strokes, cracking local passwords, checking to see
if their credentials have been saved).

> However, good antiviruses usually detect code injection & hard patching 
> & malicious components... There are still other (less known) solutions...

Definitely true, which is why being as stealthy as possible (avoiding
touching the disk, avoiding process creation where possible, etc) are
your best bet at running code under the radar of existing antivirus and
antispyware products.  While this decreases your number of options, it
nevertheless makes post-exploitation more reliable if it can be
accomplished in a reasonable size.

Barring this, though, there are a number of ways to make code injection into a
trusted process a reality.  It will, for the foreseeable future, always be 
a cat and a mouse game.  For instance, you could have a payload that 
enables the execution of untrusted ActiveX controls and adds your target 
site as a trusted site.  Once initialized, a hidden internet explorer can 
be launched to your target URL that then downloads and executes an embedded 
ActiveX control.  Since the site is in the trusted sites list, Internet
Explorer will not attempt to warn or prompt the user that an ActiveX 
control is being run.  This payload would be relatively small to implement 
and would not require a network connection in the context of the potentially
untrusted process.  This will only work if the logged in user is 
administrator (the downloading of ActiveX controls is not permitted for
non-administrative users in Internet Explorer).  This payload could be
implemented in a reasonable size, in theory.

There are also a number of alternatives to the CreateRemoteThread
technique that can be used to achieve the same goal.  However, these
techniques (when applied to the current topic of discussion) would still
have the same burden of size.  When implementing a payload, size will
always be an important factor since the size directly influences the
range of exploits that it will be usable against.  Staging technology
that requires a network connection (other than findsock) is not 
applicable in this case because it's a cart before the horse issue,
though it may be possible to use an egghunt style "stager" to find the
larger HTTP tunneling stage depending on the specifics of the exploit.

What are some of the other techniques you're referring to?