Misconfigured S3 Vulnerability in AWS

Play AWS Labs on this vulnerability with SecureFlag!

Misconfigured S3 Vulnerability in AWS

Description

The Amazon Web Services (AWS) Simple Storage Service (S3) is a common cloud-based storage service frequently used by developers due to its many functions, scalability, and the ease with which it can be implemented. Unfortunately, its popularity as a repository for juicy data has branded it as a prime target for adversarial minds, and over the last years, numerous breaches involving S3 buckets - buckets being AWS’s name of choice for the storage vessel - have occurred.

The problem is that it’s not solely sophisticated attackers that are having to develop technical methods to compromise buckets either - many have simply been misconfigured, left wide open to the public, with the right search resulting in a treasure trove of sensitive information.

Impact

Where to begin? There have been a string of high-profile incidents involving S3 buckets in the last years, and amazingly, it’s not just entities with scant security resources that haven’t secured their systems properly either. In 2017, two S3 exposures were brought to light in quick succession, with one involving the US Army Central Command and the other involving a joint US Army and NSA agency. On the civilian side, a software provider for a well-known travel company failed to adequately configure an AWS S3 bucket resulting in at least 10 million files - 24.4GB worth of credit cards, reservation details, personally identifiable information, etc. - left exposed to the public internet.

As could be expected, impacts are only limited by the value of the data that has been breached. In the cases listed above, the data were highly confidential and extremely sensitive in the government agencies’ cases and sensitive and highly personal in the case of Experian.

Prevention

The below is a necessarily exhaustive list of S3 Security Best Practices to adhere to strictly.

Managing access to resources

Buckets and objects are S3 resources. By default, only the resource owner can access these resources. The resource owner refers to the AWS account that creates the resource.

Access policy describes who has access to what. An access policy can be associated with a resource (bucket and object) or a user. Accordingly, you can categorize the available S3 access policies as Resource-based policies or User Policies.

Resource-based policies

Bucket policies and access control lists (ACLs) are resource-based because they can be attached to S3 resources.

ACLs

Each bucket and object has an ACL associated with it. An ACL is a list of grants identifying the grantee and the permission granted. ACLs are used to grant basic read/write permissions to other AWS accounts. ACLs use a S3-specific XML schema.

The following is an example ACL bucket. The grant in the ACL shows a bucket owner as having full control permission.

<?xml version="1.0" encoding="UTF-8"?>
<AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Owner>
    <ID>*** Owner-Canonical-User-ID ***</ID>
    <DisplayName>owner-display-name</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
               xsi:type="Canonical User">
        <ID>123456789012</ID>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>  

The sample ACL includes an Owner element that identifies the owner by the AWS account’s canonical user ID. The Grant element identifies the grantee (either an AWS account or a predefined group) and the permission granted. Both bucket and object ACLs use the same XML schema.

The following table lists the set of permissions that S3 supports in an ACL. The set of ACL permissions is the same for an object ACL and a bucket ACL. The table lists the permissions and describes what they mean in the context of objects and buckets.

ACL permissions

Permission	Result on Bucket	Result on Object
`READ`	Allows grantee to list the objects in the bucket	Allows grantee to read the object data and its metadata
`WRITE`	Allows grantee to create, overwrite, and delete any object in the bucke	N/A
`READ_ACP`	Allows grantee to read the bucket ACL	Allows grantee to read the object ACL
`WRITE_ACP`	Allows grantee to write the bucket ACL	Allows grantee to write the object ACL
`FULL_CONTROL`	Allows grantee the `READ`, `WRITE`, `READ_ACP`, and `WRITE_ACP` on the bucket	Allows grantee the `READ`, `WRITE`, `READ_ACP`, and `WRITE_ACP` on the object

Canned ACL

S3 supports a set of predefined grants, known as canned ACLs. Each canned ACL has a predefined set of grantees and permissions. The following table lists the set of canned ACLs and the associated predefined grants.

Canned ACL	Applies to	Permissions added to ACL
`private`	Bucket and object	Owner gets `FULL_CONTROL`. No one else has access rights (default).
`public-read`	Bucket and object	The `AllUsers` group gets `READ` access.
`public-read-write`	Bucket and object	The `AllUsers` group gets `READ` and `WRITE` access.
`aws-exec-read`	Bucket and object	EC2 gets `READ` access to GET an Amazon Machine Image (AMI) from S3.
`authenticated-read`	Bucket and object	The `AuthenticatedUsers` group gets `READ` access.
`bucket-owner-read`	Object	Bucket owner gets `READ` access.
`bucket-owner-full-control`	Object	Both the object owner and the bucket owner get `FULL_CONTROL` over the object.
`log-delivery-write`	Bucket	The LogDelivery group gets `WRITE` and `READ_ACP` permissions on the bucket.

Bucket policy

It’s possible to define a bucket policy to grant other AWS accounts or IAM user permissions for the bucket and the objects within. Any object permissions apply only to the objects that the bucket owner creates. Bucket policies supplement, and in many cases, replace ACL-based access policies.

