- Tested Versions
- Tested Operating Systems
- More info about Jenkins
- More Resources
Jenkins (continuous intergration server) default install allows for unauthenticated access to the API on the Jenkins Master Server (default behavour). Allowing unauthenticated access to the groovy script console, allowing an attacker to execute shell commands and / or connect back with a reverse shell.
Disclaimer, I didn't discover this exploit, it has been discovered before... This vulnerability has been disclosed before to the Jenkins CI developers, who do not consider it a vulnerability.
Tested Operating Systems
An effort to test all affected OS’s, showing the severity of the exploit (e.g. jenkins shell) for the default OS packaged version.
|Operating System||Default Package Expoit|
shell as user jenkins
This is really basic, I made a few small groovy scripts to execute the shell commands I wanted via Jenkins API (I recall having some issues runing more than one command at a time via groovy), I then executed them using Curl.
groovy script wget shell
Script to wget perl reverse shell to target and copy it to /tmp/shell.
Jenkins requires /tmp to have exec perms
By default Jenkins requires
/tmp to have the execute mount option set, so you should be safe to land shells there on Jenkins servers.
groovy script execute shell command
Execute the Groovy Scripts via scriptText Jenkins API
Jenkins Does Not Consider this a Vulnerability
Dispite the fact the web application is insecure by default (the default install leaves the API and webapp exposed without authentication), Jenkins do not consider this a vulnerability. Your best option is to configure authentication by following the Securing Jenkinsi Guide
More info about Jenkins
Jenkins is a tool consisting of a master and a slave, the master server schedules and runs jobs for the jenkins slaves to execute. The default installation configures the master as a slave server, allowing anyone with access to the Jenkins master to execute arbitrary code on the master (via the slave).
A more secure solution would be isolating the role of the master server. Currently if a Jenkins master server is compromised, it’s likely an attacker will also be able to execute jobs / run shell scripts on the Jenkins slaves.
An additional ACL option within Matrix-based security to disable API, and another for script console / execution on the Jenkins Master would be a good idea. Currently the only options is to disable all script access for the user/group, which appears to include the slaves.
Be mindful of the fact that, by giving access to the slaves via the Jenkins Master, you’re essentially giving the user shell level access to the slave (or at least the ability to execute shell commands on the slave machine).
More links about this vuln and similar Jenkins vulns below: