Recovery – TryHackMe Walkthrough

This will be a walkthrough of the weekly challenge “Recovery” from TryHackMe. It was released July 31, 2020.

The Scenario

Hi, it’s me, your friend Alex.

I’m not going to beat around the bush here; I need your help. As you know I work at a company called Recoverysoft. I work on the website side of things, and I setup a Ubuntu web server to run it. Yesterday one of my work colleagues sent me the following email:

Hi Alex,
A recent security vulnerability has been discovered that affects the web server. Could you please run this binary on the server to implement the fix?
Regards
- Teo

Attached was a linux binary called fixutil. As instructed, I ran the binary, and all was good. But this morning, I tried to log into the server via SSH and I received this message:YOU DIDN’T SAY THE MAGIC WORD!YOU DIDN’T SAY THE MAGIC WORD!YOU DIDN’T SAY THE MAGIC WORD!

It turns out that Teo got his mail account hacked, and fixutil was a targeted malware binary specifically built to destroy my webserver!

when I opened the website in my browser I get some crazy nonsense. The webserver files had been encrypted! Before you ask, I don’t have any other backups of the webserver (I know, I know, horrible practice, etc…), I don’t want to tell my boss, he’ll fire me for sure.

Please access the web server and repair all the damage caused by fixutil. You can find the binary in my home directory. Here are my ssh credentials:

Username: alex
Password: madeline

I have setup a control panel to track your progress on port 1337. Access it via your web browser. As you repair the damage, you can refresh the page to receive those “flags” I know you love hoarding.

Good luck!
– Your friend Alex

The Solution

To start, we will attempt to SSH with the given credentials. When doing so, you will see “YOU DIDN’T SAY THE MAGIC WORD!” spamming on the screen. You might remember this from Jurassic Park https://www.youtube.com/watch?v=RfiQYRn7fBg. Another thing you’ll notice is when we terminate this SSH, you see the termination of a while loop.

So there is a file called .bashrc in a user’s profile. .bashrc is a shell script that Bash runs whenever it is started interactively.

We can bypass it a few ways by either running secure shell (sh) or calling bash with the norc flag.

ssh -t username@hostname /bin/sh
ssh -t user@host bash –norc –noprofile

But I went with another way because I was not worried about keeping my .bashrc profile for this challenge

ssh user@host “rm .bashrc”
ssh user@host

At this point, we’ll have Flag 0 which you can check on REMOTEIP:1337.

One thing you’ll notice with the path I chose is that you will get logged out fairly quickly, but that’s fine for now. We’ll figure it out soon. If you look in alex’s home directory, you’ll find a file called “fixutil” which is what the scenario referenced as the malware binary. I copied it over to my Kali instance using scp:

Now, I don’t do too much malware analysis, but I can run strings on it and see if I can get anything. One thing we notice is the while loop being put into the .bashrc file:

We also notice that a root SSH key is added, a new user called “security” is added, and there’s a script called brilliant_script.sh in /opt that is being called by /etc/cron.d/evil. This is being called every minute. We don’t have high enough privileges to do anything about the root SSH key or security user yet, but let’s take a look at that cronjob.

The brilliant_script.sh looks like this:

So, it’s essentially what is killing our sessions >=( . However, we have write access to the file, so let’s stop it from killing our sessions.

What I did was overwrite the script with a “whoami” command that output to a file in my home directory so I could show you that root is what is running the script in the cron.

So not only did we get rid of the code that was kicking us out, we found a privilege escalation vector. Now, I setup a netcat listener and get a reverse shell. From there I change the root password. I can then “su -” in my SSH session and I’m root.

Remote Session
My machine

Now that we’re root, we don’t need the evil script. At this point, we have Flag 1. Then let’s get rid of the security user that was created. This gets us Flag 4. I did not screenshot this 🙂 Lookup how to delete a user or remove the user from /etc/shadow and /etc/passwd.

Let’s get rid of the root ssh key. It’ll be in /root/.ssh/. I just deleted authorized_keys. That gives us Flag 3.

This leaves us with 2 flags left. Let’s take another look at the strings output of fixutil.

As you can see, it moved logging.so to oldliblogging.so. And if you look here, you can see that this is actually the original logging:

So, let’s go back by running this:

This gets us Flag 2 which leaves us with one last flag.

Let’s take a look at this again:

Let’s take a look at the top 3 directories/files.

Well, it looks like the htdocs were encrypted.

And the backup.txt looks like it could be the key. But how do we decrypt?

Well after looking at the fixutil file again, you can see XOR.

So, the next step I took was copy over all the files to my local system.

I then used CyberChef to decrypt the files: https://gchq.github.io/CyberChef/

You can see I used the XOR recipe with the key we got from backup.txt (UTF8) and used it on the files in htdocs. This decrypted the files. I then took the files from the my system and put them back on the remote system.

First, I copied them to Alex’s home folder and then used my root shell to move to the /usr/local/apache2/htdocs/ directory:

This will give us Flag 5. And we’re done. Woot.

Bonus

I went ahead and put the fixutil in ghidra to get the decompiled version of the binary: