The Oxeye research team has found a critical unauthenticated Remote Code Execution vulnerability in the popular Time Series database - OpenTSDB. The vulnerability was disclosed to the project owners and was patched in version 2.4.2. GitHub has issued CVE-2023-36812 for this critical vulnerability and a CVSS score of 9.8.
Potential vulnerability impact – an unauthenticated threat actor can execute arbitrary system commands on an OpenTSDB server by writing user-controlled input to the Gnuplot configuration file and running Gnuplot with the generated configuration.
We highly recommend upgrading to the latest version. If unable to upgrade, users can disable Gunuplot by utilizing the configuration option [.inline-code] tsd.core.enable_ui = true [.inline-code]. Additionally, they may remove the shell files [.inline-code] mygnuplot.bat [.inline-code] and [.inline-code] mygnuplot.sh[.inline-code].
From the OpenTSDB documentation:
OpenTSDB is a distributed, scalable Time Series Database (TSDB) written on top of HBase. OpenTSDB was written to address a common need: store, index and serve metrics collected from computer systems (network gear, operating systems, applications) at a large scale, and make this data easily accessible and graphable.
Our story begins by digging into the past vulnerabilities in the “Issues” tab in the Github repository. Back in 2016, a remote code execution vulnerability was reported. The root cause of that vulnerability was improper sanitization of specific query parameters.
Four years later, in 2020, during a penetration testing routine, two security researchers - Shay Rod and Aviad Golan, found another remote code execution vulnerability, mainly by abusing the system and not sanitizing certain query parameters.
Seeing this recurring pattern of RCEs through improper sanitization of parameters made us ponder one of the key takeaways we listed in our recent presentation in BlueHatIL about an RCE vulnerability we found in Backstage.
Where there’s smoke, there’s fire
Our main goal was to bypass the restriction posed by the various security patches applied to fix the previous vulnerabilities.
This particular patch tried to forbid backticks from appearing in different query parameters according to the first RCE found in OpenTSDB. For example, here is a code snippet of the patch:
The patch for the second vulnerability removed the naive check of backticks with more complex regular expressions to forbid certain characters from appearing in the query string:
Based on our analysis, the recent patch applied has revealed an issue with the current regular expressions. Specifically, they are not effectively inspecting newlines, resulting in a successful bypass of the sanitization process. Bypassing the regular expressions led to Remote Code Execution on the latest version (2.4.1):
The Oxeye research team contributed to the BSidesTLV 2023 conference this year, a CTF challenge inspired by the vulnerability we found in OpenTSDB. We wanted to share the knowledge we gained during this research with the community, and what better way to do that than a CTF challenge?
The scenario we portrayed involves exploiting this remote code execution vulnerability by tricking a Prometheus server into scraping our controlled server. By responding with a 302 redirect, we force Prometheus to request any server in its line of sight.
The server the participants had to exploit is a vulnerable OpenTSDB instance running beside Prometheus. To make things clearer to our audience, since this is a CTF challenge after all, we exposed to the user a small web API using FastAPI that exposes three endpoints:
Upon successfully exploiting the vulnerability chain, the coveted flag will be readily available on the local filesystem of the OpenTSDB server. It can then be obtained with ease by those who can access it.
Here is a video that depicts the entire exploitation chain of this challenge:
We found this default behavior of Prometheus of reacting to redirects pretty odd. Before using this technique in the challenge, we responsibly disclosed this issue to the Prometheus team.
However, we were informed that this behavior is not accepted as a security vulnerability. This topic has been discussed before, and the conclusion was that the redirect behavior abused here is also a feature many users actively use.
The Prometheus team has recognized the importance of clear communication regarding this behavior. Therefore, they have updated the documentation to explicitly inform users that Prometheus will follow redirects by default.
During the CTF event, we received some positive feedback from the participants. One of the feedbacks that stood out was particularly noteworthy, and we would like to share it here as an example.
One of the other participants, going by the name [.inline-code] un5h4d0w [.inline-code], kindly posted a write-up of their solution after completing the challenge.
The Oxeye team that discovered this vulnerability is the same one that powers our product, the Oxeye Application Security Platform. Splitting time between vulnerability research and product research accomplishes two things - it helps us give back to the security and software development communities, and helps us continually enhance our product and accomplish our goal of helping companies speed up their software innovation without sacrificing security. Contact us to find out how we may be able to help you.
