Cloud computing is the latest trend these days, and most businesses and corporations have either fully transitioned their IT Infrastructure to the cloud or are in the process of achieving this task.

However, despite the advantages that the Cloud offers, it is still quite a challenge for a business to migrate 100% to the Cloud. For example, companies should not only carefully evaluate the risks to their data, but should also evaluate the cloud provider services and type and kind of Security that they offer.

However, the reality is that many organizations end up using either misconfigured or insecure cloud-based configurations which very often result in Security breaches or data leaks. This article will concentrate on the Amazon Web Services (AWS) service (also known as the “S3”) and its insecure configurations. However, before we consider the configuration side of AWS S3, the foundation of what makes up the S3 must be examined first.

What is Amazon S3?

The S3 is a cloud-based offering from AWS to store and retrieve any amount of data from anywhere in the world at any given point in time. The architecture of S3 is kept simple to provide robustness and efficiency to its end users. The S3 is made of up of 2 main elements: Buckets and Objects.

Buckets: Buckets are like big containers where data is stored. Each bucket also has a name which is unique to the other buckets that are on the AWS platform. For example, if there is a bucket name ‘test’ registered in S3, nobody else in the world can create another bucket with this same name. Bucket are accessible at http://<BucketName> .

The AWS S3 is broken down into these specific regions:

US East (N. Virginia) Region
US East (Ohio) Region
US West (N. California) Region
US West (Oregon) Region
Canada (Central) Region
Asia Pacific (Mumbai) Region
Asia Pacific (Seoul) Region
Asia Pacific (Singapore) Region
Asia Pacific (Sydney) Region
Asia Pacific (Tokyo) Region
EU (Frankfurt) Region
EU (Ireland) Region
EU (London) Region
South America (São Paulo) Region

After a name request has been submitted to the AWS, the end user will then be redirected to the respective region where the proposed bucket name geographically resides at.

Objects: Objects are the real entities which are stored in the buckets and the ss identified by a key and a version ID.


The S3 provides Access Control Lists (aka ACLs) at both the bucket level and the object level. By default, the owner of a bucket or object has the “FULL_CONTROL” permission. The AWS S3 also has predefined groups which are as follows:

  • All Users group: When this group is assigned to a bucket, permissions are assigned to anyone in the world to access that bucket.
  • Authenticated group: This group authenticates users to access a AWS account. However, they do not have to be specific users that fall under the bucket owner account.
  • Log Delivery Group: This group assigns various “WRITE” permissions which will allow the bucket users to write server access logs.

Below are the permissions in the AWS S3:

  • READ
    • If Granted on a bucket: The objects can be read from the bucket.
    • If Granted on an Object: The object data and metadata can be read.
    • If Granted on a bucket: The bucket ACL can be read.
    • If Granted on an Object: The object ACL can be read.
    • If Granted on a bucket: Objects can be created, deleted or overwritten in the bucket.
    • If Granted on an Object: N/A.
    • If Granted on a bucket: This allows for the writing of new ACLs for the bucket.
    • If Granted on an Object: This allows for the writing of new ACLs for the object.
    • If Granted on a bucket: This will allow all permissions to be assigned to the end user.
    • If Granted on an Object This will allow all permission to be assigned to the end user.
  • Ethical Hacking Training – Resources (InfoSec)

Now that we have an idea of the AWS S3 Groups and Permissions, we can now examine how these permissions can be the cause of data leaks, which is described below:

Weak Permissions

With the permissions listed above, data leaks have happened due to following:

  • ALL Users group: As described above, if a bucket is assigned to this group then any user can perform any action on the bucket. Do not make this group public. Also, make sure that the bucket has only READ, READ_ACL permission assigned to it. This group is the primary source of DATA leaks.
  • Authenticated Users group: Owners very often establish their buckets in this group with the understanding that only their users can access these buckets. However, they are assigning bucket access to every authenticated user in the world. To prevent this from happening, do not assign any bucket to this group. Make sure that only the READ, READ_ACL permissions are assigned to this group.

Hardened Permissions

Apart from the permissions and groups which are assigned to the buckets and objects respectively, users can follow the below strategies to assign Hardened Permissions to further secure their information and data that are stored in the AWS S3:

  • Use Bucket Default Encryption: The AWS S3 provides a way to encrypt all buckets and objects. All new buckets and new objects that are created are initially encrypted. Also, end users can use the server-side encryption protocols that are available to encrypt all the objects before they are stored on disk in onto the AWS S3. However, it is important to note that end users will not have complete control over the encryption keys. To obtain this, the end users first need to encrypt client side of their specific Web-based application.
  • CORS: Make sure to apply the proper policies on buckets and objects to handle the CORS request securely.

In conclusion, utilizing the S3 service is very easy, but both the users and the administrators need to make sure that the sub-resources such as the buckets and objects are carefully organized and hardened. This is done by using the various Security configurations that are supplied by the AWS.