How to attack and protect WebLogic server

WebLogic is a popular enterprise middleware tool that orchestrates the interaction between backend systems and frontend clients. This makes it a valuable tool for attackers, who can exploit it to access and influence a wide range of organizational applications. In this blog post, we explore how to install a persistent backdoor on WebLogic Server. We then show which mitigation steps you can take to protect your systems against these types of attacks.

This blog post is based on a comprehensive research report by Pentera Labs, which you can read here.

What is WebLogic?

WebLogic, developed by Oracle, is a server software application that enables backend (applications, databases, etc.) and frontend clients to interact with each other in the enterprise. Often used in large-scale environments where complex transaction processing, application integration, and multi-tiered networking are required, WebLogic can simultaneously host and run multiple applications for on-premises and cloud enterprises. It also supports database connections. 

What’s the Risk of an Attack on WebLogic Server?

From an attacker’s perspective, gaining access to WebLogic’s management console has the potential to influence a wide range of servers. This is concerning for several reasons:

• Attacker Access to Sensitive Data – WebLogic servers often handle sensitive and critical data for businesses. A successful attack can lead to data breaches, exposing confidential information like customer details, financial records and intellectual property.
• System Downtime – An attack can disrupt the normal functioning of the server, leading to system downtime. This can have significant financial implications due to lost business, repair costs and damage to reputation.
• Compliance and Legal Issues – A security breach might result in enterprise non-compliance, leading to legal consequences and hefty fines.

Let the pwning Begin

Our goal at Pentera Labs was to gain access to WebLogic Server itself, from the outside. Access to WebLogic Server also provides access to the Backend applications it hosts or connects to. Below is a brief outline of the attack we conducted.

1. Our first step was authentication bypass. By using CVE-2020-14883, we were able to get instant access to the administration console.

2. Since the console’s interface was limited, we also used CVE-2020-14882 to create an unauthenticated RCE attack.

3. To effectively benefit from this vulnerability, we needed to use the Shell method or the Remote XML method.

• Shell method – Inserting code into the url to trigger an RCE on the host. This method is very useful and its main advantage is that it’s instant. However, this method only exists on versions 12.2.1.3.0 and later ones. For older versions, like 10.3.6.0.0 and 12.1.3.0.0, we would need another method.
• Remote XML method – In this method, we used “FileSystemXmlApplicationContext” instead of using ShellSession method. This method works on every WebLogic version, enabling us to fall back on it if the ShellSession method doesn’t work.

At this point, we had access to the OS of WebLogic Server, which meant we could run any command, if we had the right permissions. We also had full access to WebLogic’s files.

4. The next step was attacking the management console by hacking into the management API. Since the management API required credentials, we needed to obtain them.

WebLogic’s encrypted credentials exist in various places on the host. The two most common places are:

• config.xml – The server’s domain configuration file.
• boot.properties – A file that is used for automatically starting a WebLogic server without the need to input credentials.

5. To decrypt the credentials, we could choose between a few methods, for example:

• WebLogic Server Administration Scripting Shell (WLST) – This method is based on the built-in scripting shell that WebLogic provides. However, it is often buggy.
• Offline Decrypting – Extracting information to decrypt the credentials on our own machine. 

6. Now that we had the admin credentials, we were able to access the Management Console.

7. We could then perform any action supported by WebLogic, but we decided to focus on two main tasks.

1. Gathering database information and, potentially, credentials.
2. Deploying a WebShell for future backdoor usage. This was done by downloading an existing, legitimate WAR file from the server, adding malicious files to it and redeploying it, which provided us with remote access and control over the WebLogic environment.

And that was it! We then had a fully functioning webshell hidden inside an existing application hosted on WebLogic. 

Mitigation 

Follow these best practices and security measures to safeguard your WebLogic environment and protect against attacks and any backdoors.

1. Update WebLogic Server regularly, as newer releases often include security patches and vulnerabilities fixes.
2. Change default credentials immediately after installation. Passwords for administrative accounts should be strong and complex. Consider two-factor authentication.
3. Change admin credentials regularly to reduce the risk of credential leaks and compromises.
4. Separate WebLogic’s Administration Console to a different port. Use firewalls, network security groups, and other access control mechanisms to limit network access. Implement SSL/TLS for secure communication.

Read the entire in-depth report, which includes detailed explanations of all steps as well as code snippets and urls that you can follow and more mitigation practices. Click here.