Your Build Server Just Became Their Beachhead: TeamCity RCEs

Alright, folks, let's talk about something that should make your palms sweat a bit. If you're running JetBrains TeamCity for your CI/CD, you just dodged a bullet – or rather, you had a gaping hole in your armor that's now (hopefully) patched. We're looking at a pair of critical RCE vulnerabilities that, when chained, give an unauthenticated attacker the keys to your entire software factory. Yeah, it's as bad as it sounds.

The Brain of Your Build Process, Now a Backdoor

For those unfamiliar, JetBrains TeamCity is a popular CI/CD server, the kind of software that orchestrates your code builds, tests, and deployments. It's the central nervous system for your development lifecycle. And that, my friends, makes it an incredibly juicy target.

We're talking about two specific CVEs here, both disclosed and patched in early March 2024:

• CVE-2024-27198: An authentication bypass vulnerability with a CVSS v3.1 score of 9.8. Ouch.
• CVE-2024-27199: A remote code execution vulnerability, also scoring a 9.8. Double ouch.

The punchline? An unauthenticated attacker could chain these two together to achieve full remote code execution on your TeamCity server. It's like someone picking a single lock to get into your house, only to find the master key to everything sitting right inside the front door.

How the Chain Reaction Works

Let's break down the technical bits, because understanding the mechanism is half the battle in defending against it. Or, in this case, understanding why you need to patch yesterday.

CVE-2024-27198 is where it all starts. This vulnerability allows an unauthenticated attacker to bypass the authentication mechanism in TeamCity On-Premises by exploiting a path traversal flaw. Essentially, an attacker could craft a specific URL that tricks the server into thinking they're already authenticated, giving them access to critical endpoints that should require credentials. Think of it as convincing the bouncer you're on the guest list by showing him a fake VIP pass that just happens to work because his name is spelled wrong on it.

Once authenticated (or rather, once the server thinks they're authenticated), the attacker can then leverage CVE-2024-27199. This RCE vulnerability allows them to execute arbitrary code on the TeamCity server. How? By abusing another path traversal bug. Specifically, attackers could manipulate file paths to write arbitrary files to the server's filesystem, including JSP pages or other executable content that the server would then process. Game over.

The sequence is elegant in its malicious simplicity: bypass authentication to gain administrative-level access, then use that access to upload and execute code. This isn't just a misconfiguration; it's a fundamental flaw.

Why a CI/CD RCE is a Supply Chain Nightmare

If you're still not sweating, let me explain why an RCE on your CI/CD server is a particularly nasty flavor of bad. This isn't just about defacing a website or stealing some user data. This is about deep, systemic compromise.

An RCE on a build server is like an attacker gaining control of the factory that produces all your software. They can inject malware directly into your binaries, sign malicious code with your legitimate certificates, or even sabotage your entire build process.

Consider the potential impact:

• Supply Chain Attack: Malicious code injected into your applications before they even hit production. Remember XZ Utils? This is how it starts.
• Credential Theft: Access to all the credentials stored in TeamCity – Git repositories, cloud environments, artifact registries.
• Lateral Movement: A foothold on the build server provides an excellent pivot point into other critical systems within your network. Build agents often have elevated privileges to deploy code everywhere.
• Data Exfiltration: Source code, intellectual property, sensitive configuration files – all ripe for the taking.

This falls squarely into MITRE ATT&CK technique T1190: Exploit Public-Facing Application, specifically targeting an application like TeamCity that's often exposed to the network, if not the internet. Given the swiftness of exploitation observed in the wild, it's clear threat actors are actively scanning for these types of weaknesses.

The Fix and the Future

JetBrains acted quickly, releasing patches for TeamCity On-Premises versions 2023.11.3 and newer. If you're running anything older, you need to upgrade and then apply the patch. There's also a server-side patch available for versions 2023.11.2 and earlier. Point is, if you haven't patched, you're playing with fire. Shodan scans showed unpatched instances within hours of the public disclosure. This isn't a theoretical threat; it's actively being exploited.

This incident is a stark reminder that our CI/CD systems, often seen as "internal developer tools," are critical infrastructure. They are, quite literally, the keys to your kingdom of code.

Actionable Takeaways: Don't Get Pwned

1. Patch Immediately: Seriously, stop reading this and go patch your TeamCity instance to the latest version (2023.11.4 or apply the server-side patch if on an older but supported version). This isn't optional.
2. Network Segmentation: Is your TeamCity server directly exposed to the internet? It shouldn't be. Place it behind a VPN or a strong firewall. Limit access to only necessary personnel and IP ranges.
3. Least Privilege: Review the permissions of your TeamCity server and its build agents. Do they really need admin access to everything? Probably not.
4. Monitor for Anomalies: Keep an eye on your TeamCity logs for unusual activity, new users, unexpected builds, or file modifications. Your SIEM should be screaming if something like this goes down.
5. Regular Audits: Treat your CI/CD pipeline like you would any production system. Regular security audits are non-negotiable.