Re: Help with java/meterpreter/war_bind_http payload handler

[Joshua Smith <lazydj98 () gmail com>]

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.

-Josh

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

_______________________________________________
https://mail.metasploit.com/mailman/listinfo/framework