Metasploit mailing list archives
Help with java/meterpreter/war_bind_http payload handler
From: Michael Schierl <schierlm () gmx de>
Date: Mon, 09 Sep 2013 16:29:54 +0200
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
Current thread:
- Help with java/meterpreter/war_bind_http payload handler Michael Schierl (Sep 09)
- Re: Help with java/meterpreter/war_bind_http payload handler Joshua Smith (Sep 09)