Help with java/meterpreter/war_bind_http payload handler

[Michael Schierl <schierlm () gmx de>]

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