Requests to access buckets in the AWS S3 service lead the holder to pay amounts that can become very high, even when these requests are denied, with important implications for improper use that can lead to real attacks. This is the discovery of Maciej Pocwierz, a Polish developer who found himself with a bill of over 1,200 after choosing, by pure chance, to give his bucket on S3 a name also used in the example configuration of an open source project. The cause lies in the fact that AWS has so far also billed for denied access to resources hosted in S3. A problem that will perhaps be resolved after the attention this case has generated.
Issues with AWS S3: Bucket naming can lead to high bills
As he explains on his blog, Pocwierz started working with an S3 bucket in the region a few weeks ago eu-west-1 of AWS, leaving it blank. Buckets are containers (literally “buckets”) on the S3 storage service and can contain files and objects; they are often used to store large amounts of data, particularly in corporate settings.
Two days after creating it, the developer checked his bucket and discovered that the bill had reached $1,300 (just over $1,200 at current exchange rates). The reason lies in the fact that he had chosen, not without some misfortune, a name for the bucket also used by an open source project as a default value that must be overridden during installation. However, many have left this name unchanged, with the result that Pocwierz’s bucket has been flooded with requests.
Although they were rejected, because the users trying to (unknowingly) access the bucket did not have permission to do so, these requests were charged to Pocwierz. This is, as the company’s support confirmed to him, the norm: even rejected requests are charged, regardless of the fact that a user may have no control over them.
The problem with this approach, as many developers and systems engineers on the Internet report, is that there is no real defense. Choosing a name that is not easily identifiable for the buckets is certainly a good practice, but it does not protect against the fact that an attacker discovers it it can however bombard the bucket with requests and thus lead to very high invoices.
Pocwierz also pointed out that in this specific case there is a problem of data security: since the name of his bucket is the one used on many installations of the open source tool, by opening the bucket to writing by anyone he was able to collect in a few minutes about 10 GB of data from unaware users who had kept the default name of the bucket. This is not a problem in the AWS service as such, but a general problem in the management of default values; of course, given AWS policies, the option of creating an inaccessible bucket with the same name as the one in the documentation becomes an unviable option. However, this aspect of security remains theoretical, because no attacks of this type are known to date.
This story sparked a strong debate, which led Jeff BarrChief Evangelist at AWS, to confirm on https://twitter.com/jeffbarr/status/1785386554372042890 how the company is working to change this mechanism, although no certain timescales have been given for the intervention. It is not even clear whether the company will decide to make the name of the bucket affected by the problem unavailable: although Pocwierz has decided to delete his, the possibility remains that someone else opens one and can thus collect the data sent by the open source tool .
We have asked the press office for further details, but at the moment there is nothing beyond Barr’s tweet, which was indicated to us: there is only the promise that we will receive any updates in the future.
 even for denied access requests){kind=link}