HTB - Jewel
Zweilosec's writeup on the medium-difficulty Linux machine Jewel from https://hackthebox.eu
Overview
Short description to include any strange things to be dealt with
TODO: finish writeup and clean up
Useful Skills and Tools
Execute a shell script payload without writing to disk
that extra (
-) is important, don't leave it out!
Useful thing 2
description with generic example
Enumeration
Nmap scan
I started my enumeration with an nmap scan of 10.10.10.211. The options I regularly use are: -p-, which is a shortcut which tells nmap to scan all ports, -sC is the equivalent to --script=default and runs a collection of nmap enumeration scripts against the target, -sV does a service scan, and -oA <name> saves the output with a filename of <name>.
My nmap scan found only three open ports: 22 -SSH, 8000 - HTTP, and 8080 - HTTP.
Port 8080 - HTTP
On the site hosted on port 8080 I found a "Bl0g" site. While looking through the articles I found two potential usernames bill and jennifer.
created an account, then logged in.
On the profile page saw a 'edit profile' link and was hoping for a image upload box, but there wasn't anything useful as I could only update the username.
Port 8000 - HTTP
On the web server hosted on port 8000 I found a git page for the "Bl0g".
file tree
The file Gemfile contained version information for all of the source files for the project, including the version of the Ruby on Rails Framework.
in the git code I found a couple of password hashes, in the file bd.sql
I downloaded the git code for the site by clicking on the snapshot link. I opened the SQL database locally but didn't find anything more that seemed useful in it, or in the rest of the code files.
This also includes email addresses for the users with a domain of mail.htb.
While looking up version numbers for everything, I found an exploit for this version of git, but it looked to only work on Windows.
Back in the code in the Gemfile I had found version numbers for rails 5.2.2.1. After searching for vulnerabilities for this version I found multiple CVEs that were related:
I tried searching for exploits related to each CVE and came up with a POC for CVE-2020-8165.
On cvebase there were eight POCs listed for this CVE which looked like a winner! I selected the one with the most upvotes which took me to a GitHub page.
The instructions looked simple enough to follow, but I did not have rails installed, so I did that first. Next, I created a new project called test. (Had to change the name to testing, since 'test' is apparently a ruby/rails reserved key word.)
After installing rails and starting my new project I got an error message saying some of the dependencies were not installed, so I had to run the bundle install command to install those as well. There was a long list of things it installed.
I had a lot of dependency issues, from yarn, webpacker, rails, and more...
I had to do the above steps to resolve the webpacker issues I was receiving. For some reason the gem version of yarn was causing problems, so I had to remove it and install it through npm.
After installing all of the dependencies I was able to start the rails console.
After all of that work, it was pretty easy to follow the instructions in the POC to create the payload.
captured request to change the username on the 'edit profile' page in burp, then added my payload in place of the username field
On the exit profile page, got an error message after sending my payload in place of the username field, but the payload still executed.
Initial Foothold
After sending my payload and sending another GET request for the profile page I got a connection back at my waiting netcat listener. I used the program script to save a transcript of all commands that I was about to run in the netcat shell, and made sure my listener was running in bash rather than zsh, since the latter causes issues when setting stty raw -echo when upgrading shells.
Upgraded my shell so I could use ctrl-c, arrow keys for history, etc.
I was logged in a bill, no special groups
There was a few interesting hidden files in bill's home folder, including one called .google_authenticator.
User.txt
I was happy to see that bill had the user.txt flag in his home directory!
Path to Power (Gaining Administrator Access)
Enumeration as bill
billlinpeas pointed out that there were a couple of files with password hashes. The second one was one that I had tried to crack unsuccessfully before, but the other was new. Since it was in a backups folder, it was possible that this was an old password that was used elsewhere
I copied the backup SQL file to my local machine and opened it up. There were a couple of new hashes in it, which I loaded into hashcat to try to crack.
For some reason hashcat could not identify the backup hashes as a valid bcrypt hash, but john was able to crack one of them almost immediately.
I checked /etc/passwd to see if there were any other users, but only bill, postgres, and root could log in.
It password ended up belonging to bill. I tried using sudo -l again now that I had a password, but it asked for a verification code. This seemed like it may have been related to the .google-authenticator file I saw in bill's home folder.
Run the google-authenticator binary to create a new secret key in your home directory. These settings will be stored in ~/.google_authenticator.
I was unable to setup a new google authenticator (and somebody likes monty Python...)
The easiest way to generate codes is with oath-tool. It is available in the oath-toolkit package, and can be used as follows:
oathtool --totp -b ABC123Where ABC123 is the secret key.
After installing oathtool and trying to generate totp using the code I had found, I noticed that the machine's time was GMT, and my system was not. This was causing my attempts to verify the OTP to fail.
After setting my system to GMT I got a different sort of error. The time between the two machines was still off by a few minutes, which may have been still causing problems. I searched for ways to sync the times between the two machines
Unfortunately it seems not only are the time zones different, but the format of the date/time was different which made it so I couldn't sync automatically by using SSH.
After playing around with matching the times, I realized that the time zone, and date were wrong.
NOTE: There's also this option in Ubuntu 14.04 and higher with a single command (source: Ask Ubuntu - setting timezone from terminal):
$ sudo timedatectl set-timezone Etc/GMT-6...you should be using a fully named time zone like America/New_York or Europe/London or whatever is appropriate for your location...
After getting the time synced, I was able to check the results of sudo -l finally:
After all of that trouble getting the OTP, I was glad to see there was a result! Next, I searched for a way to do privilege escalation using sudo gem and found a post on GTFObins on how to do this.
This requires the name of an installed gem to be provided (rdoc is usually installed).
gem open -e "/bin/sh -c /bin/sh" rdoc
Getting a root shell
I ran the command from GTFObins with sudo and it immediately gave me a root shell. It seemed to me that if I had been able to read the sudoers file I could have bypassed all of that trouble with OTPs. I wasn't sure why one wasn't required to run the command, unless I was still authenticated. I logged back out to test this.
I had forgotten to check this file earlier, but I was somewhat relieved that all of the pain that it took to sync the date and time wasn't in vain.
I was correct. There was a window in which I was able to enter commands with sudo without re-authenticating.
Root.txt
After that I collected my hard-earned proof, then set my clock back to normal!
Thanks to <box_creator> for something interesting or useful about this machine.
If you like this content and would like to see more, please consider buying me a coffee!
Last updated
Was this helpful?