# TryHackMe Writeup - Cyborg

This is a writeup of Cyborg, an easy-rated room on TryHackMe by fieldraccoon.

=> https://tryhackme.com/room/cyborgt8 Here is a link to the room.

## Exploration

### nmap

As always, after letting the server set itself up, I started off with an nmap scan. The below scan will:

* use the maximum verbosity level
* skip the host discovery stage (we a;ready know what we're attacking)
* run NSE scripts in the 'default' category
* scan the 1,000 most common ports
* probe open ports to determine service information

``` nmap command
nmap -vv -Pn -sC -sV <MACHINE-IP> | tee nmap.txt
```

=> img/cyborg-writeup-1.png Here are my scan results.

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.

### Web enmueration

=> img/cyborg-writeup-2.png 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 command
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'.

=> img/cyborg-writeup-3.png 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.

=> img/cyborg-writeup-4.png Here is what I found at 'admin.html'.

## Initial Access

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 test command
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 archive extraction command
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'.

## Privesc

### The script

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.

=> img/cyborg-writeup-5.png 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.

=> img/cyborg-writeup-6.png Here's what happens.

Apparently the script couldn't find the files to backup? Let's take a look at that '/home/alex/Music' directory...

=> img/cyborg-writeup-7.png ...are you kidding me?

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:

``` renaming mp3 files
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.

### What I missed + root flag

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'.

## So, what did we learn?

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.

* The 'etc' web directory should not be accessable, and the 'admin' web directory should be behind some sort of authorization.
* Given that 'admin' was publicly accessable, at least the admin chat/message logs and backup archive should not be sitting in the open.
* The two passwords could be much stronger. 'S3cretP@s3' isn't too bad, but there are probably rulesets out there that could guess it. 'squidward' is not an acceptable password at all, as it is in the rockyou wordlist.
* Additionally, PASSWORDS SHOULD NEVER NEVER NEVER BE WRITTEN DOWN IN PLAINTEXT AND SAVED TO DISK SERIOUSLY PEOPLE WHY
* SSH password logins should probably be disabled, unless there is a good reason that key-based authentication cannot be used, in which case user passwords MUST be stronger than they currently are.
* The backup script has no reason to have the last two lines I pointed out in it.
* Additionally, the backup script should be owned only by thr root user. It would be more secure than granting root access to a non-admin to run the commands in the script.

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:

* sudo /etc/mp3backups/backup.sh -c whoami # (this one isn't needed, obviously)
* sudo /etc/mp3backups/backup.sh -c "chmod +s /bin/bash"

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. :)

=> https://fieldraccoon.github.io/posts/Cyborg/ Read fieldraccoon's writeup.

=> /gemlog/ Back to gemlog home
=> / Back to capsule home