mailing list archives
Re: Help with java/meterpreter/war_bind_http payload handler
From: Joshua Smith <lazydj98 () gmail com>
Date: Mon, 9 Sep 2013 10:50:50 -0500
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.
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 it at
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 destroyed?
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 are appreciated.