Why compromised Jenkins can lead to a disaster?

I was recently searching for something on Google and came across this instance of what might be a logical vulnerability prevailing across multiple web applications. I was searching for publicly accessible Jenkins console through Google Dorking. My search query listed some of the websites that had Jenkins as a part of their domain name. Although this itself is not a security issue but it reveals the fact that Jenkins is being used as a CI (Continous Integration) tool and it’s console is publicly accessible. The following information may be used to plan a chain of attacks.

What took me by surprise is that I found many Jenkins console with no authentication mechanism enabled on them. I can easily open the console, read the usernames, the build history, logs of builds and much more. This made me think about the necessity of having proper security implemented on a Jenkins console. So, this blog post will be covering the devastating effect of a compromised Jenkins server and how to protect this from happening.

Why compromised Jenkins can lead to a disaster?

• Treasure of credentials such as AWS Access keys and Secret key.
  Impact: Anyone can use the AWS account linked to the Access keys and Secret keys to launch resources which will lead to the owner getting billed for it. A person possessing these credentials gets full access to the AWS account
• The server’s pem files, IP addresses, usernames, email address etc.
  Impact: The disclosure of the above mentioned information will lead to logging into the server (remember there may be a hundred of servers accessible from this console), running arbitrary commands on it, getting access to users and their respective password ( and what not! ).
  The revealed username and email address will also enable the attacker to plan much more sophisticated attacks on the organization as he is now much more aware of the developer and other accounts that are present. This can also result in him brute forcing other applications such as the Admin, CMS portal of the application.
• GitHub SSH Key
  SSH keys are used to identify trusted computers, without involving passwords. Since, Jenkins has availability of Git plugin which enables us to run Git commands from the Jenkins console itself. So, the publicly accessible Jenkins console will enable an attacker to view, modify, update the code of the production application. In the worst scenario possible, the attacker can issue a “git branch -m production” command and delete all the existing code and thus bring the application down by deleting the “production” branch containing the code of the application.
• S3 Bucket
  The Jenkins console might have access to private S3 buckets containing content such as images, log files, code backups etc. This access to essential data can be abused to delete important files and folders.

Best Practices to follow

By default, Jenkins has no security check enabled. The Jenkins console can be accessed by anyone who has the URL and can configure Jenkins, create and edit jobs and perform builds. This can be safeguard by adding two layers of protection:

• Making Jenkins URL accessible only from the trustable IP addresses.
• Enabling Authentication in Jenkins console using Acess Control.

• To further enhance security, we must select Authorization under the Access Control option. Enabling “Project-based Matrix Authorization Strategy” will ensure that we are granting required access only to the users who are eligible for it. This also enables us to provide access based on Projects.

For detailed steps to enable the above-mentioned security settings, follow the following blog:
Jenkins – Implementing Project-based Matrix Authorization Strategy

• Enable option “Prevent Cross Site Request Forgery exploits” and use “crumbs” to defend Jenkins against CSRF attacks.
  

The reason why CSRF Protection is not enabled by default is that some Jenkins APIs are difficult to use when this option enabled. Some features may not work at all. Some reverse proxies may filter the “crumb” parameter, resulting in failures when trying to use certain actions.

So, a compromised Jenkins server can cause loss of control over complete infrastructure and resources.