Monday is here and we’re back at it again with THM!
Today we move on to the Upload Vulnerabilities module.
In this module we will cover General Methodology, Overwriting Existing Files, Remote Code Execution, Filtering, Bypassing Client-Side Filtering, Bypassing Server-Side Filtering: File Extensions, Bypassing Server-Side Filtering: Magic Numbers, Example Methodology and a Challenge to conclude the module!
In the first task of this module we are trying to overwrite the current image which is found at http://overwrite.uploadvulns.thm/.
We check the source code of the website and find that the background image of the mountains is in the directory /images/ with the file name of “mountains.jpg”. We will try to use the upload function in order to overwrite the image with out own.
File has been uploaded using the same file name as the background image ‘mountains.jpg’ to overwrite the current image.
After the upload has processed the flag is then displayed.
Flag – THM{OTBiODQ3YmNjYWZhM2UyMmYzZDNiZjI5}
Next, we move on to the Remote Code Execution section of the Upload Vulnerabilities module.
We run gobuster on the target domain of which we are going to try and gain RCE from, we find three directories from the fuzzing and note the following directories are present.
/resources
/assets
/server-status
http://shell.uploadvulns.thm/
http://shell.uploadvulns.thm/assets/
We use a PHP reverse shell, edit the shell and set up a netcat listener in order to catch the reverse shell.
http://shell.uploadvulns.thm/resources/
Flag – THM{YWFhY2U3ZGI4N2QxNmQzZjk0YjgzZDZk}
In this next section which covers bypassing upload filters that may be present within web applications, we started out using gobuster again and found /assets & /images of which we could upload to images.
We attempted to reuse the .php file from the previous task but the select file option stated this was an invalid file type to select, from here we just use the upload feature which starts the process.
We can see from the below .js file that the expected and accepted file type is image/png so we amend the Burp Suite request to this when uploading.
As shown below, what we did here rather than selecting a file we enter the data from the .php file and amend the Content-Type header to the expected and even though is said POST/?submit=failure this still worked and allowed us to upload the .php shell and trigger this which was caught by netcat!
Flag – THM{NDllZDQxNjJjOTE0YWNhZGY3YjljNmE2}
In the next section of this room, the filter is on the server side for uploads so we unable to edit the client-side to manipulate the upload to work.
First we perform a gobuster and find the same /assets & /images and the directory that the file is uploaded to is /privacy.
We use the .php5 extension to append the file and then the item is accepted.
The file is uploaded in to the /privacy and then we action the shell by selecting it.
Which connects back to our netcat listener and we get the flag.
Flag – THM{MGEyYzJiYmI3ODIyM2FlNTNkNjZjYjFl}
In the next section of this module we use magic numbers in order to bypass the upload restrictions which have been placed on the below web application.
We first use directory fuzzing in order to establish where the uploads may go however we are unable to navigate or browser to any of these directories.
The upload folder is /graphics however we will need to specify the URI in order to activate the shell.
We see that the upload restrictions are only allowing GIF file types to be uploaded.
We edit out shell.php file to include the magic numbers of a GIF file which is shown below.
And from using hexeditor we amend the file type to a GIF in order to bypass the restrictions while our .php shell still being able to trigger.
We see that the upload worked.
We receive a shell and get the flag present in /var/www.
Flag – THM{MWY5ZGU4NzE0ZDlhNjE1NGM4ZThjZDJh}
We now move on to the final section which is the challenge section where we will need to put all the things we have learned within this module to the test!
http://jewel.uploadvulns.thm/
We first check Wappalyzer and see that the web application is running on an Ubuntu operating system and is using Nginx 1.14.0 and is using various JavaScript items.
We check the source code and check for client-side scripts and find that a script is present called ‘upload.js” present within /assets.
We see already that three restrictions are present, there is a file size restricton, a Magic number filter and a file extension filter within this file.
The first filter shows that the file can’t be over one KB in size so the old shell.php cannot be used in this instance.
This second filter shows that the magic number must be “ÿØÿ” which indicates in needs to be a JPEG file that is uploaded.
We use gobuster for directory fuzzing to try and find the location where the upload may be uploaded to and where we can trigger a reverse shell.
We find that we can assess the /admin directory by getting a HTTP 200 status code response.
We find that the /admin page has a field where we may be able to activate a module from the /modules directory which may be where our uploads are sent.
We inspect the web application and find that the background images are being uploaded to the /content directory
E.g –
http://jewel.uploadvulns.thm/content/ABH.jpg
After we have established that the .jpg files are being uploaded to the /content directory we run another gobuster scan to try and find the uploaded items and we see that they are given an naming convention which is not standard or the name we gave the files meaning we will need to specify the URI for the item which we have uploaded to return the shell moving forward.
Note – The wordlist shown below is provided within the room in order to find the naming convention of the files which have been uploaded to the /content folder present on the web server.
After this we decide to try and remove the client-side filters which are present by showing the response to the /assets/upload.js script which is controlling the upload function present on the main page.
Aftet this we amend the name of the shell.js to shell.jpg to circumvent the server side filtering so that the upload is allowed to proceed.
Which we see as uploaded.
We find that the file has been called the highlighted name as shown below.
http://jewel.uploadvulns.thm/content/OYE.jpg
As we can expect, this was not displayed as this was not a legit .jpg file
We then set up our listener to catch the shell.
We then go to the admin page and use ../ a directory traversal method to move up one directory in order to execute the shell which has been uploaded.
Then we have the shell and navigate to the /var/www directory and we grab the flag.
Flag – THM{NzRlYTUwNTIzODMwMWZhMzBiY2JlZWU2}
Overall, that room was quite fun but also frustrating at times in particular the last challenge, as it goes I did not find the last section easy & I’m not sure how someone brand new should be able to do this on there own, but I feel asthough I have learnt alot about upload vulnerabilities and how you bypass certain restrictions whether it be client-side or server-side/magic numbers etc.
Good room!
Until next time & don’t sleepwalk through life!
Leahaey