Unsuccessful deployment

[antoniosanchezc-zz]

Hi,

First of all, congrats for the awesome tool.

I'm doing an internal pentest at the moment, and I've found a JBoss 5.1.0 GA which in theory is vulnerable to the invoker/JMXInvokerServlet and invoker/EJBInvokerServlet vulnerability. At first I tried to exploit it using the metasploit module, and then a similar PHP exploit I found on EDB, but both were failing for some reason. As I'm already domain admin, I could log to the box and see the logs, it turns out it was complaining about the remote .war file I was trying to upload and deploy, as it was hosted on my own web server. After doing some research I found this article: http://breenmachine.blogspot.co.uk/2014/02/jboss-jbxinvoker-servlet-update.html which comes to say that JBoss >= has a bug/feature that stops remote objects from being deployed. I read his post, compiled the Java exploit and ran it. It did upload my .war file to the folder /management (...management/cmd.war), but for some reason it seems as if it doesn't deploy it!!.

After that, I found this project, gave it a go, and the result is the same, your tool does upload the .war file, but it is never deployed for some reason I can't understand!.

Any ideas?

[breenmachine]

Hey Antonio,

The reason you're seeing the same results from both tools is because they use the exact same code :)

It's been a while since I've touched this stuff. I've seen the behavior you're describing once but didn't have time to dive into it. The WAR get's uploaded but deployment fails (if you check the logs, you'll probably see that it tried to deploy and there was an error). It's not an authentication issue because if that were the case it would never get uploaded at all.

Maybe drone can shed some light on this. If I see it in the wild again I'll try to make some time to reproduce.

[antoniosanchezc-zz]

Hey mate,

Thanks for the quick reply!. Thing is that I do not see any error in the logs, as I saw before when I used teh PHP or Metasploit module, as they both use remote objects. Its' just bizarre.

[breenmachine]

The MSF module does things a little differently, they haverone and myse a hardcoded blob that gets sent over where we generate a version specific one on the fly. If you're trying to debug, I'd suggest running the Java code in a debugger and inspecting the objects at each step, especially the ones that come back from the server.

If you have full access to the box, you can monitor the JBoss trace log that gives full detail on whats going on, it's a text file on the server, I think it has more detail than what's in the web interface.

[antoniosanchezc-zz]

‎Yeah that's how I was looking at the logs, as I do have access to the box, but do not know valid creds for the JMX-Console. There are not errors at all when I use your tool or the Java Version,as the upload‎ is successful, but it doesn't get deploy... I just got off the client's office, I'll be back on Monday and see what I can do, I have to find out what's going on!

From: Stephen Breen Sent: Friday, 20 March 2015 17:03 To: hatRiot/clusterd Reply To: hatRiot/clusterd Cc: Antonio Sánchez Subject: Re: [clusterd] Unsuccessful deployment (#36)

The MSF module does things a little differently, they haverone and myse a hardcoded blob that gets sent over where we generate a version specific one on the fly. If you're trying to debug, I'd suggest running the Java code in a debugger and inspecting the objects at each step, especially the ones that come back from the server.

If you have full access to the box, you can monitor the JBoss trace log that gives full detail on whats going on, it's a text file on the server, I think it has more detail than what's in the web interface.

— Reply to this email directly or view it on GitHubhttps://github.com/hatRiot/clusterd/issues/36#issuecomment-84068288.

---

This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com

---

---

Disclaimer: This e-mail and any attachments are confidential.

It may contain privileged information and is intended for the named addressee(s) only. It must not be distributed without Dionach Ltd consent. If you are not the intended recipient, please notify the sender immediately and destroy this e-mail.

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Unless expressly stated, opinions in this e-mail are those of the individual sender, and not of Dionach Ltd.

Dionach Ltd, Unipart House, Garsington Road, Oxford, OX4 2PG Company Registration No. 03908168, VAT No. GB750661242

---

[antoniosanchezc-zz]

I finally found the reason why the .war file was not being deployed. It turns out they had the automatic Hot Deployment module/service/whatever disabled. For JBoss 5.x this is as simple as moving or deleting a specific file. For more info:

https://developer.jboss.org/wiki/JBoss51DisableEnableHotDeployHDScanner

ALthough it's still possible to upload files to the server without credentials, which is an issue, I don't see a way of getting a shell, which is a shame!.

[hatRiot]

Hi @antoniosanchezc

Thanks for the feedback and follow-up on this. I do wonder if there's a way to write or move that file back using an exposed JMX console. I'll look into this.