Impact Study: Amazon S3 Buckets Configuration

Nowadays, the flights of data are more and more present in the media … A bad configuration of your Buckets Amazon S3 can have big impacts such as attacks of corruption of data, distribution of malware, even typical attacks ransomware! Thanks to HTTPCS, it is possible to test the safety of your Buckets Amazon S3.


For several months now, the media has been reporting data leaks from misconfigured Amazon S3 Buckets which allow to read sensitive files.

Indeed, Amazon S3 is a cloud storage service. In order to send your files (pictures, videos, PDF, etc.), you should first create a “compartment”, called “bucket”, in one of the Amazon Web Service (AWS) regions. This step provides the upload of an unlimited number of data to this compartment.

From Verizon to the WWE and even the Pentagon itself, more and more State departments, companies and individuals get storage spaces available online without applying security configurations required.

By the very nature of the storage, allowing any type of file, Buckets may contain anything from simple picture to databases’ full backup.

A few examples of leaks discovered by HTTPCS :

 Amazon AWS Public Buckets sensitive information
Illustration Legend : Amazon AWS Public Buckets not locked in reading containing sensitive information.


 Amazon AWS Public Buckets sensitive information
Illustration Legend : Amazon AWS Public Buckets not locked in reading containing sensitive information.



This makes them prime targets for any hacker worthy of the name.

Knowing this, HTTPCS conducted an impact assessment to get current and specific results about Amazon S3 Buckets’ configuration.

During the study, we analyzed these parameters :

  • 1 – Is the Bucket private or public ?
  • 2 – If the Bucket is public, does it contain any files ?
  • 3 – If it contains files, can we read them ?
  • 4 – If the Bucket is public, is it possible to write ?



  • 1 – Enumeration of * addresses : HTTP 404 = nonexistent Bucket ; HTTP 403 = private Bucket ; HTTP 200 = public Bucket.
  • 2 – If the page contains the beacon <Keys>, the Bucket contains at least one file.
  • 3 – Files analysis and attempt to read from the first file : if the page contains the string “<Code>Access Denied</Code>“, then the file is not readable. Otherwise, the file is readable.
  • 4 – Attempt to write then read the transmitted file.

We chose this methodology because it takes into account several factors which seem to have been omitted in previous published studies, including whether the Bucket is private or empty. Furthermore, the random enumeration of addresses avoids using search engines, which only identify public Buckets.


Here are the results over more than 100,000 existing Buckets (percentages rounded to unity) :


We may draw these conclusions :

  • 90% of Buckets are not public, therefore there is no risk of data leaks or corruption ;
  • 58% of public Buckets (i.e. 5.8% of the total) contain readable files, what might allow data leakage ;
  • 20% of public Buckets (i.e. 2% of the total) aren’t write-protected, what might lead to data corruption attacks, malware spreading, and even to ransomware attacks, as we could see in 2017 on poorly configured MongoDB databases ;
  • Only 5% of the Buckets which aren’t write-protected (i.e. 0.1% of the total) don’t contain any file, therefore the possibilities of large-scale attacks are quite real.



After this study, HTTPCS, European leader in IT security, provides its tool (integrated into the HTTPCS dashboard) to test your Amazon S3 Buckets security.

try our httpcs technology for free



Your email address will not be published.