This article is part of a complete guide to AWS Penetration Testing. We previously discussed S3 pentesting and will now cover EC2 and IAM security policies.
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.
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 such as wkhtmltopdf are susceptible to attacks such as this. If user generated content is used in conjunction with these utilities, it can be used as a vector to access 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!
