1

While I was pentesting a web application, I found out that files that are uploaded to the web application are stored in an AWS S3 instance. Based on my experience, when a web application needs to store all types of files, including files with potential malicious extensions (.php, .exe, .js and etc.), they will not allow the AWS S3 instance to view/execute the file content on the server, so they will automatically download the file instead of running it. Surprisingly, the AWS S3 instance is configured to view/execute all types of files. So, when I tried uploading a .html file, the HTML tags are executed. Other than uploading .html files and creating my own HTML page, what are other security concerns/exploits that can be done through the misconfigured AWS S3 Instance?

Additional Information: I was able to upload .html and .js file and execute it on the AWS S3 instance

Regards,

Improve this question
5
  • I don't quite understand the question. AWS S3 is an object storage service -- it doesn't have the ability to execute files (e.g. php, exe etc). When you say S3 instance, I assume you mean an EC2 instance with access to an S3 bucket? Is that right?
    – keithRozario
    Commented Jul 18, 2021 at 3:52
  • @keithRozario I believe that amazon allows files that are stored on the S3 instance, or I should say S3 buckets, to be viewed directly. I don't have much experience with AWS, but I assume there is a configuration that allows AWS S3 users to view files directly or just to download them when the URL is accessed. Uploading a profile picture to AWS S3 Bucket is one of the examples that allows the file to be viewed/executed. The question is what can I do if I have the permission to upload .HTML and .js file? Is spoofing the most that I can do?
    – Emanuel Beni
    Commented Jul 21, 2021 at 2:53
  • if the bucket is serving a website, then yes, you'd be able to upload .HTML and .js files that will execute on the visitors machine. However, the file is 'executing' on S3, only on the browser that is viewing the files served out of it.
    – keithRozario
    Commented Jul 22, 2021 at 5:07
  • @keithRozario Yes, I understand this point. Is being able to upload and execute .HTML and .js files dangerous for AWS S3 bucket?
    – Emanuel Beni
    Commented Aug 5, 2021 at 9:52
  • the bucket itself is just a storage mechanism, it doesn't execute the file. But leaving aside S3 for the moment, allowing users to upload files that might be executed on server-side is never a good idea.
    – keithRozario
    Commented Aug 8, 2021 at 3:24

2 Answers 2

Reset to default
1

Unrestricted file uploads on S3 are never good, but the actual having an S3 server "execute" HTML and JS code would be the same as serving a website and having the javascript run client-side.

If the JavaScript is being run in the context of the server (that is, serverside JS like Node), then that's exploitable.

Where unrestricted file uploads really hit hard is in cost. If there's no rate or size limit on uploads, the cost of storing all these files is potentially unlimited.

Improve this answer
1
  • In terms of being able to upload .HTML and .js files, the most that I can get is spoofing right? Where I am hosting my HTML files under their AWS S3 Instance domain. The last point you mentioned regarding no rate or size limit on uploads, how do I actually test this without accidentally inflicting cost on the company? And how do you actually connect Unrestricted File Uploads with no rate or size limit on uploads, wouldn't this simply be a configuration issue not Unrestricted File Uploads?
    – Emanuel Beni
    Commented Jul 15, 2021 at 5:33
0

Uploaded files represent a risk to apps...

A first step in many scenarios is to get some code to the attacked system, then find a way to execute the code. File upload helps the attacker for the first step.

As mentioned above a dangerous consequence here is an overloaded S3 bucket or AWS instance filesystem, but apparently here the app face client-side attacks (simple defacement, or stored XSS with the execution of arbitrary code in the client browser).

The S3 bucket might be abused to host troublesome files including malwares, decompression bombs, illegal software, or questionable contents, but also shell or other executable scripts targeting the server environement.

You should check for statements to the S3 bucket policy that allow the s3:PutObject action only for objects that have the extension of the file type that you want and check for policies misconfiguration, since the policy could have been changed by something or someone else.

Others concerns include:

File metadata, like the path and file name. These are generally provided by the transport, such as HTTP multi-part encoding. Such data easily pass into server logs and can also be another vector of attacks.

Small size files as they can also lead to denial of service attacks.

All the control characters and Unicode char from the filenames and their extensions.

Filenames with excessive length.

Overwriting mecanisms inside the S3 bucket itself.

Multiple extensions since they are used to bypass restrictions

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .