On a recent internal penetration test, the clients goals were to gauge what an internal user or attacker could achieve with user level access to their network. In these cases you want to look for known exploits, weak passwords and miss-configurations.
This one fell into the miss-configuration bucket. Its not an issue with the software itself, but was an issue with the state the application was left in
So generally in these scenarios, the first step i do is find out who i am.
Next there are a bunch of standard stuff to do here, for windows hosts take a look at seatbelt for a great automation option. https://github.com/GhostPack/Seatbelt. For this example lets say we’ve done that or followed another path and started to focus on running services. I then checked for services that are set to Auto start, Currently running and not in c:\windows:
The openfire service seems interesting, and its running as LocalSystem.
Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache License. It uses the only widely adopted open protocol for instant messaging, XMPP Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.
So i then took a quick dive into the Openfire directory to see if we can find some useful information.
Looking at the openfire config file we can see it should be listening on port 9090. You could have found this out by running a netstat or portscanning but we are here either way.
Opening up the browser to that port we can see the Openfire server is listening and seems to be waiting for us to configure it!
Choosing the defaults, we get the server running set up.
Now that we have admin control of the Openfire application we can upload and install malicious plugins that will run as LocalSystem.
I spin up a seperate VM to build some plugins. But first, I start looking at available plugins on the ignite github page: https://github.com/igniterealtime. I chose to git clone this repo: openfire-xmldebugger-plugin.
Modifying the contents of '\openfire-xmldebugger-plugin\src\web\debugger-configuration.jsp' with a simple webshell should do the trick
Then build the plugin with mvnw -verify. If everything goes as planned the compiled JAR will be located @ ‘\openfire-xmldebugger-plugin\target\xmldebugger-openfire-plugin-assembly.jar‘
Back on the target, transfer and install the plugin
The web shell should be located at: Server -> Server Settings -> XML Debugger Properties. Running a whoami confirmed we have a system shell!
At this point post exploitation went something like, dump hashes, elevate to domain user, pivot, dump hashes, elevate to domain admin, Own the Domain.
