Expert: Security Problems Plague Integration ToolsDevelopers Must Lock Down Tools, Pentration Testing Expert Warns at Black Hat Europe
Continuous integration tools, which allow multiple software developers to easily merge, build and test their code, lack strong security controls by default. So says penetration testing expert Nikhil "SamratAshok" Mittal, delivering a Nov. 13 presentation - "Continuous Intrusion: Why CI Tools Are An Attacker's Best Friends" - on the second day of Black Hat Europe in Amsterdam.
He claims that organizations that use continuous integration tools frequently fail to lock them down - and too often make them publicly accessible via the Internet - thus leaving software code at risk of being stolen or modified by anyone with malicious intent.
Continuous integration is a software development practice in which multiple developers have their additions or changes to a body of code - a.k.a. code base - merged together on a regular basis. A number of tools offer these capabilities - Jenkins, CruiseControl and Go are open-source options, while TeamCity and Hudson are commercial CI tools.
But no matter the toolset, many ship with misconfigured or missing security controls, Mittal claims, asserting that all five of the aforementioned tools have these problems in common:
- Minimal security by default;
- Security controls that are common for other tools are missing, such as enforcing complex passwords;
- Even non-admin users can run powerful commands and scripts;
- Credentials and SSH keys are stored insecurely;
- Many of these tools are Internet-accessible, meaning that outsiders could potentially access them.
None of businesses or teams behind those five tools immediately responded to requests for comment on Mittal's research.
As with any other software, individual CI tools may also contain exploitable vulnerabilities that attackers could use to infiltrate a wider enterprise environment. For example, penetration-testing firm Fox Glove Security on Nov. 6 warned that a vulnerability in a Java library in Apache commons-collections, which was first detailed more than nine months ago, remained unpatched. The flaw could be used to remotely exploit any software that uses the library, and one of those vulnerable software applications, Fox Glove Security reported, was the CI tool Jenkins, although the open source project on Nov. 11 released an update that fixes the flaw. Go also reported that its software was vulnerable to the flaw, and released a related update Nov. 9.
The Push For Continuous Integration
The practice of continuous integration grew out of so-called extreme programming, or XP, which debuted in 2006 and supports rapid specification-to-delivery cycles, involving compiling - or building - software on a regular basis, perhaps even multiple times per day.
XP was a notable departure from the dominant development methodology at the time, known as the waterfall model, which advocated specifying all software requirements, building and testing the software to meet all of these requirements, putting it into production and then verifying that the software did everything it was built to do. But the delay between specifying requirements and delivering a build - the entire process might take months or even years - meant that software that was designed in this manner was often outdated before it ever went live. Furthermore, many software teams failed to correctly gather users' requirements and deliver software that users either wanted or found easy to use.
Since the introduction of XP, many practitioners have now embraced so-called agile development practices, which follow many of the same principles as XP. In general, small teams of developers work closely with users to specify software requirements, pick a few of the most important ones and then deliver working software, typically within weeks. From there, the same team will build out the software, adding additional features, functionality and refinements and shipping software updates, perhaps every two to six weeks.
Many agile development teams rely on continuous integration tools. But when used incorrectly, public-facing CI tools - meaning they're accessible by anyone with an Internet connection - can expose everything from admin and database credentials to usernames and SSH keys. "Take the top 10 software developers in the world," Mittal says. "At least four to five of them leak things like this."
One related risk is that an attacker could "enumerate users" - map who has access to the system - as well as access the code-development database and add their own code, for example, to add hidden but malicious capabilities. Likewise, unscrupulous competitors could grab a copy of whatever software is under development, thus putting an organization's intellectual property at risk.
To address the missing or misconfigured security settings that are prevalent in CI tools, Mittal offers multiple recommendations, including:
- Separate "master" project accounts from "slave" - or subset - accounts;
- Restrict access to the privileges that allow build steps to be configured;
- Secure the CI tool administrator dashboard;
- Internet-expose a CI tool only as much as is required;
- Never grant access privileges to anonymous users;
- Enforce complex-password policies.
When it comes to passwords in particular, Mittal says he's found numerous public-facing instances of continuous integration toolsets in which users have set their usernames to be the same as their password. But other CI tool installations lack any authentication controls at all. "Most of the time, CI tools with unauthenticated instances are for game companies - maybe they think this is a game or something," he says.