Vulnerability of the Month - Controversy of the JetBrains TeamCity CVE-2024-27198 & CVE-2024-27199

In this blog series, we look at a new CVE each month and discuss its impact, discovery, and remediation. This month we are diving into the JetBrains TeamCity vulnerabilities which will allow hackers to take control over CI/CD servers by bypassing authentication. We will discuss the technical details of the vulnerability and then dive into some discussion around the controversy of this disclosure (we will spill the CVE tea!)

CVE #

Description 

Base Score

EPSS Score

Dates 

(for both)

CVE-2024-27198

Authentication bypass vulnerability in the web component of TeamCity utilizing alternative path issue 

9.8 (Critical) 

97.2%

Reported Feburary 19th 2024

Patched
March 4 2024

CVE-2024-27199 

Authentication bypass vulnerability in the web component of TeamCity utilizing path traversal issue

7.3 (High)

0.90%

Notes: The Base Score indicates how critical a vulnerability is while the EPSS score indicates the likelihood it will be exploited in the wild during the next 30 days 

JetBrains TeamCity

JetBrains TeamCity is a free CI/CD (continuous integration and Continuous Deployment) tool that is used by 30,000 DevOps teams and many more developers. This makes it a big target for attackers to conduct large-scale supply chain attacks which makes these vulnerabilities even more scary. The Russian-backed hacking group behind the 2020 SolarWinds attack was discovered to be actively attempting to exploit a similar but different vulnerability in Jetbrains TeamCity already back in 2023.

Opinion: Given that we know this vulnerability has been used in the wild to try and deliver malware through CI/CD servers, I believe it is likely that state actors like Midnight Blizzard are actively exploiting this given their previous modus operandi. 

About the vulnerability

These vulnerabilities are both authentication bypasses, the most severe of the two enables an attacker to conduct a complete takeover of the TeamCity server allowing RCE to essentially grant full access to the projects, build process, and artifacts. 

How does the exploit work?

By default TeamCity creates a web server over HTTP at port 8111, an attacker can then create a URL that bypasses all the authentication checks which then allows endpoints to be accessible that were meant to be secured behind authentication. The main exploitation path would be for an attacker to leverage this vulnerability by creating a new administrator account including passwords controlled entirely by the unauthenticated attacker, The attacker can then log into the web portal or request an administrator token to take full control of the system.  Read a full technical analysis 

Video demo for exploit

Versions affected 

Firstly, all cloud instances of TeamCity have been patched and only the on-prem versions are vulnerable from version 2023.11.3 it is CRITICAL that if you are using an on-prem version of TeamCity you update to at least 2023.11.4 released on March 4th, 2024 (Note, JetBrains have a very misleading versioning method). 

The Controversy 

If you thought the world of CVEs was boring, let me tell you there is enough drama it could be a new reality TV show on Netflix. 

This vulnerability was first discovered by the amazing research team at Rapid7 on February 19th who shared a detailed report to JetBrains. JetBrains then suggested a path in which they would follow to resolve this, including a blog post, email communication, and publishing the CVE records, but crucially, they would not release any of this until ‘a few days’ after the patch was released (which took multiple weeks). Rapid7 was adamantly against this as they believed it constituted ‘silent patching’, Rapid7 has a policy o release all information as soon as the patch is released. 

Silent patching is an unethical method of releasing fixes to security issues without communicating the issue itself. This is in the hope of not bringing attention to security issues but also means urgency to patch is not communicated to users leaving them vulnerable. 

JetBrains stopped communicating with Rapid7 from February 23rd to March 1st. On March 4th they released the patch and this same day Rapid7 wrote a complete technical breakdown of the vulnerability along with instructions to exploit. JetBrains also made mention of the vulnerability.

Almost immediately after, we observed this being exploited in the wild. Almost undoubtedly attackers were assisted by the Rapid7 technical report. However, would attackers be able to exploit it anyway? Or should we have waited a few days like JetBrains would have wanted? This is certainly an interesting debate and one I can argue for on both sides.

Overall I believe this shows the importance of the research team and the product team being on the same page when it comes to disclosure.