Unrestricted Upload of File with Dangerous Type [CWE-434]

Arbitrary file upload weakness describes improper or absent validation of file types when uploading files.

Created: September 11, 2012
Latest Update: December 28, 2020

Table of Content

1. Description
2. Potential impact
3. Attack patterns
4. Affected software
5. Exploitation Examples
6. Severity and CVSS Scoring
7. Mitigations
8. References
9. Latest Related Security Advisories

Want to have an in-depth understanding of all modern aspects of
Unrestricted Upload of File with Dangerous Type [CWE-434]? Read carefully this article and bookmark it to get back later, we regularly update this page.

1. Description

This weakness occurs when application does not validate or improperly validates files types before uploading files to the system. This weakness is language independent but mostly occurs in applications written in ASP and PHP.

A file of dangerous type is a file that can be automatically processed within the product's environment. The following example demonstrates upload of a PHP file:

HTML form

upload_image.php

The above code does not perform any checks on uploaded file and uploads this file within the web root directory. As a result an attacker might be able to upload arbitrary PHP file and execute it by directly accessing the uploaded file.

2. Potential impact

An attacker might be able to upload and execute arbitrary code on the target system which could result in execution of arbitrary HTML and script code or system compromise.

3. Attack patterns

There are following CAPEC patterns for this weakness:

• CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
• CAPEC-122: Exploitation of Authorization

This weakness is not described as an attack technique in WASC Threat Classification database.

4. Affected software

Any software that allows files uploads is potentially vulnerable to this weakness.

5. Exploitation Examples

We will use the HTB23079 security advisory (CVE-2012-1468) as an example of this weakness. Open Journal Systems does not properly verify file extension before uploading files. A remote authenticated user can upload files with dangerous extension within the web root directory. Since registration is open by default, an attacker can register to the application and perform a successful attack.

Let's create the exploited as described in the advisory:
file.pHp

After that we log in into the application and create a new Submission. On step 2 we upload our file:

As we can see, the file was uploaded and renamed to "23-43-1-SM.pHp". Now we can access this file directly using the following URL:
http://[host]/files/journals/1/articles/23/submission/original/23-43-1-SM.pHp

Since this file has a .pHp extension, it is treated as a regular PHP file by the webserver. The following image shows successful execution of our PHP code on the target server:

6. Severity and CVSS Scoring

This weakness should be scored depending on the maximum potential impact. If upload of arbitrary PHP file is possible it should be scored as:
10 (AV:N/AC:L/Au:N/C:C/I:C/A:C) - Critical severity.

If authentication is required to exploit this vulnerability but registration is open by default and any registered user can upload files with dangerous types it should be scored as Au:N otherwise as Au:S or Au:M depending on required privilege level and authentication schemes.

We use CVSSv2 scoring system in our HTB Security Advisories to calculate the risk of the discovered vulnerabilities. Not all of the vulnerabilities are scored in strict accordance to FIRST recommendations. Our CVSSv2 scores are based on our long internal experience in software auditing and penetration testing, taking into consideration a lot of practical nuances and details. Therefore, sometimes they may differ from those ones that are recommended by FIRST.

7. Mitigations

To avoid exploitation of this weakness, developers should consider the following recommendations:

1. Store uploaded files outside of the web root directory when possible.
2. Use randomly generated filenames for uploaded files.
3. Ensure that only one extension is used in the filename. Consider cross-site scripting possibility if you allow upload of html files.
4. On case-insensitive systems ensure that case-insensitive evaluation of the file extension is performed.
5. Check for the correct MIME type of the file before uploading it but do not exclusively rely on the MIME type.
6. When possible ensure that only files with allowed extensions can be directly accessed from the upload directory, for example restrict access to any PHP/ASP files within a directory if it should only contain images.

8. References

1. CWE-434: Unrestricted Upload of File with Dangerous Type [cwe.mitre.org]
2. Unrestricted File Upload [owasp.org]

9. Unrestricted Upload of File with Dangerous Type Vulnerabilities, Exploits and Examples

• HTB23239: Arbitrary File Upload in HelpDEZk
• HTB23218: Unrestricted Upload of File with Dangerous Type in BoltWire
• HTB23199: Multiple Vulnerabilities in VideoWhisper Live Streaming Integration WP Plugin
• HTB23079: Multiple vulnerabilities in Open Journal Systems (OJS)

Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to ImmuniWeb is given.