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

[eip at tampabay.rr.com (eip)]

The OLE/IE automation that ALLAIN was talking about can be found here:

http://www.securiteam.com/securityreviews/6S0030ABPE.html

Basically they use IE to go and fetch pages from one of there servers. The
pages they control tell the client what to do. The reason they use IE is so
that they can bypass client side firewalls/IPSs. I think SecurityFriday
initially found this techinique and present it at BlackHat
(http://www.securityfriday.com/tools/IEen.html) a few years ago. They have a
program called IE'en. It allows you to remotely watch and/or control
someones Internet Explorer. It is kind of like an Internet Explorer sniffer
of sorts.

eip



----- Original Message ----- 
From: <mmiller at hick.org>
To: "ALLAIN Yann" <Yann.Allain at accorservices.com>
Cc: "H D Moore" <hdm at metasploit.com>; <framework at metasploit.com>
Sent: Wednesday, February 16, 2005 11:49 AM
Subject: Re: [framework] Idea for a new payload : Manipulate Internet
Explorer with OLE AUTOMATION


> On Wed, Feb 16, 2005 at 01:14:58PM +0100, ALLAIN Yann wrote:
> > May i suggest you a new payloads : Manipulate IE in OLE AUTOMATION to
> > create an outbound tunnel on http. Like the Setiri Troyan of SENSEPOST
> > or the GASPER troyan from rstack group.
>
> I'm not familiar with the approach they used (couldn't find reference to
> it on google).  It seems like using OLE automation to create an HTTP
> tunnel may be a bit overkill, but I would be curious to see their
> approach.  Why not just use the WININET API (InternetConnectA,
> InternetOpenUrlA)?  This API even has the advantage of transparently
> using any proxy that has been defined for Internet Explorer, though if
> the proxy requires credentials you will have to provide them (which you
> can do via InternetSetOptionA).
>
> > I will try to inject DLL that manipulate IE in OLE with your marvelous
> > Meterpreter. But could you give me your feedback of this payloads
> > (feasibility,  stability, and so one)
>
> The usefulness of the outbound HTTP tunnel would be to bypass outbound
> firewall restrictions and transparent HTTP proxies, or so I assume.
> The problem is that in order to upload the DLL to the target machine,
> some sort of connection has to be established (reverse connect, port
> bind, findsock), or in this case an HTTP tunnel.  Since the HTTP tunnel
> would have to be established before the DLL that is to create the HTTP
> tunnel can be uploaded, you have a cart before the horse issue.
>
> In order to make this work you would need a first stage payload that
> connects via HTTP to the attacking machine (or some other intermediate
> machine) and downloads a second stage payload.  The second stage payload
> would then handle the creation and management of the HTTP tunnel to the
> attacker, at which point you could implement a specialized second stage
> HTTP tunneling payload to download and inject a DLL.
>
> While it may be possible to write custom payloads that are capable of
> using an HTTP tunnel, all of the existing second stage payloads
> in the framework that require a valid socket will not be able to work
> with them.  The reason for this is that the second stage payloads assume
> that they are being passed a stream-based socket that can be passed to
> functions like ws2_32!recv.  This is not the case when using an HTTP
> tunnel since you don't have a true streaming connection (more of a
request/
> response).  While it is possible to emulate a streaming connection using
> HTTP/1.1 KeepAlive with multiple request/response inside the same
> HTTP connection, the second stage payloads will still not work without
> an intermediate socket that is truly streaming (such as a local TCP
> abstraction layer between the second stage payload and the HTTP
> tunneling payload).
>
> We've considered writing first stage payloads that use valid HTTP
> request/response formats in the past and may still do this in the
> future.  Though, as I've identified, it is a challenge to create truly
> streaming HTTP tunnels due to the nature of the protocol itself.
> In the end, some form of abstraction is required if one hopes to
> use valid HTTP request/responses between the target machine and the
> attacker and still retain compatibility with other payloads that assume
> they are dealing with a truly streaming connection.
>
> So, to summarize, an HTTP tunneling payload is indeed feasible and could
> be made stable, but the subtle complexities of making a stream-based
> abstraction to the non-stream-based HTTP tunnel make the problem more
> complicated than it would otherwise seem.  Now, after that explanation,
> I hope I didn't miss the point of your question, but if I did let me
> know. :)