CTF — Hacker101 — TempImage

Ravid Mazon
CyberX
4 min readApr 10, 2020

--

I enjoyed TempImage a lot, as it made me learn something that I didn't know before— Injecting shellcode to an image, uploading it to a web server, execute the shell (the code inside the image) and connect to the server.

But first things first, let's start with the first flag.

FLAG0

First, I tried to upload any file and got an error, noticed that the format that was supported was and PNG image file.

I tried to upload a PNG file and saw that the image was uploaded to the /files directory on the web server, with a generated prefix before the actual file name. It looked something like this:

The path of an uploaded image on the webserver

When talking about paths, the first vector that comes to my mind is “path traversal”.

Let's see if we can find a path traversal vulnerability here, allowing us to upload an image to a location other than the /files directory.

Using Burp to inspect the file uploading POST request, we are can change the path of the upload of our image.

Using /../../ before the file name will go two steps back from the location we are currently in — /index/files/image to /index and will try to upload the image in that path.

Uploading ‘cat.png’ to /index path

Trying that we got the first flag, the server is indeed vulnerable to path traversal attacks.

But more importantly, we got a 200 OK for our request, meaning that the image ‘cat.png’ actually was uploaded to /index.php! Let's verify that:

A beautiful Robotcat in /index path

And yup, the image was uploaded successfully to /index.php.

FLAG1

Knowing that we can upload a file to a path that can execute PHP code we can do many malicious things.

One of them is injecting a Webshell backdoor code inside the content of an image. This is a well-known technique that is being used in order to take advantage of the fact the server is not inspecting the content of the image (file) that was uploaded.

Moreover, with this technique, you can even bypass a WAF that suppose to provide another layer of defense between the end-user and the server, if the WAF is not inspecting the image content while it is being uploaded to a web server.

Let's get into business:

So we can download an image file that looks innocent, but actually hide in it malicious payload, or.. we can “create” a one of our own.

Let's keep going with the ‘cat.png’, going to Burp inspecting our POST request to upload that file we can see that the POST body consists of a long text of symbols, that represent the of the image’s binary content.

We can add our malicious payload at the end of the image’s content, and it will be executed and run by the server.

I’ve tried something like this:

PHP code at the end of the image content

As you can see, I’ve added my malicious payload — A PHP code at the end of the image’s content and changed the type of extension of the file to .php.

Probably you are worried that the server won't let me upload the file as now it is .php and not .png as should, but actually the server does not care about the extension of the file, it cares about the header Content-type, which specify the type of the content delivered in the request.

As long as you keep the value of the header as PNG, the server will allow your request: Content-Type: image/png.

PoC:

By sending the crafted request to the server, we get a 302 redirect (in which we can see the first flag again, as we used path traversal).

Clicking on “Follow redirect” giving us 200 OK with the content of our new cat.php file, that includes its content, and more importantly — the response to the command that we injected and got executed.

ls command successfully executed

At this point we know we successfully compromised the server and we can execute any command we want such as <?php system (“cat /etc/passwd”);?> and more.

But we still didn't get our flag.

After playing around for some time, I found out that the flag was located in the index.php page, so using the following command: <?php system (“cat index.php”);?> to display its content, reveled the desired flag:

Server response — Flag captured!

--

--