Live data from Hacker News

The AWS S3 Denial of Wallet Amplification Attack

blog.limbus-medtec.com

51–60 of 97 posts

Re: The AWS S3 Denial of Wallet Amplification Attack

#51

Why is anyone using S3 when Cloudflare R2 is free?

Lots of reasons. My company started using AWS (and specifically S3) something like 9 years ago; R2 wasn't even on the radar back then. If I were starting from scratch today, I'd be looking seriously at Cloudflare as a platform, but it's only in the last year or two that they've offered these services that would make it possible to build substantial applications.

Re: The AWS S3 Denial of Wallet Amplification Attack

#53
AWS APIs need a cleanup. I am constantly running into issues not documented in the official doc, boto3 docs, or even on StackOverflow. It's not even funny when a whole day goes by on trying to figure out why I see nothing in the body of a 200 OK response when I request data which I know is there in the bowels of AWS. Then it turns out that one param doesn't allow values below a certain number, even though the docs say otherwise.

Re: The AWS S3 Denial of Wallet Amplification Attack

#54

"Denial of Wallet" seems a misnomer--it makes it sound like source of payment is being blocked. They should really use the same term cellular systems have been for decades to describe this kind of threat, namely an "overbilling attack".

"Denial of Wallet" has been used in countless articles (incl. academic) and places to refer to attacks that increase usage bills.

Re: The AWS S3 Denial of Wallet Amplification Attack

#55
post #37

Earlier quoted context omitted.

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.

In all fairness, systems administrators have always had to pay for unauthorized requests and systems to mitigate the risk The new thing is hyperscalers have so much capacity you can get flooded by these long before the service degrades or goes offline

Also, the cost of doing this per request is insane compared to either absorbing or rate-limiting the bandwith the requests take.

Cloud computing charges you by the request/byte/cpu cycle. Servers do not have this issue.

Also, is it simply not possible to rate limit this on a per IP basis? Make client only able to do X requests per second from each unique IP/network flow.

Re: The AWS S3 Denial of Wallet Amplification Attack

#56

Earlier quoted context omitted.

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.

Sure, that's true. The thing is: this was the same requested (and cancelled) range on the same file(s), over and over (it was a bug). Looking at this from the outside, even some internal S3 caching should have had many cache hits and not have to re-download the requested ranges internally all the time (there were dozens of identical requests per second, immediately being cancelled).

On top of this, S3 already bills (separately) for any request against a bucket (see the other current issue with the invalid PUT requests against a secured bucket, which still got billed to the bucket owner; https://news.ycombinator.com/item?id=40203126). So I'd say both the requests and the cancellations were already paid for; the surprise was the 'egress' cost on top, of data that was not actually leaving the AWS network.

Still, you are right that this still consumes some additional AWS resources, and it is probably a non-trivial issue to fix in the 'billing system'.

Re: The AWS S3 Denial of Wallet Amplification Attack

#57
post #15

Earlier quoted context omitted.

So I guess the attack of the OP is a case AWS calculate price based on the unbounded request header and not on the actual egress

More or less. The article quotes AWS as saying the following: > Amazon S3 attempts to stop the streaming of data, but it does not happen instantaneously. ...which doesn't really explain it. It shouldn't send more than a TCP window after the connection is closed, and TCP windows are at most 1 GiB [1], usually much less, so this completely fails to explain the article's observed 3 TB sent vs 130 TB billed. The article…

this can be explained that this may be not egress out of AWS, but egress out of S3 system itself.

S3 is a block storage, so retrieving an object for such a high availability and high perf service means it tries to pull some X block of data and cache it before sending through the socket.

That X block of data is out of internal S3 storage, just not sent through the bigger Internet egress subsystem.

So technically aws may argue this is egress for s3, just not for aws

Re: The AWS S3 Denial of Wallet Amplification Attack

#59
post #57

Earlier quoted context omitted.

More or less. The article quotes AWS as saying the following: > Amazon S3 attempts to stop the streaming of data, but it does not happen instantaneously. ...which doesn't really explain it. It shouldn't send more than a TCP window after the connection is closed, and TCP windows are at most 1 GiB [1], usually much less, so this completely fails to explain the article's observed 3 TB sent vs 130 TB billed. The article…

this can be explained that this may be not egress out of AWS, but egress out of S3 system itself. S3 is a block storage, so retrieving an object for such a high availability and high perf service means it tries to pull some X block of data and cache it before sending through the socket. That X block of data is out of internal S3 storage, just not sent through the bigger Internet egress subsystem. So technically aws m…

Then subsequent requests that hit the cache shouldn’t be charged by that logic.

Re: The AWS S3 Denial of Wallet Amplification Attack

#60
post #25

Earlier quoted context omitted.

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?

If writers don't want people to think their content is AI generated, maybe they shouldn't put ugly AI generated images on top of everything they write.
Post reply on HN