Introduction:
This document illustrates an unauthorized RCE popularly known as remote code execution. This critical vulnerability has been reported in dotCMS - an open-source CMS developed in Java and utilized by more than 15,000 companies including Fortune 500 brands.
A few months back, this critical vulnerability was reported in a large bank that was using dotCMS software. You can find the detailed description of this exploitation using source code analysis from there.
CMS Description:
DotCMS is used to manage content and content-driven websites. It provides a free community-based edition of its content management system, alongside an Enterprise SaaS edition that can be purchased on an annual or monthly subscription.
Vulnerability Severity :
CVE ID: CVE-2022-26352 (dotCMS)
Severity: - CRITICAL
CVSS Vector - NA
Scope of Impact :
This vulnerability has been reported in dotCMS v22.01 though there are.various vulnerable dotCMS environments listed below and official mitigations are available:
- dotCMS 5.1.6+
- dotCMS (4.x-5.1.5)
- dotCMS (<4.x)
WHERE IS THE VULNERABILITY PRESENT?
As per the vulnerability reported by researchers at Assetnote, an adversary is able to upload arbitrary files such as jsp files by using a directory traversal naming technique directly on the server through file upload flaws in the Tomcat root directory. This enables you to perform remote code execution in the underlying Tomcat server.
dotCMS has functionality to upload the file via content API. The uploaded file is directly placed in the .temp directory of the server before it becomes content. The vulnerability arises when the CMS does not validate and sanitize the file name that contains the malicious jsp code with the directory traversal naming technique at server-side via the POST multi-part request header. This leads to uploading the ContentResource (POST /api/content) directly on the temp directory outside the dotCMS temp directory. By using this technique, an adversary can upload the malicious crafted jsp file to the webapp/ROOT directory of dotCMS that leads to perform remote code injection.
Note: If DotCMS is using default configuration, then it allows CONTENT_API_ALLOW_ANONYOUS=WRITE. In this scenario, this vulnerability can easily be exploited by unauthorized users.
Risk:
An adversary can upload malicious jsp files on the Tomcat server file system and execute those uploaded files directly through client side proxy tools like burp suite and internet browsers (such as Mozilla, Google Chrome) that lead to perform command injection directly on the underlying server without interruption.
It is also possible to perform all the operations that an administrator can perform on the server - i.e. create, modify, update and delete files. An adversary can chain these flaws to perform different attacks on connected servers on the same network.
This leads to compromising the Confidentiality, Integrity and Availability (CIA) of the underlying system, dump entire configuration files, and sensitive data that contains PII details of the users.
In other words, an attacker can escalate this vulnerability to replace the existing files of the server with the malicious web shell to gain persistent remote server access without the victim’s knowledge.
Mitigation:
The official recommendation provided by dotCMS to mitigate the issue is to upgrade dotCMS versions that contain code fixes for the reported issue. This includes versions 22.03, 5.3.8.10_lts, and/or 21.06.7_lts.
- Hotfix Plugins:
OSGI based plugins are developed that can be deployed in the affected versions of dotCMS environments. Official Github links are available for the below versions:
- Implementation of WAF on the environment that requires the rules below to restrict directory traversal requests on the server.
For example, AWS WAF has a ruleset: GenericLFI_BODY which looks for the presence of Local File Inclusion (LFI) exploits in the request body. Examples include path traversal attempts using techniques like ../../.
Label: awswaf:managed:aws:core-rule-set:GenericLFI_Body
- Disable Anonymous Content Submittal
If you are not using an anonymous content submission in your application, e.g. dotCMS forms or front end content submission, then in this case, we recommend you set CONTENT_APIS_ALLOW_ANONYMOUS=READ or CONTENT_APIS_ALLOW_ANONYMOUS=NONE in your dotmarketing-config.properties.
By configuring this, it prevents your CMS from anonymous access to /api/content, which means an anonymous attacker will not be able to exploit the vulnerability.
Note: this configuration does not prevent a known/authenticated user from exploiting the vulnerability.
Exploit implementation :
Attack Scenario:
We will be using a docker image by creating a virtual environment setup of DotCMS Arbitrary File Upload (CVE-2022-26352) in a Linux environment.
For this practical, we require the below setup on the Linux machine.
- Docker
- Golang
- Nuclei
Exploitation:
- Download the github vulnerable docker image from the link below to your linux machine. https://github.com/h1ei1/POC/tree/main/CVE-2022-26352
- Now, we need to set-up the local environment in the machine, run the below command once docker is properly installed, then run on the Linux machine.
- The environment setup is successfully done. Visit the following URL and you will see the login page.
https://your-ip:8443/dotAdmin
- Now, we can exploit this vulnerability using a manual approach as well as an automated script. In this scenario, we will be using nuclei templates to exploit this vulnerability. We will run the command below to check the dotCMS vulnerability using the nuclei template.
nuclei -u https://192.168.201.174:8443/ -t cves/2022/CVE-2022-26352.yaml -p=http://127.0.0.1:8085We can see that exploit is successfully executed on the target and it uploads the malicious jsp file onto the target server.
- We will reproduce the exploit using Burp Suite by capturing the nuclei template exploitation. Upload the malicious jsp file using directory traversal technique in the Tomcat server as shown below. We will get 500 server errors, don’t be concerned with these.The malicious jsp file is successfully uploaded on the server.
- Now, we will validate the uploaded jsp file by using the below command. And, we can see the result of the remote code execution on the dotCMS Tomcat server.
https://192.168.201.174:8443/shell.jsp?cmd=id
