Secure Jenkins for fast and safe app delivery

Enterprises evaluating a migration to Jenkins continuous integration for quick and agile software development should keep security in the forefront of their decision.

Continuous integration has taken the IT world by storm, as Jenkins and other tools enable quicker turnaround on code releases. But danger could lurk on the horizon if IT shops do not secure Jenkins.

Continuous integration (CI) enables instantaneous testing of code prior to deployment in production environments, among other advantageous capabilities for developers, testers and IT engineers. Without continuous integration, moving code updates to production is a tedious process, as developers submit their code to a repository, oblivious to other changes that occurred while they diligently worked on their piece. This out-of-sync development results in numerous errors and miscommunications.

The Jenkins project combats all such confusion. To be cross-platform, the open source software associated with the Jenkins project was written in Java. Several major corporations such as Mozilla and IT firms such as Cardinal Solutions have come to rely heavily on the Jenkins framework.

Before Jenkins or another CI framework becomes a vital part of the enterprise's development environments, the question should be answered: Where are the Jenkins vulnerabilities?

Start talking about SSH

A conventional enterprise deployment uses a master/slave configuration of nodes connected to the Jenkins framework. The Jenkins server or cluster of servers responsible for testing all code submissions is considered the master and all connected nodes, usually development machines, are considered slaves. Secure socket shell (SSH) is a popular way to connect the master server to a slave. This can be done via username and password, SSH private keys, or certificates in Jenkins' SSH credentials plug-in.

SSH connections are considered secure since they can work with a number of encryption mechanisms, such as American Encryption Standard, Blowfish and Triple DES. To secure Jenkins, however, the login credentials for SSH must only be known by appropriate users. Even if access control is tight, SSH-based security assumes that a given enterprise network is impervious to insider attacks.

The master/slave configuration is great for convenience and agility. However, Jenkins networks are easily configured so that trust between master and slave nodes is almost 100%. Slaves are authorized to do anything on the master server that the master server is capable of doing, limited only by the underlying operating system of the master server. If the master server contains sensitive data, or if it is trusted by other sensitive servers, nefarious individuals with SSH access could seriously manipulate enterprise source code.

Groovy's hidden vulnerability

The Groovy shell is the command-line interface for the Jenkins framework. Similar to bash, found in most Linux distributions, Groovy offers a powerful way for administrators to interact with Jenkins nodes. When the administrators need Groovy shell access remotely, it's only natural to use SSH. However, a vulnerability revolves around the Groovy shell.

A nefarious user can use the Groovy shell, with proper privileges, and steal user information, according to a white paper published by the SANS Institute, a cooperative research and education organization for security and related professionals. The user runs the following command (among others):

"cat /etc/passwd".execute().text

The aforementioned command creates a text file that receives a dump of the /etc/passwd file. This file contains general information about each user, useful for malicious actions.

Recommendations to secure Jenkins

To better secure Jenkins in an enterprise implementation, the SANS Institute suggests that IT shops disable the SSH daemon (SSHD) if possible. Instead, utilize the web service with Secure Sockets Layer enabled. This will render the Jenkins vulnerabilities discussed in this article null. If the SSHD is absolutely necessary, then the institute's experts further recommend that the daemon be configured with a known port, so that firewalls can whitelist known IPs, making Jenkins more secure.

Second, SANS recommends that Jenkins never run on root or administrator privileges. That way, attackers who successfully infiltrate the network via a Jenkins account will still have to work on a privilege escalation to carry out more serious attacks.

Third, remove accounts associated with Jenkins from the sudoers file, which stores information about which users can run which commands on what machines. This will go a long way toward preventing privilege escalation by attackers. When a user is not in the sudoers file, that user lacks administrative access. Less access means a more secure Jenkins deployment.

Next Steps

Learn how to retain your organization's talented security staff

Creating a good IT security policy

Teamwork needed for IT security

Dig Deeper on IT Ops Implications of Continuous Delivery