By using AWS re:Post, you agree to the Terms of Use
/AWS Exposed Keys Alerts/

AWS Exposed Keys Alerts

0

AWS has a mechanism that detects exposed/compromised AWS API keys found in public github repos.

I have seen several areas in which AWS or third parties will state that a PutUserPolicy action will be initiated if this occurs and a policy called AWSExposedCredentialPolicy_DO_NOT_REMOVE will be applied to the user.

Places this policy comes up include:

However, I took the liberty of exposing a static AWS API user key in a public repo (the key had no permissions). Here's what actually happened:

  1. The action taken was AttachUserPolicy.
  2. The policy was a managed policy: AWSCompromisedKeyQuarantineV2.

So whats accurate? When if ever will AWSExposedCredentialPolicy_DO_NOT_REMOVE occur? If AWSExposedCredentialPolicy_DO_NOT_REMOVE doesn't occur, why do these researchers believe this and why can't AWS update their information?

1 Answers
0

Hi,

I am not actually 100% sure why these IAM policies have different names (AWSExposedCredentialPolicy_DO_NOT_REMOVE and AWSCompromisedKeyQuarantineV2), but looking at the contents of both it is safe to say that V2 has a lot more deny permissions under it.

Contents of the AWSExposedCredentialPolicy_DO_NOT_REMOVE can be found here: https://gist.github.com/0xdabbad00/b1ff2b09a1d04a401fa65ace48bd41e3

AWSCompromisedKeyQuarantineV2 has the following permissions:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "ec2:RequestSpotInstances",
                "ec2:RunInstances",
                "ec2:StartInstances",
                "iam:AddUserToGroup",
                "iam:AttachGroupPolicy",
                "iam:AttachRolePolicy",
                "iam:AttachUserPolicy",
                "iam:ChangePassword",
                "iam:CreateAccessKey",
                "iam:CreateInstanceProfile",
                "iam:CreateLoginProfile",
                "iam:CreatePolicyVersion",
                "iam:CreateRole",
                "iam:CreateUser",
                "iam:DetachUserPolicy",
                "iam:PassRole",
                "iam:PutGroupPolicy",
                "iam:PutRolePolicy",
                "iam:PutUserPermissionsBoundary",
                "iam:PutUserPolicy",
                "iam:SetDefaultPolicyVersion",
                "iam:UpdateAccessKey",
                "iam:UpdateAccountPasswordPolicy",
                "iam:UpdateAssumeRolePolicy",
                "iam:UpdateLoginProfile",
                "iam:UpdateUser",
                "lambda:AddLayerVersionPermission",
                "lambda:AddPermission",
                "lambda:CreateFunction",
                "lambda:GetPolicy",
                "lambda:ListTags",
                "lambda:PutProvisionedConcurrencyConfig",
                "lambda:TagResource",
                "lambda:UntagResource",
                "lambda:UpdateFunctionCode",
                "lightsail:Create*",
                "lightsail:Delete*",
                "lightsail:DownloadDefaultKeyPair",
                "lightsail:GetInstanceAccessDetails",
                "lightsail:Start*",
                "lightsail:Update*",
                "organizations:CreateAccount",
                "organizations:CreateOrganization",
                "organizations:InviteAccountToOrganization",
                "s3:DeleteBucket",
                "s3:DeleteObject",
                "s3:DeleteObjectVersion",
                "s3:PutLifecycleConfiguration",
                "s3:PutBucketAcl",
                "s3:PutBucketOwnershipControls",
                "s3:DeleteBucketPolicy",
                "s3:ObjectOwnerOverrideToBucketOwner",
                "s3:PutAccountPublicAccessBlock",
                "s3:PutBucketPolicy",
                "s3:ListAllMyBuckets"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

This leads me to think V2 is just that, perhaps just an updated version? The AWS blogs, documentation and articles are not 100% accurate, there are always bugs, false statements, or incomplete sentences I have found and reported over the years.

BTW, there is also a managed policy under the name "AWSCompromisedKeyQuarantine" (without the V2, which looks very similar to the contents of the AWSExposedCredentialPolicy_DO_NOT_REMOVE policy you mentioned).

Hope this helps.

answered 12 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions