Disclaimer: We would use only existing features of Jenkins, no 'exploits' here.
During a recent penetration test I came across a Jenkins server. Having written a blog post on it, I was really excited and jumped straight to the /script url for the Groovy script console. But, it redirected me to a login page. Bummer!
Anyway, I registered as a user (yes it was allowed), and then tried to go the script console, but (all screenshots from my test machine)
After that, I put the initial excitement aside and started to explore whatever was available and read Jenkins documentation . Some interesting links are given below. All of these are publicly/anonymously accessible in Jenkins Standard Security Setup detailed here :
List of users:
http://[jenkinsurl]/asynchPeople/
List of all builds:
http://[jenkinsurl]/view/All/builds
(Seems to be fixed in the latest version 1.575)
List publilcy available content :
http://[jenkinsurl]/userContent/
Type of the Operating System:
http://[jenkinsurl]/computer/
It turned out that in Standard Security Setup, a registered user and anonymous user have same privileges unless otherwise configured.
During the pen test, I found links to couple of repositories in build details (console outputs) which were a treasure trove. but nothing on the Jenkins server itself. It be noted here that I was unable to see the build details on my test machine which is the latest version.
Anyway, the list of available users got my attention. From my experience working in the industry, I almost knew there would be some easy passwords as developers and build management guys are not really good at passwords :P
I quickly ran a brute force on all the listed users using Burp and 500 worst passwords list from Skullsecurity . I ran it on POST request to /j_acegi_security_check. If you use Burp intruder, make sure it is configured to follow redirects.
No points for guessing, I got password for a user. Yay! Login and jump to the script console but
Few minutes later, I got password for two more users but none had access to the script console. Aaargghhh!
After further exploring Jenkins console, I saw that one of the users could configure build jobs (could not create new ones) and there are couple of very interesting things in the "AddBuild Step" option:
I added a small script, saved the configuration and built the task. Recall that we can get the OS type using http://[jenkinsurl]/computer/
But, damn it:
The script didn't execute. There had to be a way out! I called up my elder brother (he is on twitter , follow him!) who is a veteran in configuration and build management. He suggested me to see if there is any task running before the "Execute Shell" build step and is failing. There was one indeed.
He further suggested if I could re-order the build steps. Quick
duck
search returned a way, I just need to drag my Build Step to top, save and build. Aaand, finally!
Now, you can try getting a meterpreter session using built-in perl, python, ruby etc. And if it is a windows machine use powershell for various attacks as mentioned in my
earlier post
. Note that unlike script console we need not use Groovy script if we use the build step.
If you want to get admin access to Jenkins, read on. As per, Jenkins documentation here , you can disable security by setting the [useSecurity]true[/useSecurity] to false in config.xml in $JENKINS_HOME or by deleting the config,xml.
Lets check for $JENKINS_HOME, we use "ps -ef | grep jenkins" in the Shell Execute step.
Now lets see if we can delete config.xml
Save, build and refresh. Bingo! Admin access for everyone!
UPDATE:
Deleting config.xml is absolutely not required. You could always run a sed command to replace [useSecurity]true[/useSecurity] with [useSecurity]false[/useSecurity] for same results.
During a recent penetration test I came across a Jenkins server. Having written a blog post on it, I was really excited and jumped straight to the /script url for the Groovy script console. But, it redirected me to a login page. Bummer!
Anyway, I registered as a user (yes it was allowed), and then tried to go the script console, but (all screenshots from my test machine)
After that, I put the initial excitement aside and started to explore whatever was available and read Jenkins documentation . Some interesting links are given below. All of these are publicly/anonymously accessible in Jenkins Standard Security Setup detailed here :
List of users:
http://[jenkinsurl]/asynchPeople/
List of all builds:
http://[jenkinsurl]/view/All/builds
(Seems to be fixed in the latest version 1.575)
List publilcy available content :
http://[jenkinsurl]/userContent/
Type of the Operating System:
http://[jenkinsurl]/computer/
It turned out that in Standard Security Setup, a registered user and anonymous user have same privileges unless otherwise configured.
During the pen test, I found links to couple of repositories in build details (console outputs) which were a treasure trove. but nothing on the Jenkins server itself. It be noted here that I was unable to see the build details on my test machine which is the latest version.
Anyway, the list of available users got my attention. From my experience working in the industry, I almost knew there would be some easy passwords as developers and build management guys are not really good at passwords :P
I quickly ran a brute force on all the listed users using Burp and 500 worst passwords list from Skullsecurity . I ran it on POST request to /j_acegi_security_check. If you use Burp intruder, make sure it is configured to follow redirects.
No points for guessing, I got password for a user. Yay! Login and jump to the script console but
Few minutes later, I got password for two more users but none had access to the script console. Aaargghhh!
After further exploring Jenkins console, I saw that one of the users could configure build jobs (could not create new ones) and there are couple of very interesting things in the "AddBuild Step" option:
I added a small script, saved the configuration and built the task. Recall that we can get the OS type using http://[jenkinsurl]/computer/
The script didn't execute. There had to be a way out! I called up my elder brother (he is on twitter , follow him!) who is a veteran in configuration and build management. He suggested me to see if there is any task running before the "Execute Shell" build step and is failing. There was one indeed.
If you want to get admin access to Jenkins, read on. As per, Jenkins documentation here , you can disable security by setting the [useSecurity]true[/useSecurity] to false in config.xml in $JENKINS_HOME or by deleting the config,xml.
Lets check for $JENKINS_HOME, we use "ps -ef | grep jenkins" in the Shell Execute step.
