Jun 07 · 4 min read
Jenkins is the most widely-used CI/CD tool today. As the world moves from cloud to cloud-native applications powered by Kubernetes, Jenkins still remains highly relevant. It has adapted to the fast-changing tech landscape and is still a vital part of software operations for many organizations. However, Jenkins, as any software, needs to be properly secured to avoid breaches. In this post, we look at the 4 common misconfigurations related to Jenkins and ways to avoid these. Let’s start with some background on Jenkins.
One look at the Jenkins logo and you’d think it’s quite silly in comparison with other tech logos. An elderly man dressed in a tux, seemingly waiting on someone.
Well, that is exactly what the creators of Jenkins had in mind when naming the project and creating this logo. The name ‘Jenkins’ is inspired by a butler, who manages the food and other home duties at large households. In like manner, Jenkins the tool is all about enabling you to get things done better and faster when creating and deploying software.
Jenkins calls itself an ‘open source automation server.’ It is known for its role as a build server, which is a key part of the continuous integration (CI) process. While initially focused on CI, Jenkins has also expanded further downstream to include continuous delivery (CD) capabilities as well. Today, as the world moves to Kubernetes and containers, Jenkins has not waned in popularity. It is still used to control and manage the software supply chain at many organizations, both large and small.
Verkada, a company that manufactures security cameras for industrial and home use, was recently in the news for a security breach that involved Jenkins. Verkada had left their Jenkins servers unsecured and publicly accessible via the internet. These servers had ‘super administrator’ privileges turned on by default, which automatically gave attackers full privileges on those servers. Using these privileges, one security researcher was able to extract the details of 157,000 security cameras and their users’ email ID. The group that revealed this attack showed screenshots of videos they could access. This is an eerie breach of customer trust, and incidents like this can bring an organization down to its knees.
Let’s take a look at 4 security pillars for Jenkins and which misconfiguration to look for related to them.
Top Misconfiguration: The Jenkins Controller can be accessed by agents. The agent can then ask a Controller to do just about anything within the confinement of the operating system, such as accessing files on the Controller or triggering other jobs on Jenkins.
How to avoid it: You can restrict the actions and files an agent can make and/or access on the Jenkins Controller.
Top Misconfiguration: Possible malicious code injection in Jenkins server. Jenkins allows outside users to supply HTML, which could contain malicious code.
How to avoid it: Prevent malicious code injections through HTML by setting a Markup Formatter plugin. This would ensure that users don’t supply malicious cargo code in the HTML they supply (in descriptions of jobs, builds, views, and others).
Top Misconfiguration: Build jobs running on Jenkins Controller which can read or modify files in JENKINS_HOME can impact the entire Jenkins installations and even the ability to create pipelines.
How to avoid it: Configure the master to have no executors, and run builds only on build agents where people who administer Jenkins are different from the people who configure jobs or commit to projects.
Top Misconfiguration: Possible CSRF (Cross-Site Request Forgery) attacks on Jenkins, which force an end-user to execute unwanted actions on Jenkins.
How to avoid it: Configure CSRF protection on Jenkins. This requires that for any actions resulting in modifications, a specific token (called crumb in Jenkins) will be provided so the user it was created for can be identified.
As seen above, there are multiple attack vectors for a Jenkins install. Attackers could gain access using IAM, application code, the Jenkins Controller, or externally via CSRF. There are multiple ways to secure Jenkins CI CD from these attacks. The remedies listed here to keep in mind the type of attack and address them appropriately. There are many other such attacks to keep an eye on. What’s important is to have a security posture that keeps adapting according to changes in attacks.
Security tools that secure applications in production aren’t built for these kinds of tasks. What is needed is a supply chain-aware security solution that understands the different components and players across the entire supply chain. Things like the Jenkins Controller, code coming from known and unknown identities, and builds that violate privileges.
By being aware of the security risks facing Jenkins and leveraging the appropriate security tooling to guard against them, you can bolster your software supply chain. In a world where a company’s reputation can be tarnished with just one incident (hint: SolarWinds) all organizations need to take appropriate actions to secure their software supply chain from these attacks.
Jenkins, DevOps, DevSecOps, CICD Security
What is GitLab GitLab is a free open-source service designed to manage and share code in a distributed version control…
The SolarWinds Attack Was the Industry’s Wakeup Call The new wave of software supply chain attacks that targeted SolarWinds, Codecov,…
Hardly a week goes by these days without hearing about a new supply chain attack. A recent headline featured yet…