Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The AWS S3 Denial of Wallet Amplification Attack

blog.limbus-medtec.com

Post reply on HN
Print view View original

41–50 of 97 posts

Re: The AWS S3 Denial of Wallet Amplification Attack

#41

Post by __roland__ »

bearjaws wrote: post #18

Hate that it's essentially half ChatGPT generated. Especially given the huge explanation of AWS.

I can assure you this was not AI-generated, apart from the 'symbolic image' (which should be fairly obvious :).

Maybe that's just our non-native English shining through. In any case, as a small European company in the healthcare space, we are quite used to having to explain "the cloud" (with all potential and pitfalls) to our customers. They are also (part of) the target audience for this post, hence the additional explanations.

(Not OP and not author of the article, but was involved in the write-up.)

Re: The AWS S3 Denial of Wallet Amplification Attack

#42

Post by carbotaniuman »

jsheard wrote: post #29
Havoc wrote: post #24

It's almost like the combination of public accessible + charged per use + big cloud refusing to allow hardcaps on spend is a terrible idea...

Azure is probably the most egregious example of this, AWS and GCP can at least claim they have architectural barriers to implementing a hard spending cap, but Azure already has one and arbitrarily only allows certain subscription types to use it. If you have a student account then you get a certain amount of credit each month and if you over-spend it then most services are automatically suspended until the next month…

I guess it's a matter of students don't have money to spend and bad optics, while a company might be cowed into paying the bill.

Re: The AWS S3 Denial of Wallet Amplification Attack

#43

Post by akira2501 »

INTPenis wrote: post #26
akira2501 wrote: post #22

We use CloudFront and we deny public users the ability to access S3 directly. You can even use Signed URLs with CloudFront if you like. I'm not sure I'd evere feel comfortable letting the public at large hit my S3 endpoints.

As it should be, but recently on HN it was posted that AWS will charge you for any unauthorized PUT request to your S3 buckets. Meaning even 4xx errors will rack up a charge. So your S3 bucket names must be hidden passphrases now that stand between an attacker and your budget.

Wow. Okay. New horrors brought to us by the modern world we've created.

Thankfully, it does look like AWS is appropriately embarrassed over this, and is going to maybe do something.

https://twitter.com/jeffbarr/status/1785386554372042890

Re: The AWS S3 Denial of Wallet Amplification Attack

#44

Post by dylan604 »

jsheard wrote: post #29
Havoc wrote: post #24

It's almost like the combination of public accessible + charged per use + big cloud refusing to allow hardcaps on spend is a terrible idea...

Azure is probably the most egregious example of this, AWS and GCP can at least claim they have architectural barriers to implementing a hard spending cap, but Azure already has one and arbitrarily only allows certain subscription types to use it. If you have a student account then you get a certain amount of credit each month and if you over-spend it then most services are automatically suspended until the next month…

That's insane as well. They already built the system, but you just can't use it because we want the option for you to screw up and pad our billing. There are many projects I've worked on where a service not being available until the 1st of the next month would not be anything more than a minor annoyance, and would much rather that happen than an unexpected bill. This is also something that I think would be a nice CYA tool when developing something in the cloud for the first time. It's easy to make a mistake when learning cloud services that could be expensive like TFA shows.

Re: The AWS S3 Denial of Wallet Amplification Attack

#45

Post by nicklecompte »

mikepurvis wrote: post #38
nielsole wrote: post #28

Earlier quoted context omitted.

S3 egress costs are free if the traffic stays within AWS. Sounds like your clients were EC2 instances so this wouldn't apply to you, would it?

If it was a web application as stated in the GP, then it would indeed be egress as the request would be coming from a browser.

Yes, it was client-side JavaScript making the range requests, asking for a string of genomic data to render in the browser. It was only to give the scientists a pretty picture :) The EC2 costs were largely ElasticSearch for a different function, which never looked at the data in S3.

Re: The AWS S3 Denial of Wallet Amplification Attack

#46

Post by __roland__ »

voidwtf wrote: post #3

The way billing is calculated should be clearly labeled along with the pricing. Azure does this too, it's super unclear what metric they're using to determine what will be billed for requests. We're having to find out via trial and error. If we request 0-2GB on a 6GB file, but the client cancels after 400MB. Are we paying 2GB or 400MB or 6GB? Is there a billed difference between Range: 0-, no "Range" header, and Rang…

Sorry for not having this made clearer (we'll fix this part of the post): the gotcha is not that AWS does not honor range requests, it's that canceling those will still add the full range of bytes to your egress bill (and this can add up quickly) although no bytes (or much fewer) have been transferred.

Re: The AWS S3 Denial of Wallet Amplification Attack

#47

Post by alchemist1e9 »

__roland__ wrote: post #46
voidwtf wrote: post #3

The way billing is calculated should be clearly labeled along with the pricing. Azure does this too, it's super unclear what metric they're using to determine what will be billed for requests. We're having to find out via trial and error. If we request 0-2GB on a 6GB file, but the client cancels after 400MB. Are we paying 2GB or 400MB or 6GB? Is there a billed difference between Range: 0-, no "Range" header, and Rang…

Sorry for not having this made clearer (we'll fix this part of the post): the gotcha is not that AWS does not honor range requests, it's that canceling those will still add the full range of bytes to your egress bill (and this can add up quickly) although no bytes (or much fewer) have been transferred.

On the other hand you did ask for them so what does it mean “canceling”? Just playing devil’s advocate that they did likely start getting the data for you and that takes resources. Otherwise they would be open to a DOS attack that initiates many requests and then cancels them.

Re: The AWS S3 Denial of Wallet Amplification Attack

#49

Post by anon373839 »

tills13 wrote: post #25
bearjaws wrote: post #18

Hate that it's essentially half ChatGPT generated. Especially given the huge explanation of AWS.

A "AI Generated" label would be nice, here.

These AI accusations are becoming a tired trope. What, exactly, about the article gives you the impression that it was generated by an LLM?

Re: The AWS S3 Denial of Wallet Amplification Attack

#50

Post by zedpm »

tomp wrote: post #39

how about the "PUT deny" attack? AFAIK cannot be protected against https://twitter.com/Lauramaywendel/status/178506487864384308...

Jeff Barr posted that AWS is actively working on a resolution for this: https://twitter.com/jeffbarr/status/1785386554372042890 . Given who he is, I take this as a strong indication that there will be a reasonable fix in the near future.
Post reply on HN