Reflections on trusting plugins: Backdooring Jenkins builds

When I first joined Synopsys, one of my colleagues posed an interesting question in one of our chat channels: how would one go about backdooring Maven builds in Jenkins? I found this intriguing but didn’t have much time to pursue it.

For the uninitiated, Jenkins is the most popular automation tool for building, testing, and deploying software in CI/CD. It is open source and used by many companies, large and small, to build their software.

Recent high-profile breaches have brought renewed attention to supply chain security, and I decided to revisit the question and develop a proof-of-concept Jenkins plugin that can add an attacker’s modifications to source code before it is built—no commits to the upstream source repository needed.

Before I proceed to the code, a few points:

• First, this approach assumes an attacker has sufficient privileges on a Jenkins instance to install plugins, and that they will not be noticed by the victim in time. But this is much more likely than you might at first assume.
  On internal pen tests, Synopsys often finds that Jenkins instances lack fine-grained authorization, running in modes like “Logged-in users can do anything” or occasionally even “Anyone can do anything.” Even when fine-grained authorization is used, it’s fairly commonplace that Jenkins instances are vulnerable to privilege escalations. Plus, credentials to access Jenkins are often relatively easy to come by.
  And so far, I haven’t seen much evidence of organizations closely monitoring plugin installs (though perhaps they should). In fact, I’ve found that systems like Jenkins and other development-related tools/infrastructure are often under-hardened, under-patched, and under-monitored in general.
• Second, I want to make clear that this has nothing to do with any defect or vulnerability in Jenkins. The technique shown here uses legitimate functionality that is and should be exposed to plugins.
• Finally, this is a proof-of-concept to show the relative ease of subverting a build system like Jenkins this way, highlighting why it’s so important to secure them. It should go without saying that it’s risky to carry out an attack like this during pen testing or red teaming, and it should be done only with great caution. (Plus, there are often quicker wins to be had from Jenkins, e.g., by obtaining credentials used for deployment). The code presented here is a quick-and-dirty without much mind paid to corner cases, caching, etc.

The code is pretty straightforward (and lacks caching) but notice that the file operations use Jenkins’ own FilePath class rather than Java’s native File class. The former will transparently handle files located on remote build agents.

The modified file will remain in the workspace after the build has completed. As a counter-forensic measure, one may want to revert it to its original state; I have not tried to implement this, but looking at Jenkins’s extension points it looks as though a viable approach would be to create a BuildStepListener with a finished() method that checks whether its BuildStep argument is an instance of Notifier.