I've noticed in my testing that if authentication can be bypassed for an older JBoss target server (as reported by metasploit-framework/modules/auxiliary/scanner/http/jboss_vulnscan.rb), your chances of getting a successful shell is greatly increased if you set the http VERB option from the default of GET to HEAD. This is easy to do since changing the http VERB is a user configurable option for this exploit module.
However, when you set the verb to HEAD so that auth can be bypassed for that target, I find that I always get a 500 internal server error response from the target (even though the exploit ran fine and I got a call back shell) and that 500 error causes the whole module to exit and fail due to line 206 shown here:
fail_with(Failure::Unknown, "Upload to deploy WAR archive [#{res.code} #{res.message}]")
Again, even though I got remote code execution and a call back, the original payload sent with HEAD triggers a 500 error response and fails the whole module with the above line. What I would suggest is when the HTTP verb is set to HEAD, do not execute the above fail_with line and also place a similar VERB check condition on line 289 as well shown here:
print_warning("WARNING: Undeployment failed on #{app_base} [#{res.code} #{res.message}]")
Also as a general suggestion to improve likelihood of exploitation for this module, I would suggest the following two enhancements:
When LHOST is set by the user, automatically use that value for the SRVHOST parameter also since in the reverse_* scenario, SRVHOST is the ip address that the Jboss deploy method will try to connect back to, to retrieve the war file and a default value of 0.0.0.0 will mean you never get a callback and the exploit silently fails. Better chance of success if SRVHOST is auto set to the same value as LHOST, when LHOST is set.
After the module finishes running with the GET http verb, which is the default verb, and if you receive a 401 error to that request, do the check that's in jboss_vulnscan to see if auth can be bypassed and if so, iterate once more using the HEAD verb to bypass auth to try again.
I think doing the fix above and both of these enhancements will help the overall maturity of the exploit to go up and the chances for achieving a shell.
bcoles
commented
5 years ago
Module: metasploit-framework/modules/exploits/multi/http/jboss_maindeployer.rb
I've noticed in my testing that if authentication can be bypassed for an older JBoss target server (as reported by metasploit-framework/modules/auxiliary/scanner/http/jboss_vulnscan.rb), your chances of getting a successful shell is greatly increased if you set the http VERB option from the default of GET to HEAD. This is easy to do since changing the http VERB is a user configurable option for this exploit module.
However, when you set the verb to HEAD so that auth can be bypassed for that target, I find that I always get a 500 internal server error response from the target (even though the exploit ran fine and I got a call back shell) and that 500 error causes the whole module to exit and fail due to line 206 shown here:
fail_with(Failure::Unknown, "Upload to deploy WAR archive [#{res.code} #{res.message}]")
Again, even though I got remote code execution and a call back, the original payload sent with HEAD triggers a 500 error response and fails the whole module with the above line. What I would suggest is when the HTTP verb is set to HEAD, do not execute the above fail_with line and also place a similar VERB check condition on line 289 as well shown here:
print_warning("WARNING: Undeployment failed on #{app_base} [#{res.code} #{res.message}]")
Also as a general suggestion to improve likelihood of exploitation for this module, I would suggest the following two enhancements:
I think doing the fix above and both of these enhancements will help the overall maturity of the exploit to go up and the chances for achieving a shell.