Blue Goat regularly encounters file upload functionalities during web application penetration tests. When our team finds this, it often becomes a high-priority area for testing. When files being uploaded to the back end aren’t adequately checked for exploits, it can allow attackers to access the web server through a command shell or XML External Entities Injection (XXE) attacks. If these attacks aren’t possible, it is still possible to perform some attacks with restricted file uploads, such as Cross-Site Scripting (XSS).
Cross-Site Scripting Through File Upload
To understand how this is possible, it is first important to understand how file upload attacks in general work. When the file is passed to the back end, the server processes it and renders it in the best way that it can find. For example, if there is a profile picture upload function, the server will try to load whatever files are passed to it as pictures for the user. If it renders something instead of pictures, such as a .php file, it can give attackers a back door. When performing Cross-Site Scripting attacks, the back end must render .html files. These are less often checked for than the standard .php or .asp files that can load a web shell.
Case Study
On this particular Gray Box web application test, Blue Goat was tasked with testing three user levels on a home-brewed ASP.NET application. During initial reconnaissance, it was discovered that two of the user levels had access to a file upload functionality. This was meant to be a profile picture upload section for administrative users to manage their organization. This means that any changes made would be pushed out to many different users at once.
To start the testing, we wanted to try some of the more common attacks first. This was an ASP.NET application with XML processing on the back end, so the first things we wanted to try were the standard .asp web shells and XXE. Despite trying various techniques and bypasses, nothing was properly working, and we were unable to get access to the file system this way. Once we uploaded a basic HTML file, we were able to render it by trying to view the profile image. This meant that we would likely be able to get JavaScript to run as well, and sure enough, our simple proof of concept worked.
<!DOCTYPE html>
<html>
<head>
<meta charset=”utf-8″/>
<meta name=”viewport” content=”width=device-width, initial-scale=1″/>
<title>Test Upload File</title>
</head>
<body>
<h1>Test upload</h1>
<script>alert(document.cookie)</script>
</body>
</html>
This was especially impactful due to the fact that the malicious payload would be distributed to any user under the organization if they viewed the profile picture. Stored XSS attacks with this much reach could allow for widespread session hijacking, or phishing attempts by prompting users to visit a malicious website.
Issue Remediation
At Blue Goat, we make sure to work with our clients to fix vulnerabilities to the best degree possible and make sure that any applied fixes cover potential bypasses. In this case, the client made fixes to the file upload functionality to validate whether the files were images or not. This prevented us from simply uploading the same payload as above and getting it to function, as it was searching for the proper MIME type on the image. This type of file validation reads a few “magic bytes” at the beginning of the file to ensure that it’s actually a specific file type. Unfortunately, this can often be bypassed by placing the magic bytes for an image at the beginning of the payload.
GIF87a <!DOCTYPE html>
<html>
<head>
<meta charset=”utf-8″/>
<meta name=”viewport” content=”width=device-width, initial-scale=1″/>
<title>Test Upload File</title>
</head>
<body>
<script>alert(1)</script>
</body>
</html>
During the retest, we noticed that this bypass worked and still allowed for the XSS to work. After some more validation was put in place to prevent uploaded files from rendering anything besides images, the fixes were finalized and the vulnerability was no longer present.
Evaluate Your Web Application’s Security with Blue Goat Cyber
Our team is highly experienced in Black Box, Gray Box, and White Box web application penetration tests. We can perform tests to ensure that your applications are hardened against cybercrime. Contact us to learn more.
