AWS IAM is one of the most powerful and important services enabling secure access management to AWS services and resources. With AWS IAM, we can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources. AWS IAM was first launched in 2011, and it’s celebrating its 10th birthday this year. Almost every year, AWS announces some new features of AWS IAM. We’re expecting to hear some exciting news about new AWS IAM launches, additional settings, and configurations.
In this blog post, we will be focusing on AWS IAM from two different perspectives:
- From a Cloud Security Engineer/Auditor perspective, we will be talking about the AWS IAM Access Analyzer service that was launched in 2019 and saves us.
- From a Cloud Penetration Tester perspective, we will be talking about enumerating IAM users and which AWS service we can access. Let’s start!
At AWS re:Invent 2019, AWS announced the release of AWS IAM Access Analyzer that helps to identify unintended access to our resources and data which are shared with external entities. It analyzes the Amazon S3 buckets, AWS IAM roles, AWS KMS keys, AWS Lambda functions and layers, Amazon Simple Queue Service queues, and AWS Secrets Manager secrets. AWS IAM Access Analyzer performs this task by using logic-based reasoning to analyze the resource-based policies in our AWS environment. It generates a finding for each instance that is shared. Findings include information about the access and the external principal that it is granted to. We then review those findings to understand if the access is intended or not and take the appropriate action accordingly. We can also use the findings to preview the effects of newly deployed permissions.
When enabled, AWS IAM Access Analyzer creates an analyzer for the entire organization or the account that it is created for. The organization or account we choose is the zone of trust for the analyzer and the analyzer monitors all the supported resources within it. Any access to resources that are within our zone of trust is considered trusted. Once enabled, AWS IAM Access Analyzer analyzes the policies on supported resources in the zone of trust. After the first analysis, AWS IAM Access Analyzer analyzes these policies periodically. Access Analyzer analyzes it within about 30 minutes if a new policy is added or an existing policy is changed.
AWS IAM Access Analyzer is a regional service, analyzing only policies that are applied to resources in the same AWS Region that it is enabled in. To monitor all resources in the AWS environment, Access Analyzer must be enabled in each region where the supported AWS resources are used.
To configure and use Access Analyzer, your account needs some required permissions. Access Analyzer provides AWS-managed policies to help us get started quickly. The first one is “IAMAccessAnalyzerFullAccess”, which allows full access to Access Analyzer for administrators. The second one is “IAMAccessAnalyzerReadOnlyAccess”, and it allows read-only access to Access Analyzer. When we use this policy, additional policies must be added to IAM identities to allow them to view. To create an analyzer with the account as the zone of trust, please follow the following steps:
- Open the IAM console and then choose Analyzers
- Choose Create analyzer.
- On the Create analyzer page, confirm the Region where we want to enable the Access Analyzer. Enter a name for the analyzer, then choose the account as the zone of trust for the analyzer.
- Notice that when an analyzer is created to enable Access Analyzer, a service-linked role named “AWSServiceRoleForAccessAnalyzer” is created in the account.
To create an analyzer with the organization as our zone of trust, the steps are almost identical, the only difference being the chosen zone of trust. To do this:
- Choose the current organization instead of the current account. When an analyzer with the zone of trust organization is created, a service-linked role named “AWSServiceRoleForAccessAnalyzer” is created in each account of the organization.
- After creation, the status of the access analyzer can be observed from the analyzers tab.
Here, both analyzers in our account are in an active state. The analyzers can exist in one of four states: active, creating, disabled, and failed.
- Active means the analyzer is actively monitoring resources in the zone of trust.
- Creating means the analyzer’s creation is still in progress.
- Disabled means the analyzer is disabled due to some administrative action.
- Failed means the creation has failed due to a configuration issue.
AWS IAM Access Analyzer generates a finding for each instance of a resource-based policy that grants access to a resource within your zone of trust to a principal that is not within it. Findings are generated only once for each instance of a resource that is shared outside your zone of trust. Each time a resource-based policy is modified, AWS IAM Access Analyzer analyzes the policy. If the updated policy shares a resource that is already identified in a finding, but with different permissions or conditions, a new finding is generated for that instance of the resource sharing. If the access in the first finding is removed, that finding is updated to a status of resolved. The status of all findings remains active until they are archived or the access that generated the finding is removed.
After the AWS IAM Access Analyzer is enabled, we need to review findings to determine whether the access identified in the finding is intentional or not. Archive rules can be created to automatically archive specific types of findings. They can also be manually archived and resolved. To review findings, open the IAM console, choose the access analyzer, and choose the analyzer you want to view. Findings are displayed only if your account has permission to view findings.
The active, archived, and resolved findings can be viewed separately. The page displays some details about the shared resource and policy statement that generated the finding:
- The Resource column is the type and partial name of the resource that has a policy applied to it that grants access to an external entity not within the zone of trust.
- The External Principal is the principal, outside the zone of trust, that the analyzed policy grants access to. It can be an AWS account, any principal, a canonical user, an IAM role, or an IAM user.
- The Condition column is the condition from the policy statement that grants the access.
- The Shared Through column indicates how the access that generated the finding is granted. It can be a bucket policy, an ACL, or an access point.
- The Access Level column is the level of access granted to the external entity by the actions in the resource-based policy. The detailed view of the finding gives more information about this and can be accessed by clicking on the finding. Access level values can be list, read, write, permissions, and tagging.
- The Updated column gives a timestamp for the most recent update to the finding status, or the time and date at which the finding was generated if no updates were made.
We can use filters to display only the findings for a specific resource, account, principal, or other value. Select the property you want to apply a filter on to create a filter, then choose a property value. The filter options are automatically listed when you click on them. For example, to create a filter that displays only findings for resources that allow public access, choose the public access property, then choose “Public access: true”.
To archive findings from the findings page, select the check box next to the findings, then select Archive from the Actions menu. A confirmation should be displayed at the top of the screen.
To archive findings from the Findings Details page, choose the Finding ID for the finding to archive, then select Archive. A confirmation should be displayed at the top of the screen. To unarchive findings, repeat the steps, but choose to unarchive instead of the Archive. When a finding is unarchived, the status is set to Active.
To resolve findings generated from access that was not intended to be allowed, modify the policy statement to remove the permissions that allow access to the identified resource.
We can capture AWS users’ credentials when attacking their AWS environment in different ways such as in an S3 bucket, EC2 metadata, etc. After capturing AWS users’ credentials, we can access the other services in AWS, but there is a slight problem. How can we know which AWS service we have access to? If we try to check every service in AWS it’ll take a lot of time. To prevent this we’ll use a tool called enumerate-iam. This tool tries to brute force all API calls allowed by the IAM policy. The calls that happened by this tool are all non-destructive. As a result, this tool will list all of the services that are accessible.
Our prerequisites: kali linux 2021.1, python 3.9.2, pip3 20.3.4
We will download enumerate-iam from Github and install all requirements.
git clone https://github.com/andresriancho/enumerate-iam.git cd enumerate-iam/ pip install -r requirements.txt
To use this tool, we need to know the AWS access key and the secret key of the party we want to attack. To run the tool we need to add the access key and the secret key.
In this blog post, we’ve covered AWS IAM service from two different perspectives: red team and blue team. We’ve introduced different tools that could be lifesavers for your audit and cloud pen testing processes. We hope you find it helpful. Thank you for reading.
Check out our Cloud Security services to stay secure!