mailing list archives
Re: Help with java/meterpreter/war_bind_http payload handler
From: Michael Schierl <schierlm () gmx de>
Date: Fri, 01 Nov 2013 21:43:32 +0100
Am 09.09.2013 17:50, schrieb Joshua Smith:
I would like to help on the Ruby side, if I'm able. My java sucks.
But, I won't have spare cycles for about a week. I have to finish a
side job I've been slow on.
since apparently that week still is not over despite already having 53
days (and you seem to have disappeared from IRC, too?) - could anyone
else please have a look?
Fullquote retained since it has been quite a while ago:
On Sep 9, 2013, at 9:29 AM, Michael Schierl <schierlm () gmx de> wrote:
For some time (first commit was Mar 29, 2012) I've been trying to
build a payload handler that works both with custom generated war
files with multi/handler, and with exploits that put war files to a
publicly available webserver (like the tomcat and jboss ones) and
that tunnels the payload communication (Java Meterpreter) over that
http(s) connection - which is especially useful if egress ports are
filtered from the network where the webserver is located.
But due to recent lack of time (and motivation, and too much
frustration when trying to get this working), this endeavor is
somehow dormant, and I'd like to ask you if anyone of you, who is
also interested in seeing this done, would like to help me here.
The Java side of it was not that much of a problem (and has already
been tested outside Metasploit and works well): I used the http(s)
bind payload and changed it so that instead of polling an URI, it
puts the packets into an internal buffer which can then be polled
and filled via http by a custom servlet
(PayloadTunnelServlet.java). Combined with some minor tweaks to the
bootstrapper class (Payload.java) this works well.
I have pushed a rebased and retabbed (but not retested) version of
However, the Ruby side did not work out that well. In case anyone wants
to help me out (or take it over), the current version (again,
rebased and retabbed, but not retested) is available at
* Generating of war files with msfvenom and/or generate command works
well, since it only needs to swap one payload class and use a
different config. I also managed to tweak the PayloadCompat
settings so that you cannot combine incompatible stage/stager
combinations like java/shell/war_bind_http. But, I did not manage
to tweak PayloadCompat so that it is impossible to use this stager
with any exploits that do not create war files (like applet
exploits or that one jboss exploit that creates a JSP file).
Probably easy for someone who understands the PayloadCompat system
better - any directions for that would be appreciated.
* The current implementation works by creating a Ruby thread that
repeatedly polls the servlet and passes the data to the normal
reverse_tcp_http handler and vice versa. Might be nicer to create
a new payload hander for this that does not call into
reverse_tcp_http, but I think that is a larger endeavor and it
would need some ninjas that know how the handler code work (not
only by trial&error like me).
* I'm having trouble starting my handler for both exploits and
multi/handler use. When my handler module overwrites start_handler,
it is called in all cases, but called to early for exploits, and
datastore access does not work. When it overwrites handler, it gets
called right at the right time for tomcat_mgr_deploy (and datastore
access works), but called never for multi/handler. If I did not
miss a callback I could overwrite, probably some new callback would
be needed to get this working properly.
* Also, I'm unsure how to pass the information how to reach the
servlet from exploit to payload. In case of multi/handler it is
clear that the user will have to supply it, but in case of an
exploit that uses a randomized servlet name, I think the exploit
module must be modified to somehow notify the handler about the new
path. My current "solution" of checking the payload name in the
exploit and changing the datastore dynamically works, but is
probably not the nicest way.
* And last but not least, currently all the war exploits clean up
the war as soon as a session has been created. In case of this
payload, they will have to wait until the session is destroyed,
since otherwise the tunnel will break down obviously. I really have
no idea how to properly implement this without adding knowledge of
all exploits into my handler to call them back. Maybe have some
method in handler that takes a method reference/pointer (or however
you call that in Ruby), the exploit calls it when it thinks it
could clean up with a reference to the method that does the
cleanup, and the default implementation calls it immediately but
the bind_http payload calls it later once the session is
And I've probably forgotten some more obstacles that will come up
once these are solved...
So, anyone wanting to help me here? Pull requests that solve some
of the points and/or comments that point me to the right direction
- Re: Help with java/meterpreter/war_bind_http payload handler Michael Schierl (Nov 01)