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
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:
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/initialAdminPasswordAn 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:
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 -> vipsuThe 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:
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
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:
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:
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:
