AWS Penetration Testing Part 2 – S3, IAM, EC2

Arrow

Penetration Testing AWS Services

AWS Penetration Testing Part 2.
S3, IAM, EC2

S3 and IAM Policies

Unlike ACLs and bucket policies, IAM policies are targeted at IAM users/groups instead of S3 buckets and objects. Using an IAM policy, we can give an IAM user limited access to S3 resources (or any AWS service in general). The following is an example IAM policy:

{
    "Statement": [
        {
            "Effect":"Allow",
            "Action": [ 
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject"
            ],
            "Resource":"arn:aws:s3:::examplebucket/*"
        }
    ]
}

This gives the IAM user assigned that policy read access to any object stored in the “examplebucket” S3 bucket as well as the ability to create and delete objects.

Note: The same tests for bucket policies are applied to IAM policies by the AWS Extender Burp extension; however, IAM user credentials must be supplied in this case.

Pre-signed URLs

In addition to the access control mechanisms listed above, S3 can allow temporary read/write access to private objects hosted in buckets via pre-signed URLs. Applications that use S3 to host mildly sensitive images such as avatar images are recommended to use pre-signed URLs to ensure images cannot be harvested by other users.

Pre-signed URLs typically look like the following:
https://s3.amazonaws.com/{S3_BUCKET}/{path}?AWSAccessKeyId={S3_ACCESS_KEY_ID}&Expires={expire_date}&Signature={signature}

Two checks are performed by the AWS Extender Burp extension:

  1. Whether or not authentication is enforced for objects referenced in pre-signed URLs.
  2. Whether the token is valid for an excessive amount of time.

The Intersection of Access Control Mechanisms

When more than one access control mechanism is applied, Amazon decides what to allow based on the union of all of them. For instance, if an IAM policy grants access to an object that a bucket policy denies, that object will not be accessible to the user as an explicit “DENY” rule always takes precedence over an “ALLOW” rule. And while any operation that does not have an appropriate “ALLOW” rule set is rejected by default, a lot of misconfiguration issues can arise due to various mistakes and misunderstandings on the bucket owner’s part; sometimes leaking very sensitive data publicly [4].

It’s also worth noting that Amazon S3 does not have a concept of hidden or internal buckets. As you might imagine, this creates an inherent security problem of bucket name enumeration, so some may consider that when choosing bucket names.

EC2 Metadata IP

AWS provides instance metadata for EC2 instances via a private HTTP interface only accessible to the virtual server itself. While this does not have any significance from an external perspective, it can however be a valuable feature to leverage in SSRF related attacks. The categories of metadata are exposed to all EC2 instances via the following URL:

http://169.254.169.254/latest/meta-data/

We commonly find that image and PDF rendering endpoints are susceptible to attacks such as this. If user generated content is used in conjunction with utilities such as wkhtmtopdf, it can be used as a vector to grab this data.

Cognito Authentication

AWS provides the capability to fully manage authentication of application users via Cognito authentication. This can be integrated with large identity providers like Google, Facebook, Twitter, and custom interfaces as well. This functionality also supports access for anonymous access where anyone can request an access token. Penetration testers should be aware of this behavior and be able to test for such cases.

Our plugin has the capability to test for unauthenticated access when an identity pool is discovered in proxy traffic, however penetration testers should not rely on this scenario for test coverage. Identity pool IDs may often be encoded in token requests sent to cognito-identity.amazonaws.com. Awareness of this behavior is a critical first step to verifying unauthenticated Cognito access. In such situations the plugin can be forced to make the test case by sending the extracted pool ID to any request parameter to allow the plugin to detect it.

Other Cloud Services

Many of the behavior described so far in this series applies to the other major cloud services such as Google and Azure. In part 3 we will look at more examples of those and how they can be tested as well. Please check back shortly!