File Upload

The first step in many attacks is to get some code into the target system before finding a way to execute the code. The file upload vulnerability is a common way for attackers to accomplish the first step.

There are two main classes of the file upload vulnerability. The first is with the file metadata, like the path and file name. These are generally provided by the transport, such as HTTP multipart encoding. This data may trick the application into overwriting a critical file or storing the file in a bad location. The second is with the file size or content of the file uploaded. This depends entirely on what the file is used for.

Attack Vector

File Upload HTML forms allows users to upload files onto a web server. The file upload vulnerability allows an attacker to upload a file with malicious code that could be executed on the server.

For the file upload attack to be successful, an attacker must be able to upload a malicious file that violates path, file name, file size, or content restrictions. Then the attacker must be able to execute the file and perform some malicious action.

Impact

The consequences of the file upload vulnerability can be any of the following, depending on what the application does with the uploaded file and where it is stored:

  1. Server-side attacks: The web server can be compromised by uploading and executing a web-shell which can run commands, browse system files, browse local resources, attack other servers, or exploit the local vulnerabilities, and so forth.

  2. Client-side attacks: Uploading malicious files can make the website vulnerable to client-side attacks such as XSS or Cross-site Content Hijacking.

  3. Uploaded files can be abused to exploit other vulnerable sections of an application when a file on the same or a trusted server is needed (can again lead to client-side or server-side attacks).

  4. Uploaded files might trigger vulnerabilities in broken libraries/applications on the client side (e.g. iPhone MobileSafari LibTIFF Buffer Overflow) or server side (e.g. ImageMagick flaw that called ImageTragick!).

  5. The file storage server might be abused to host troublesome files including malwares, illegal software, or adult contents. Uploaded files might also contain malwares' command and control data, violence and harassment messages, or steganographic data that can be used by criminal organisations.

Attack Examples

Example 1 - Basic File Upload

A basic File upload HTML form without any input validation condition (i.e. the server is not checking for the file extension or content-type of the file being uploaded) will simply accept whatever file is uploaded. A php file (with the .php extension) containing a malicious script can be uploaded to create a backdoor into the server.

Example 2 - Content-Type Restriction

Burpsuite can be used to capture the ongoing HTTP request and observe the "content-type" header which indicates the internal media type of the message content. It is also a common parameter used by web applications to recognize a file as valid or not. For instance, they might only accept files with the "Content-Type" or "text/plain". This protection can be bypassed by changing the content-type parameter with "image/png'' in the request header using Burpsuite. The same php file described in example 1 can be uploaded to the server to perform malicious actions.

Example 3 - Double Extension File Upload

If the application is checking file extensions, they may restrict file uploads to only contain certain extensions like ".png" and ".pdf". Now we can no longer upload a PHP file because the ".php" extension would be rejected. Taking a look at the developer's code reveals how extensions are being handled:

$igAllowed = array('png');
$igSplit = explode(".", $_FILES["files"]["name"]);
$igExtension = end($igsplit);

if($_FILES["file"]["type"] ≠ "image/png" || !in_array($igExtension, $igallowed))

Echo "Please Upload Valid \"PNG\" File.";

There are three important things to observe:

  1. $igAllowed contains an array for the extension .png (i.e. the web server will accept only that file which has .png at the end).

    1. $igSplit uses the explode() function with a reference to ".", thus the PHP interpreter will break up the complete filename as it encounters with over a dot "."

  2. In the third variable over in the $igExtension, he is using the end() function for the value of $igsplit, which will thus contain the end value of the filename.

To bypass these restrictions, the attacker must implement the Double Extension" by inserting multiple extensions with a filename. For example "Attack.php.png" looks like a png image, but when the file is uploaded with the double extension it will execute a php file. Thus, by implementing double extension on the file to upload will overcome this extension security.

Historical Attacks

  • This wpshop plugin file upload vulnerability reported in early 2015.

  • Through the use of an automated testing toolkit, a team of South Korean academics found 30 file upload-related vulnerabilities on numerous open-source applications, forums, store builders, and content management systems.

  • This Contact Form 7, the most widely used WordPress plugin, unrestricted file upload vulnerability.

Defenses

There are multiple defenses against file upload that are considered too weak, such as denying listing file extensions, "content-type" headers, and using a file type detector. More secure prevention methods are included in the following:

  • File types allowed to be uploaded should be restricted to only those that are necessary for business functionality, only allow specific file extensions

  • The application should perform filtering and content checking on any files which are uploaded to the server. Files should be thoroughly scanned and validated before being made available to other users. If in doubt, the file should be discarded.

  • Limit the filename length. For instance, the maximum length of the name of a file plus its extension should be less than 255 characters (without any directory) in an NTFS partition.

  • Use an algorithm to determine the filenames. For instance, a filename can be a MD5 hash of the name of a file plus the date of the day.

  • Uploaded directory should not have any "execute" permission and all the script handlers should be removed from these directories.

  • Limit the file size to a maximum value in order to prevent denial of service attacks (on file space or other web application's functions such as the image resizer).

Criteria for Demonstration

To demonstrate a file upload, show that a file that violates the path, file name, file size, or content restrictions can be uploaded. Then, show how that enabled further manipulation of the web server by executing code from the uploaded file.

Other resources

OWASP

Hacksplaining

Bi0s wiki

cwhatley