Protection from Unrestricted File Upload Vulnerability

How boring would social networking websites, blogs, forums and other web applications with a social component be if they didn’t allow their users to upload rich media like photos, videos and MP3s?  The answer is easy: very, very boring! Thankfully, these social sites allow end-users to upload rich media and other files, and this makes communication on the world wide web more impactful and interesting.

But user-uploaded files also give hackers a potential entry-point into the same web apps, making their safe handling an extremely important task for administrators and the security team. If these files are not validated properly, a remote attacker could upload a malicious file on the web server and cause a serious breach.

Qualys Web Application Firewall protects against uploads of malicious files by providing automatic validation of uploaded files. Specifically, it inspects the contents of the HTTP request and response associated with the file upload, which allows it to identify specific indicators of whether the contents of the file upload are legitimate or not.

This blog post describes how Qualys WAF does its magic.

About Unrestricted File Upload Vulnerabilities

Malicious files uploads are the result of improper file validation: OWASP calls it Unrestricted File Upload, and Mitre calls it Unrestricted Upload of File with Dangerous Type. According to OWASP, unrestricted file upload vulnerabilities can allow two different types of attacks:

1)  Missing proper validation of file name

This can allow an attacker to overwrite application files using a specially crafted request, for example “../../../index.php”. If not handled correctly, the request in this scenario may overwrite the default application home page, or worse, upload the file to a user-accessible location which is outside the file storage sandbox.

2) Missing proper validation of file content and size

Allowing attackers to upload a file of any size without restriction may allow consuming all storage space on the server, potentially causing a denial of service and even crashing the server in some cases.

The allowed file content type is the most critical issue. This should be taken care of properly, otherwise it may result in arbitrary code execution on the server. Let’s discuss more about this second case. If we look at software affected by unrestricted file upload issues on exploit sharing sites such as exploit-db we can find hundreds of applications affected. Most of these are unauthenticated issues, meaning attackers don’t need to have valid credentials to exploit the issue. This gives us a rough idea of the scope of the issue; it is quite common.

Common But Ineffective Mitigations

An examination of some common but ineffective mitigation techniques gives insight into how hackers can attack your web apps.

File Extension Verification

Blacklisting and whitelisting of file extensions is the most common validation method implemented by developers.

To implement blacklisting, the developer needs to gather all executable extensions disallowed by the server, which is obviously a tricky task, which can be defeated several ways in practice:

• Blacklisting can often be bypassed using uncommon executable extensions such as php3, php4, php5, shtml, phtml, cgi which are understood by server.
• Hackers can also use “.htaccess” file tricks to upload a malicious file with any extension and execute it. For a simple example, imagine uploading to the vulnerabler server an .htaccess file that has AddType application/x-httpd-php .htaccess configuration and also contains PHP shellcode. Because of the malicious .htaccess file, the web server considers the .htaccess file as an executable php file and executes its malicious PHP shellcode. One thing to note: .htaccess configurations are applicable only for the same directory and sub-directories where the .htaccess file is uploaded.
• In certain configurations, multiple file extensions such as shell.php.jpg will trick the server to execute file.
• The infamous null character injection (%00) attack falls under this category.

The whitelisting approach gives developers more control over security as compared to blacklisting, since only allowed file extensions are specified and every other file extension is refused. Still there are some pitfalls in this method. There is a history of server side bugs which allow bypassing such protections, including:

• The IIS 6 semi-colon vulnerability caused by a parser bug which allow user to upload and execute file with names such as test.asp;.jpg, and
• ADS streams on Windows which may allow an attacker to bypass these protections.

Content-type Verification

This kind of verification completely depends upon content-type header, e.g. Content-Type: image/jpeg, containing the MIME type. This is a very weak validation mechanism, as this header is supplied by the user (attacker).

Image Type Content Verification

Many developers believe this is the safest method to prevent malicious file upload issues, it is not foolproof with certain configurations and can still cause issues. For example, using the image processing getimagesize() function which provides information about uploaded file including filetype,size,dimensions which is helpful to detect if an uploaded file is indeed an image.

Security researchers already demonstrated a way to inject executable code in certain sections of images. Some examples of such attack are JPEG image EXIF header injections and encoding of executable code in PNG IDAT chunks. Injecting malicious code inside another file format is not completely new; in the past we have also seen some interesting attack methods like GIF/Javascript Polyglots and the GIFAR attack which bypassed almost all protection mechanisms implemented at the time.

How Qualys Web Application Firewall Protects

As can be seen in the above examples, most file upload attacks are triggered by the fact that the application relies on an established protocol for communication with the client. By playing with this protocol, an hacker can deceive the application and make it think that uploaded files are legitimate when in fact they are malicious.

When the application relies on a content-type verification, the hacker sets an accepted content-type while uploading a PHP script. If the application expects a specific extension, the hacker will be happy to rename his payload file with the desired extension. And if the application tries to validate the file format with classic PHP functions, the hacker will insert the code inside a file that respects the desired format (EXIF header injection described above).

Qualys WAF throws standard protection techniques on their heads by applying deep inspection mechanisms to the bodies of requests instead of performing file validation. Qualys WAF analyzes all parts of the file upload request for signs of trickery or malicious payloads. While parsing a file upload request, it looks for any malicious content indicators such as executable code containing classical dangerous functions (system, exec, kill), functions used for code obfuscation (base64_decode, urlencode, preg_replace) or uncommon tricks used for evading detection. When enough signs are present the WAF will block the request to prevent the application to be damaged.

All signs of attack will be accurately reported to help the user to understand what’s happening. When a user tries to upload a malicious file such as a web shell, Qualys WAF blocks that attempt. The detailed information about this malicious user action gets logged and displayed in the user interface. The event details contain information about detection type, method, severity, user request details, origin of request, etc. which provides valuable insight of attack.

Example: Blocked Upload

The screenshot below shows an example of an attempted file upload that was blocked by Qualys WAF.

The Qualys WAF administrator can configure what level of threat is reported and what level is blocked. In this case, the threat level of 80 shown in the red box exceeds the blocking threshold, so the event was blocked.

The Event Details section shows the detection information details. For the event shown here, QID 150114 is triggered which indicates the user tried to upload a malicious file. QID 226016 indicates the detected event threshold (Threat Level 80) is greater than the blocking threshold (31 in this example), and as a result this request is blocked.

The Event Details section also shows what is in the headers and body for both the request and response, which makes it easy for the administrator to analyze the specifics of the threat.

Click the image below to view full-size.