Policy

A policy contains the following elements:

Resources:

Buckets and objects are the S3 resources for which you can allow or deny permissions. In a policy, use the Amazon Resource Name (ARN) to identify the resource.

Actions:

For each resource, S3 supports a set of operations. Identify resource operations that will be allowed (or denied) by using action keywords.

For example, the s3:GetObject permission allows the user to use the S3 GET Object (Get Object) operation. For more information, see S3 actions.

Effect:

This can be either allow or deny. If access is not explicitly granted to a resource, access is implicitly denied.

Principal:

Principal refers to the account or user who is allowed access to the statement’s actions and resources. In a bucket policy, the principal indicates the user, account, service, or other entity that is the recipient of this permission. For more information, see Principals.

Condition:

Conditions for when a policy is in effect.

Use AWS-wide keys and/or S3-specific keys to specify conditions in an S3-access policy. For more information, see S3 condition key examples.

Bucket and User policies are expressed using a JSON file.

The policy in the example below grants anonymous read permission on all objects in a bucket. The bucket policy has one statement, which allows the s3:GetObject action (read permission) on objects in a bucket named examplebucket1. By specifying the principal with the wildcard *, the policy grants anonymous access.

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid":"GrantAnonymousReadPermissions",
            "Effect":"Allow",
            "Principal": "*",
            "Action": ["s3:GetObject"],
            "Resource": ["arn:aws:s3:::examplebucket1/*"]
        }
    ]
}

User policies

It’s possible to use Identity Access Management (IAM) to manage access to an S3 resource by creating IAM users, groups, and roles in the account and attaching access policies to them, granting them access to AWS resources, like S3.

