Re: Help with java/meterpreter/war_bind_http payload handler

[Michael Schierl <schierlm () gmx de>]

Hello Josh,


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:
>
> > 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
> >
> > https://github.com/schierlm/metasploit-javapayload/compare/rapid7:master...java_war_bind_http_incomplete2
> >
> >
> >
> > 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
> >
> > https://github.com/schierlm/metasploit-framework/compare/rapid7:master...java_war_bind_http_incomplete2
> >
> >
> > * 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.
> >
> >
> > Regards,
> >
> >
> > Michael
_______________________________________________
https://mail.metasploit.com/mailman/listinfo/framework