💾 Archived View for matthewhall.xyz › gemlog › cyborg-writeup.gmi captured on 2023-01-29 at 02:34:18. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
This is a writeup of Cyborg, an easy-rated room on TryHackMe by fieldraccoon.
As always, after letting the server set itself up, I started off with an nmap scan. The below scan will:
nmap -vv -Pn -sC -sV <MACHINE-IP> | tee nmap.txt
There are a fair number of ports here, but the only ones we're interested in are 22 (SSH) and 80 (HTTP). I didn't have any login credentials at this stage, so I started with HTTP.
Let's try going to the ip address in a web browser.
Okay, that wasn't very helpful. Time to enumerate! I like to use gobuster to enumerate website URLs. Here is the command and wordlist I typically start with:
gobuster dir -x php,html -w dirbuster-dirlist-2.3-medium.txt -u <MACHINE-IP>
I usually leave this command running while I try to explore the site manually with a proxy like Burp. A few minutes later I got two interesting results: '/etc' and '/admin'. Navigating to /etc shows a directory with one subdirectory named 'squid'.
Inside of that directory I found two interesting files.
'squid.conf' suggests that the box is running a caching proxy called 'Squid', but other than that it doesn't give us much to work with. 'passwd' contains a password hashed with apr1 for someone/something named 'music_archive'. I threw that into John with rockyou and cracked the hash. The recovered password was 'squidward'. I then tried those credentials to login with SSH, and they didn't work. No problem, I'm sure this will be useful later.
Next I moved on to '/admin'. This had an actual web page, appearing to be the website for some kind of musician. There are two interesting links on this page: '/admin/admin.html' and '/admin/archive.tar'. I downloaded the .tar file to check out later.
Here is what I found at 'admin.html'.
So, the .tar file appears to be some kind of backup. Sure enough, extracting the archive reveals a README file proclaiming that this is a Borg Backup repository. I had never heard of this backup system, so I had to do some searching to learn how to use it. Navigating to the 'final_archive' subdirectory, I ran this command to test the repository:
borg list .
After running the command, I discovered that the backup was password protected. Thankfully, the password was 'squidward', the one I cracked earlier. Success! It showed that the archive was named 'music_archive'. Figuring out how to extract the archive was a bit tricky, but here's how it works: 'borg extract path/to/repository::name_of_archive' is the generic form of the extract command. I created a directory called 'extracted' and navigated to it. Then I ran this command to extract the archive:
borg extract ../home/field/dev/final_archive::music_archive
Looking at the extracted files, it seems we have recovered the home directory of a user called 'alex'. Unfortunately for 'alex', they left their unencrypted password in 'home/alex/Documents/note.txt'. Sure enough, I was able to login with SSH with the username 'alex' and the password 'S3cretP@s3'. The user flag was kept in '/home/alex/user.txt'.
Now for the root flag. My usual first step for thhings like this is to try 'sudo -l' to see what I might be able to do.
Here's what I found from that.
It seems we have root permissions to run the script '/etc/mp3backups/backup.sh' without a password. Let's try running it and see what happens.
Apparently the script couldn't find the files to backup? Let's take a look at that '/home/alex/Music' directory...
Okay, so the files are named like images even though they're actually audio? Why?? Whatever. There's no problem you can't fix with regular expressions:
rename -v "s/image(\d+)\.mp3/song\$1.mp3/" ./*
With the files renamed, the backup script no longer throws error messages. The next thing I turned my attention to was the bottom of the file:
cmd=$($command) echo $cmd
I started trying to inject some shell code through the $command variable by setting it before running the script. Unfortunately, I was foiled by the way bash handles environment variables. Because I was running the script as root, the variables I set as alex didn't carry over into the script. Additionally, trying to set the variable inline with the call to the script gave me a permission error.
If you didn't see it already, go back and look at my screenshot of the 'sudo -l' output. Also included in that screenshot is the directly listing for '/etc/mp3backup'.
Can you see it? Because I didn't at first, hence why I wasted a bunch of time on the stuff described above.
The backup script has permission settings 554, meaning there is no write access. However, it is also owned by the alex user. Because I am the alex user, I can set the permission settings of the script to whatever I want. This means I can just give myself write access and change the script to whatever I want. My forehead is still red from how hard I face-palmed.
One chmod 777 later, I added '/bin/sh -i' to the end of the script and ran it through sudo. Sure enough I got my root shell. The root flag was located in '/root/root.txt'.
If this was real, I would say there are many security issues with this box. I won't be going too in-depth because these are all fairly simple to fix.
As for me personally, I learned a little about Borg Backup and how it works. Additionally, I thought that my root-access solution was a bit strange, so I looked up another writeup and found one by the creator of the room, fieldraccoon. Apparently, the intended solution was to just pass the follwing shell commands as script arguments:
By giving bash the suid bit, you can just spawn a root shell with '/bin/bash -s'. I missed all of this because I didn't bother to read and understand the part of the script that parses arguments. So the big lesson for me was to make sure I've read everything. Maybe I'll learn it someday. :)
