BLOG POST

Continuous Integration Insecurity

 

December 10, 2015 | DevOps | Wes Davis

 

We at Conjur see little value in fear as a motivator. Whenever we do find legitimate reasons to be afraid, we like to build them into constructive conversations around better practices.

Today’s focus is on (in)security for continuous integration (CI) tools.

Insecurity for CI ToolsThis year, penetration tester and infosec researcher Nikhil Mittal has given the same presentation at both Black Hat conferences (USA and Europe). Mittal isn’t being lazy, he’s being relevant. For his talk “Continuous Intrusion: Why CI tools are an attacker’s best friends,” he tested five different tools — Jenkins, CruiseControl, Go, TeamCity, and Hudson — and found serious security issues with all of them.

When I say serious, I’m talking fundamental infrastructure security threats.

Thanks to low default security settings and practices that are far from “best,” Mittal shows that gaining access to CI tools can result in ownership over anything from the build process, source code, Git credentials, SSH keys, even all the way down to the machines running the slaves.

The bluntest version:

“I have not been through a single Pen Test or Red Team engagement where access to a CI tool did not result in Domain Admin access.”

The better practices he outlines are the classics for any automation tool:

  • password policy enforcement
  • more security-conscious configuration and development
  • eliminating plaintext credentials on the master

These are fantastic first steps, but they fall short of best practices, especially from an audit and compliance standpoint.

Our technical wizards have been hard at work lately putting together the Ten Factor CI Job.

Beyond these standards, it would also be great to see an iteration of Mittal’s test with Conjur’s orchestration platform providing auditable role-based identity and access management for the CI tool masters, slaves, and teams of users.

Conjur’s Jenkins solution, for example, not only secures all the credentials and keys that otherwise might wind up in source control, our RBAC model allows fine granularity in granting temporary access to jobs and managing privileged access for engineers.

Awareness is always the first step, and for raising it with reference to CI insecurity, we thank Nikhil. Now it’s time to take steps two, three, and beyond…

 

 

Share This