Home page logo

metasploit logo Metasploit 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:

Hello all,

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.




  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]