Vulnerability of the Month – Controversy of the JetBrains TeamCity CVE-2024-27198 & CVE-2024-27199
2024-5-4 02:42:28 Author: securityboulevard.com(查看原文) 阅读量:3 收藏

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 but DID NOT communicate about the security incident when they released the patch! Rapid7 however published full technical documentation of the security issue on the same day. 

Both parties have rationale behind their approach, JetBrains didn’t want to release information that would allow hackers to target systems before they had been patched. Rapid7 didn’t want to wait because people wouldn’t understand the urgency of patching. But here is the problem, the fact that both decided to adopt their own approach left TeamCity users in the most vulnerable position. The attackers had information from Rapid7, but the user had no information regarding the security of JetBrains. This likely affected the urgency in which they updated. This likely contributed to why we saw this vulnerability exploited in the wild so quickly. In the end, both company's approaches contributed to what they were trying to avoid.

*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog - Code Security for the DevOps generation authored by Mackenzie Jackson. Read the original post at: https://blog.gitguardian.com/jetbrains-teamcity-cve-2024-27198/


文章来源: https://securityboulevard.com/2024/05/vulnerability-of-the-month-controversy-of-the-jetbrains-teamcity-cve-2024-27198-cve-2024-27199/
如有侵权请联系:admin#unsafe.sh