Is Your Jenkins Server Exposed to the Web?
Jenkins is a very popular open source server. DevOps teams use it to build, test and deploy apps running in cloud environments. This post shines a light on a serious security concern which is common but yet doesn’t get enough attention – Jenkins exposures to the web.
In fact, on average, Reposify’s platform detects over eighty thousand exposed Jenkins servers every month. A Jenkins server which is exposed to the internet often means that there is some kind of a misconfiguration in the credentials and privilege setup. In some cases, the Jenkins server is exposed to the web by design. This is mostly true for companies that have open source products. But in all other cases, Jenkins should not be exposed to the internet.
What are the main risks associated with the exposure of Jenkins Servers?
Since Jenkins is most commonly used to deploy apps and to run pull requests, it typically contains sensitive information like source codes and development ticket information.
Leaving your Jenkins server exposed to the internet can result in several things:
- Information of all sorts can leak. For example, SSH private keys, private source code repositories and access tokens.
- Hackers can use this as an entry point and perform lateral movement in internal networks and gain access to production environments.
These are the 4 most common types of misconfigurations which result in a risky exposure:
- The login panel is left exposed instead of being placed behind a VPN. This is not terrible but definitely not recommended as attackers will try to brute force the login and in some cases may actually succeed.
- The login allows for ‘self-registration’ which grants guest users access to the server. This means that anyone that happens to find the login page, can simply sign in and gain access.
- Often Jenkins will be placed behind an SSO login which is linked to a Github account. In some cases, instead of being restricted to specific users, it is misconfigured to allow any Github account to login.
- There is no login whatsoever and the server is completely open to the internet with guest or admin permissions by default. This is a big no no.
The Battle of Agility vs. Compliance:
Often developers will look for simple ways to quickly access such servers from anywhere. This leads to creating shortcuts and bypassing security policies. There is always an inherent tension between the desired ease of use vs. the need to secure your assets. For developers – ease of use typically matters more and especially now, when teams are working remotely.
How Do IT and Security Teams Discover Such Cases Of Non-Compliance?
Often, they don’t until it is too late. There is a visibility challenge which is a major barrier for discovering such exposures. This results from 2 main reasons.
First, such exposures can happen at any given moment while network scans are typically performed periodically, so this can be easily missed.
Another reason is that Jenkins servers often run on non-production environments which IT and security teams are unaware of. Therefore, such exposures will be completely off radar and will not be covered by the traditional network scanners.
5 Tips for avoiding exposure of Jenkins servers to the internet
If your DevOps team is running Jenkins servers in their cloud or on-prem environments, there are several simple steps that you can take:
- Disable self-registration
- A second best practice is to use SSO authentication rather than basic authentication
- When connecting remotely, only allow access to the server via VPN
- Use zero executors on master to prevent attackers from stealing sensitive information
- Don’t forget to disable the auto-discovery protocol if you do not use it. This will prevent attackers that managed to enter the network from finding the server.
In conclusion, continuous integration tools are connected to the company’s code base and repositories and therefore, can become a weak point in the company’s attack surface and a lucrative target for attackers. While in this blog post we focus on Jenkins, it is important to note that similar misconfigurations are common across many continuous integration tools (e.g. TeamCity, GitLab CI, Bamboo and others).
No matter which tool your team is using, the above mentioned tips are a good starting point for improving the cybersecurity hygiene of every development and DevOps teams.