- CTF Name: TempImage
- Resource: Hacker101 CTF
- Difficulty: Moderate
- Number of Flags: 2
Note::: NO, I won't be posting my found FLAGS, but I will be posting the methods I used.
- Like other flags the first thing I want to do is look at the code. There doesn't first seem much. It seems to be a php page as there is a link to a php page. The network response shows that there is a a nginx1.14.0 (Ubuntu) server running and php/5.5.9-1ubuntu4.24 but that is about it.
- Navigating to the upload.php page there is a hidden field in the code and it looks like that script will display the filename on the screen. By trying to add in a pic of the wrong type I can see the file name is displayed on the screen. By sending the image in I get an error that the image I tried to upload is not supported.
- Going back and adding in a picture of the supported type the filename is still shown on the page and this time the image uploads with no problems.
Looking at the URL we can see there is an added section for "files" now in the path of the image.
http://184.108.40.206/9a1694927f/files/4a47a0db6e60853dedfcfdf08a5ca249_1.pngIf I modify that to be
flaginstead of the image I get an error that the file is not found. But there might be other files...
- Before I try to find other files I want to see what happens if I upload the same image again. By uploading the same image again I get the same url... That seems odd and I would assume that each image would get a new string on the front of it. If I toss this string over to https://crackstation.net/ I can see that it is an MD5 hash for the file's name.
- Now that I know it's format I want to see what if I upload a file path as the file name ending in .png. For this I uses a php file that was made to get the phpinfo(). I named the file
/../../../etc/passwd%00.pngand sent it in. On the first try I can see that the site is not allowing me to use '/' as part of a file name and is changing it so this attack didn't work. If I Repeat the request but modify it so that the file name is correct you can see that the flag populates.
This flag is dealing with an attackers ability to gain access to arbitrary files on the server that is running a web app though directory traversal.
In this case I was able to bypass the applications validation for a specific file type (.png) by requesting one that would lead to a different path.
The best Remediation is not allowing user input when using file system calls.
If this is not possible then validating the users input, use of policies around where files can be saved and what files can be obtained, using whitelists to ensure user input is only of allowed content, and normalizing user input before using.
- It clearly wants one specific format
- If you can't bypass that check, what can you do?
- Read up on PNG chunks
- Because this is part 2 I won't look at the code. It hasn't changed. So this time I want to see if I can upload a malicious PNG file. This is a file that is a PNG, but it will have some code in it that will run instead of or with the image. To do this I start off with a simple .png file that will test if it will accept other input. But as you can see having php code in the image contents was a fail...
- It appears that the application might be checking if the contents of the image are really image data so now I am going to modify this payload to be expected image data. To do this I will take a small image I have and upload it once.
- And now in BurpSuite I will Repeat the request but I will add some data to the png chunks.
First thing to do is to get it working. For this I will add
<?=`$_GET`;?>to the file and send that. The output is a page with the text path on it... hmmm
- Now that I have a GET in the code and I can see it was accepted by the status 302 and the page loading I now need to modify this a bit. The application is only checking the
Content-Type: image/pngand now the end file type so I will change that to .php. Nothing really changed but now if I go to the new php file location I have the option to add in some parameters
1.php?0=ls. As you can see I added in a lot of files. Now let's replace the
cat filenameand take a look at a few of them.
- First one (default.conf) is not interesting.. Second one (index.php) is not that interesting... But if we look at the response that the network got we can see the flag.
The vulnerability is the ability for an attacker to bypass weak validation and inject malicious file to get execution during processing.
This is a really interesting issue as it seems like it could be difficult to check for.
Recommended remediation is to make sure the web server does not parse or execute any code in the directory or by the web-browser, if possible, store user-uploaded images outside of the web-root directory or on a different/additional (CDN) server, and validating file names and whitelisting acceptable characters.