The example policy allows the associated user is attached to perform six different S3 actions on a bucket and the objects in it. This policy can be attached to a specific IAM user, group, or role.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AssignUserActions",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                 "arn:aws:s3:::examplebucket1/*",
                 "arn:aws:s3:::examplebucket1"
            ]
        },
        {
            "Sid": "ExampleStatement2",
            "Effect": "Allow",
            "Action": "s3:ListAllMyBuckets",
            "Resource": "*"
        }
    ]
}

How S3 Authorizes a Request

When S3 receives a request for a bucket or an object operation, it first verifies that the requester has the necessary permissions.

To determine whether the requester has permission to perform the specific operation, S3 does the following, in order, when it receives a request:

Converts all the relevant access policies (user policy, bucket policy, ACLs) at run time into a set of policies for evaluation.
Evaluates the resulting set of policies in the following steps. In each step, S3 evaluates a subset of policies in a specific context based on the context authority.

a) User context

In the user context, the parent account to which the user belongs is the context authority. S3 evaluates a subset of policies owned by the parent account. This subset includes the user policy that the parent attaches to the user. If the parent also owns the resource in the request (bucket, object), S3 also evaluates the corresponding resource policies (bucket policy, bucket ACL, and object ACL) at the same time. A user must have permission from the parent account to perform the operation. This step applies only if the request is made by a user in an AWS account. If the request is made using the root credentials of an AWS account, S3 skips this step.

b) Bucket context:

In the bucket context, S3 evaluates policies owned by the AWS account that owns the bucket. If the request is for a bucket operation, the requester must have permission from the bucket owner. If the request is for an object, S3 evaluates all the policies owned by the bucket owner to check if the bucket owner has not explicitly denied access to the object. If there is an explicit deny set, S3 does not authorize the request.

c) Object context:

If the request is for an object, S3 evaluates the subset of policies owned by the object owner.

Block Public Access

By default, new buckets, access points, and objects don’t allow public access. However, users can modify bucket policies, access point policies, or object permissions to allow public access. S3 Block Public Access settings override these policies and permissions to limit public access to these resources.

S3 Block Public Access provides four settings. These settings are independent and can be used in any combination. Each setting can be applied to an access point, a bucket, or an entire AWS account.

The following table contains the available settings.

Name	Description
`BlockPublicAcls`	Setting this option causes the following behavior: - PUT Bucket ACL and PUT Object ACL calls fail if the specified ACL is public. - PUT Object calls fail if the request includes a public ACL. - If applied to an account, then PUT Bucket calls fail if the request includes a public ACL. When this option is set, the specified operations fail, however, existing policies and ACLs for buckets and objects are not modified.
`IgnorePublicAcls`	Setting this option causes S3 to ignore all public ACLs on a bucket and any objects that it contains. This setting enables to safely block public access granted by ACLs while still allowing PUT Object calls that include a public ACL (as opposed to `BlockPublicAcls`, which rejects PUT Object calls that include a public ACL). Enabling this setting doesn’t affect the persistence of any existing ACLs and doesn’t prevent new public ACLs from being set.
`BlockPublicPolicy`	Setting this option for a bucket causes S3 to reject calls to PUT Bucket policy if the specified bucket policy allows public access. Setting this option for a bucket causes S3 to reject calls to PUT Bucket policy if the specified bucket policy allows public access. This setting enables users to manage bucket policies without allowing them to publicly share the bucket or the objects it contains. Enabling this setting doesn’t affect existing access point or bucket policies. To use this setting effectively, apply it at the account level. A bucket policy can allow users to alter a bucket’s block public access settings. Therefore, users who have permission to change a bucket policy could insert a policy that allows them to disable the block public access settings for the bucket. If this setting is enabled for the entire account, rather than for a specific bucket, S3 blocks public policies even if a user alters the bucket policy to disable this setting.
`RestrictPublicBuckets`	Setting this option restricts access to a bucket with a public policy to only AWS service principals and authorized users within the bucket owner’s account. This setting blocks all cross-account access to the bucket (except by AWS service principals), while still allowing users within the account to manage the bucket. Enabling this setting doesn’t affect existing bucket policies, except that S3 blocks public and cross-account access derived from any public access point or bucket policy, including non-public delegation to specific accounts.

Encryption at Rest

Server-Side Encryption

S3 can encrypt objects before saving them on disks in its data centers and then decrypting them when the objects are downloaded.

There are three mutually exclusive options, depending on the strategy used to manage encryption keys.

a) Server-Side Encryption with S3-Managed Keys (SSE-S3)

Each object is encrypted with a unique key. As an additional safeguard, it encrypts the key itself with a master key that it regularly rotates.

b) Server-Side Encryption with Customer Master Keys (CMKs) in KMS (SSE-KMS)

There are separate permissions for the use of a CMK that provide added protection against the unauthorized access of objects in S3. SSE-KMS also provides an audit trail that shows when the CMK was used and by whom. Additionally, it is possible to create and manage customer-managed CMKs or use AWS-managed CMKs that are unique to the service and/or Region.

c) Server-Side Encryption with Customer-Provided Keys (SSE-C)

AWS customer manages the encryption keys, and S3 manages the encryption, as it writes to disks, and decryption when objects are accessed.

Client-Side Encryption

Encrypt data client-side and upload the encrypted data to S3. In this case, the AWS Customer manages the encryption process, the encryption keys, and related tools. To enable client-side encryption, there are two options:

a) Use a Customer Master Key (CMK) stored in AWS Key Management Service (AWS KMS).

b) Use a master key that stores within the application.

Encryption in Transit

Enforce encryption of data in transit Use HTTPS (TLS) to help prevent potential attackers from eavesdropping on or manipulating network traffic using person-in-the-middle or similar attacks. Only allow encrypted connections over HTTPS (TLS) using the aws:SecureTransport condition in S3 bucket policies.

Logging and Monitoring

Create CloudWatch Alarms CloudWatch allows the creation of alarms that sound upon changes in the configuration of an S3 bucket.

Enable CloudTrail Logs CloudTrail provides a record of actions taken by a user, role, or an AWS service in S3.

Enable S3 Access Logs S3 Server access logs provide detailed records about requests that are made to a bucket.

Data Resiliency

Enable Versioning Versioning is a means of keeping multiple variants of an object in the same bucket. With versioning, it’s possible to recover from both unintended user actions and application failures easily.

Enforce Object Lock S3 Object Lock blocks object version deletion during a customer-defined retention period so that it is possible to enforce retention policies as an added layer of data protection or for regulatory compliance. Object Lock can help meet technical requirements of financial services regulators (such as the SEC, FINRA, and CFTC) that require write once, read many (WORM) data storage for certain types of books and records information.

Setup S3 cross-region replication Replication enables the automatic, asynchronous copying of objects across S3 buckets. Buckets that are configured for object replication can be owned by the same AWS account or by different accounts.

Enable multi-factor authentication (MFA) Delete MFA Delete can help prevent accidental bucket deletions. If MFA Delete is not enabled, any user with the password of a sufficiently privileged root or IAM user could permanently delete an S3 object.

Defense in Depth

Use Amazon S3 Inventory S3 Inventory allows audits and reports about the replication and encryption status of objects for business, compliance, and regulatory needs.

Consider using AWS Macie AWS Macie uses machine learning to automatically discover, classify, and protect sensitive data in AWS. Macie recognizes sensitive data such as personally identifiable information (PII) or intellectual property.

Enable AWS Config AWS Config enables one to assess, audit, and evaluate the configurations of AWS resources. AWS Config monitors resource configurations, allowing the evaluation and comparison of recorded configurations against desired secure configurations.

References

AWS S3 Security AWS S3 Security Best Practices AWS S3 Data Durability AWS S3 Encryption AWS S3 Server-Side Encryption AWS S3 Client-Side Encryption AWS S3 Managing Access Control AWS S3 Access Control using Policies AWS S3 Access Control using ACLs AWS S3 Block Public Access AWS S3 Incident Response AWS S3 Maintaining Compliance AWS S3 Disaster Recovery Bleepingcomputer - US military database holding web monitoring data left exposed online Bleepingcomputer - top secret US army and NSA files left exposed online on amazon s3 server