Prevent Breaches with AWS IAM Access Analyzer

Scenario

It’s your first day as blue team consultant for your client Huge Logistics, and you have set up several AWS-native services to supplement your existing security suite. Your goal now is to set up IAM Access Analyzer, identify what issues might be present and work to remediate them.

Walkthrough

Authenticate using given credentials

└─$ aws sts get-caller-identity
{
    "UserId": "AIDA4RAAI74V4HHEQBXJH",
    "Account": "861141532459",
    "Arn": "arn:aws:iam::861141532459:user/security"
}

Now we change the password to login to AWS console

└─$ aws iam update-login-profile --user-name security --password '<REDACTED>'

After authenticating to AWS console, navigate to Access Analyzer, which is contained and part of the Identity and Access Management (IAM) service. IAM Access Analyzer can be used to:

• Identify resources that are shared outside our “zone of trust” (AWS account)
• Identify IAM users and roles with assigned permissions that they do not use (and could potentially be safe to remove)

In Access Analyzer, click Create Analyzer

Select the default selection of External access analysis and click Create analyzer

Analyzer was created

Let’s analyze the findings. Set filter All instead of Active

We find the serious misconfiguration, where any AWS user has access to perform any action on the bucket

If we click the S3 bucket under Resource, it will open the tab with this bucket. We can see to_delete public folder, which contains AWS access keys

To address this issue, we would:

• disable the exposed AWS access key
• identify the AWS IAM user they belong to (kate)
• understand when the key has been used and what resources the user has been accessing

After that we focus on removing this access. Under Bucket policy, click the Edit button.

Now, replace the policy with a more restrictive one, that just allows access by the IAM users security and kate (if it’s confirmed by the security team as not compromised)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::861141532459:user/security",
          "arn:aws:iam::861141532459:user/kate"
        ]
      },
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::huge-logistics-tmp-44accbabeb8b/*",
        "arn:aws:s3:::huge-logistics-tmp-44accbabeb8b"
      ]
    }
  ]
}

Save the policy

Now if we Rescan the finding, we should see that status has been changed to Resolved

Let’s move to next finding related to the same S3 bucket. Any AWS account can list the contents of the bucket

Now, click on S3 bucket under Resources again and navigate to Permissions tab. There scroll to Access Control List (ACL) section and click Edit

We see the problematic ACL, so Untick the Everyone (public access): List setting and click Save changes

After rescaning the finding, it will be changed to Resolved status

Continue with the next finding. It shows that any AWS user that is aware of the bucket name would be able to list and read the bucket contents

Now, similarly as with the first findings, change the policy so that only the user Francesco (who adds and accesses customer data) and security should have access

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::861141532459:user/security",
          "arn:aws:iam::861141532459:user/francesco"
        ]
      },
      "Action": [
        "s3:GetObject",
        "s3:ListBucket",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::huge-logistics-custdata-44accbabeb8b",
        "arn:aws:s3:::huge-logistics-custdata-44accbabeb8b/*"
      ]
    }
  ]
}

Save the changes and rescan

Let’s resolve OrganizationAccessAccessRole finding next. According to documentation, this role is automatically created for any AWS account that is a member of an AWS Organization.

AWS Organizations is an account management service that allows businesses to consolidate multiple AWS accounts into an organization, which then share billing details (and optionally also AWS credits), and this also allows centralized management of resources

This configuration is intended, thus click Archive

Let’s move on to the next finding. We can see that EC2 EBS snapshot has been shared with the AWS account ID of a consultant.

The snapshot contained infrastructure as code backups that might have contained sensitive credentials, so remove access (Make sure that the credentials have already been rotated…). Click on the URL under Resources

Select the snapshot and click on the Actions menu and then select Snapshot settings > Modify permissions

Under the Shared Accounts section, selecte the target AWS account ID and click Remove selected, then Modify permissions

After permissions have been changed, rescan the finding to resolve it

It’s also possible to use Unused access analyzer, that identifies permissions that could potentially be removed (principle of least privilege). But this is a paid service (with cost based on the number of IAM users and roles in account). Still worth considering as part of risk reduction strategy. Overall, it’s really useful service, which is helpful in applying the principle of least privilege throughout cloud environment.