A Hole in the Bucket: Compromising Amazon Simple Storage Service

File upload vulnerabilities have existed since the early days of web applications. Due to the absence of robust security mechanisms, these flaws were introduced and remained unnoticed for years. These vulnerabilities often existed in plain sight until someone discovered and exploited them, deploying a backdoor and continuously accessing the system through it for a long time.

In a typical flow, a user uploads an image or file to a website, which gets stored on the server. When accessed, the file is retrieved from the server. However, weak security mechanisms allow attackers to upload malicious files to the server. At first glance, this may not seem like an issue, but a security researcher is always ahead of the curve.

In fact, if developers learn to code with broad and in-depth knowledge, they start identifying security issues independently. An in-depth understanding of any system often triggers critical questions like, "What if I do this?" or "What if I switch it with another value?" These questions can expose unintended behaviors in the system's functionality, potentially confirming the presence of vulnerabilities. Follow-up research may lead to critical exploits or reveal less severe bugs. In simple terms, only by deeply understanding how something is built can you figure out how to break it.

On the other hand, security novices who jump straight into attacking systems without understanding how they work are often called "script kiddies." These individuals typically rely on exploits created by experts rather than uncovering vulnerabilities themselves.

The rapid advancement of technology has introduced new elements into the equation, such as the S3 bucket. In this blog, we will explore how unrestricted file uploads on S3 buckets can be abused.

Background of File Uploads

Conventional file uploads are stored on the server in one of the folders within the web root. The web root is executable by default. Let’s suppose our application is written in PHP and has a folder called upload where all uploaded media is stored. If an attacker uploads a file containing malicious code with a .php extension, wouldn’t it appear similar to other legitimate PHP files? And upon retrieval, wouldn’t the code be executed? Let’s explore this further below:

A functionality to upload image files with weak security checks in place. [Security checks, validation, and bypasses are beyond the scope of this blog.]
The following one-liner code will be placed in the file to be uploaded
 

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

The malicious code has been uploaded; let's break it down.

<?php ?>    → syntax of the beginning of php
echo “ shell ”;     →will simply print the word Shell when we retrieve the page
System()    → System is a function that takes OS commands and executes them
$GET[ ‘cmd’ ]     →$GET is HTTP get variable which defines the URL parameter and ‘cmd’ is the name parameter
 

Assume that example.com/file.php?cmd =id. Our malicious code will take a URL parameter and pass its value to the system function, and the result will be displayed on the web page.

The file is successfully uploaded on the server. “echo Shell” is displayed on the webpage when the file is being retrieved.

The file is successfully uploaded on the server. “echo Shell” is executed and displayed on the webpage when the file is being retrieved.

Webshell: The id command is passed into the URL parameter and the result is displayed on the webpage. Now we can execute shell commands on the web, hence the name WebShell

There are security defenses in place that can be bypassed and there are ultimate secure defenses as well but that is the topic for another day. This is remote code execution via file upload, infects the server side which can be elevated to compromise the server and it is critical.
 

Case Study

US Dept of Defense RCE via File upload

The question arises: If an end user's file is being stored on an S3 bucket instead of the backend server, the server will be oblivious to this particular attack. But is there still a vulnerability if the application has no checks in place for uploading? Perhaps a different attack vector and impact?

The Intervention of S3 Bucket 

Amazon Simple Storage Service (S3) requires no introduction. It is a flexible solution for storing various types of data, serving multiple purposes, one of which is uploading and retrieving media for end users.

For example, when a user uploads a profile picture, the JPG or PNG file is stored in and retrieved from an S3 bucket instead of the server. If an attacker uploads a file with a backend language extension, such as .php or .py, it may seem like no big deal since S3 buckets serve files and media as static content. This means that code execution is not possible due to the absence of a server, the file will simply be served as it is in the browser (keep this in mind).

However, the real question arises: If a file is served as-is in the browser, what happens if we upload frontend language code with a specific content type? And what if, upon retrieval, it is served to the browser?

The Innocent Browser

Browsers are designed to render front-end languages. Any HTML, CSS, or JavaScript code will be parsed and executed by the browser, regardless of where it originates, whether it's from the backend server you're interacting with or elsewhere. This is how client-side injection works, where an attacker injects malicious code into the application's front-end code, causing harmful actions on the client side.

The responsibility for security checks lies on the server side to prevent anyone from injecting code that could be interpreted as front-end code or any other type of executable code. Browsers are not involved in these types of security checks because they operate on the client side and their job is simply to parse and execute specific languages. However, in the current scenario, any front-end language code will be executed by the browser.

Request

The HTML code has been executed, and the legitimate domain name is displayed at the top
 

Exploitation

In the current scenario, malicious code is uploaded to the S3 bucket, and upon retrieval, the code is executed on the client side, all while appearing under a legitimate domain name. We can design a phishing page that mimics the application and spread the URL, such as:

Response

Attackers can exploit this in various scenarios, but here are the top concerns:

Phishing Users

Since the domain name is legitimate, an attacker can set up a phishing page that offers a massive discount, prompting users to enter their credit card information or login credentials. The page may redirect to an external site, followed by an alert. Any theme can be customized to lure users, depending on the business logic of the application.

Malware distribution

There are no checks on the type of file that can be uploaded, allowing an attacker to easily upload malware to the S3 bucket. Although this doesn't directly affect the bucket itself, the attacker can use phishing techniques, as discussed earlier in the "Phishing Users" section, to convince victims to download and install the malicious file. Hosted on the trusted S3 bucket, the file appears to come from a legitimate source, increasing the likelihood that it will be trusted by the victim.

Remediation

All data uploaded from the client side must be thoroughly validated. Based on business requirements, review the files and documents to establish a whitelist of allowed extensions and content types. Any file that does not match the whitelist criteria should be rejected.

Conclusion

As we've explored, file upload vulnerabilities can be a serious security risk, even when the files are hosted on seemingly secure platforms like Amazon S3. Attackers can exploit weak security measures to upload malicious files, which can then be used for phishing or malware distribution. While S3's static content delivery may seem harmless at first glance, the ability for browsers to execute certain types of code on the client side opens the door for exploitation. To mitigate these risks, businesses must implement strong validation and security checks on all uploaded content. Only by proactively addressing these vulnerabilities can we ensure that our applications remain safe from exploitation and our users' data stays secure.