CTF: Jarbas 1 – vulnhub CTF walkthrough

VM: Jarbas 1
Author: Tiago Tavares (vulnhub) @tiagotvrs (twitter)
Series: Jarbas
Difficulty: Beginner/Intermediate
Privilege Escalation: Beginner/Intermediate*
Target IP: 192.168.1.112

This is a walkthrough on the CTF called Jarbas uploaded to vulnhub. *I’m not sure whether this is to be classified as Intermediate or beginner but it has its own twist on the way of getting a shell due to the lack of nc on the target (probably it’s a bit more into the beginner category).
So let’s begin.

Enumeration

nmap scan on Jarbas - vulnhub CTF walkthrough - d7x - PromiseLabs - blog
# nmap -sT -sV –top-ports 1000 -O 192.168.1.112

The target is running a ssh, httpd, mysql and jetty services. I wasn’t quite familiar with what actually Jetty is until I began further enumeration on this host. The web page on port 80 is some kind of an archived search engine pointing to external links on web.archive.org.  The ssh daemon returned the string “SSH-2.0-OpenSSH_7.4” which isn’t quite of help trying to enumerate the exact target OS.


The fields on the web page are pointing to an external page. Trying to “fix” the links using local filenames didn’t do anything and reviewing the source code on the page didn’t bring anything of value to my attention.
The MySQL service running on the target seems to be accessible, however connecting to it returns a denied response:

I wrote down the string “Jarbas” as a possible username while enumerating the target further. The daemon on port 8080 was actually Jenkins, some kind of java-driven http application, or by stated by the authors, “Jenkins is an open source automation server written in Java. 
It requires a username and password, and the only thing I found interesting on this page was a snippet within the source that contained some kind of hash, which was always the same and static:
f809754d72ab3fbd4f547af426eb0ee6 – an interesting hash within the Jenkins Java application


This wasn’t actually of any use in this CTF but it was an interesting spot. Any default credentials wouldn’t work, but while learning more about the Jenkins application I found out that the default username is admin and the password is actually stored in the following file:
.jenkins/secrets/initialAdminPassword
An LFI would serve great as an entry point so far, however this wasn’t the case.

Step #1: Getting an entry point

After struggling a bit with the web application on port 80 written in Portuguese and after a few tries with dirb didnt get anything interesting until I included the .html extension. The inputs on the web page didn’t target a local page as explained earlier, and swapping them with local filenames would return a 404. dirb however, returned an interesting result:
Jarbas vulnhub CTF walkthrough - d7x - PromiseLabs blog
access.html – an interesting file on target Jarbas

The contents of access.html actually contain some hashes, which are next to be tried both on the ssh daemon and the Jenkins java application:

Pasting the hashes on google returned their password equivalents right out of the box (didn’t even have to crack them):
tiago:5978a63b4654c73c60fa24f836386d87 -> italia99
trindade:f463f63616cb3f1e81ce46b39f882fd5 -> marianna
eder:9b38e2b1e8b12f426b0d208a7ab6cb98 -> vipsu
The next I did was try all the credentials on the Jenkins web application as well as connect to ssh using either of them. The last one was a match on Jenkins, and feeling a bit disappointed with the fact that neither of them worked on the ssh daemon I created a username and password wordlists to try all the matches with hydra. No login was granted within ssh, however the Jenkins access served as a great entry point:  
Jenkins web interface

Getting the Jenkins java app to execute commands is actually rather easy: 1 ) Go to New item and enter a project name (like “shell”) 2) Choose the project type (I chose Freestyle project) 3) Click OK 4) On the next page, there’s a dropdown menu under the “build” section. Choose “Execute shell”  and you will be able to to type shell commands. As a start I tried an nc backpipe however as it wasn’t successful I wrote the following script to enumerate the target and see what applications are actually available:
#!/bin/bash
cat /etc/passwd
ls /bin
ls /usr/bin
uname -a
Executing a shell on Jenkins
5) Click save, and then “Build now” on the left menu:
Building an execute shell app in Jenkins
A note stating “Build scheduled” should appear, and then a link to the new task status at the bottom left, below the menu. After clicking on the link there will be some options shown regarding the particular build. Click “Console output” and you will see the output of the shell script:  
Console output in Jenkins – showing the output of our script

Step #2: Getting a shell

As nc is missing from the target and there aren’t communication prerequisites found on the target (or at least I couldn’t find some) I found myself in a bit of a twist during CTF. So Jenkins grants the ability to execute a shells script, however  it seems to be missing the option to upload files (or may be I just was too lazy to research it), so how do we get the server to run any payload? My solution was to create a payload using msfvenom, then base64 its binary contents and echo the base64 decoded string to a file.  (At the time of this writing I actually found out there’s also python available on the server so this would be another option to get a shell, but I’ll follow down on the method I used and for the sake of the exercise)   And then, writing the base64 decoded string to a file on the server: And now the only thing left is to spawn a listener, and then build the application:
Getting a shell on target Jarbas using an msfvenom x64 payload

Step #3: Privilege Escalation

Privilege escalation on this box is rather easy.  There’s a cron script running as root with global file permissions. As the shell is spawned with user jenkins the easiest and quickest way for me was to add jenkins to the sudoers group:
/etc/script/CleaningScript.sh has insecure permissions and is running as root
Getting root privileges on Jarbas
(yeah, I accidently wiped the /etc/sudoers contents so the sudo su command was not working anymore for some reason) And getting the flag:
/root/flag.txt