Continuous integration tools can be the Achilles’ heel for a company’s IT security

Some of the most popular automated software building and testing tools used by developers have not been designed with security in mind and can open the door for attackers to compromise enterprise networks.

These so-called CI (continuous integration) tools allow developers to automatically create software builds when code changes are contributed by developers to a central repository. The creation of these builds, which are used for quality control, is coordinated by a CI master server based on predefined rules and done on CI slave machines.

If hackers manage to access a CI master server, they can steal proprietary source code, but also gain the ability to execute commands on all the machines that operate as CI slaves, security researcher and penetration tester Nikhil Mittal said Friday in a presentation at the Black Hat Europe security conference in Amsterdam. “This access could be used for lateral movement to get access to more machines.”

In fact, Mittal said that he has never seen a penetration test so far where unauthorized access to a CI tool didn’t result in administrative access to the whole network domain.

That’s because most CI tools are insecure in their default configuration and certain user roles allow the execution of PowerShell commands and scripts with system privileges. Chances are high that the token for a domain administrator can be found in a process running on one of the CI slave machines.

Mittal tested three open-source CI tools called Jenkins, CruiseControl and Go and two proprietary ones called TeamCity and Hudson. He found default insecure configurations and exploitable features in all of them.

He demonstrated several attacks that could result in command execution on underlying machines, the opening of reverse shells and the theft of sensitive data like database and Git credentials, SSH keys and more.

The researcher found many instances of CI server deployments that are directly accessible from the Internet and do not even require authentication.

Out of the top ten software development companies in the world, at least 5 had such services exposed, he said.

As common problems across all tested CI tools, Mittal found: minimal security in default configurations, missing security controls like brute-force protection, the ability to run commands and scripts on the OS by non-administrative users, the ability to remove all security measures if a build agent is running on the master server, insecure storage of credentials and SSH keys and unauthenticated remote access.

In order to protect these systems, the researcher recommended that no build executor should ever run on the master CI server, restricting the user privileges who can configure build steps, securing the admin dashboard, not exposing the CI tool to the Internet unless absolutely necessary, not providing read privileges to anonymous users, and preventing users from using their usernames as passwords.