AWS API calls that return credentials

AWS API calls that return credentials.md

• chime:CreateApiKey
• codepipeline:PollForJobs
• cognito-identity:GetOpenIdToken
• cognito-identity:GetOpenIdTokenForDeveloperIdentity
• cognito-identity:GetCredentialsForIdentity
• connect:GetFederationToken
• connect:GetFederationTokens
• ecr:GetAuthorizationToken
• gamelift:RequestUploadCredentials
• iam:CreateAccessKey
• iam:CreateLoginProfile
• iam:CreateServiceSpecificCredential
• iam:ResetServiceSpecificCredential
• iam:UpdateAccessKey
• lightsail:GetInstanceAccessDetails
• lightsail:GetRelationalDatabaseMasterUserPassword
• rds-db:connect
• redshift:GetClusterCredentials
• sso:GetRoleCredentials
• mediapackage:RotateChannelCredentials
• mediapackage:RotateIngestEndpointCredentials
• sts:AssumeRole
• sts:AssumeRoleWithSaml
• sts:AssumeRoleWithWebIdentity
• sts:GetFederationToken
• sts:GetSessionToken

This one is really interesting. I was reading about how to link up AWS Chatbot to Slack and thought about the potential for using Slack as an attack vector. Seems like AWS has anticipated this; the AWS Chatbot documentation says here that they do not support commands denied by the following IAM Policy:

{
  "Statement": [
    {
      "Action": [
        "appsync:ListApiKeys",
        "chatbot:*",
        "codecommit:GetFile",
        "codecommit:GetCommit",
        "codecommit:GetDifferences",
        "cognito-idp:*",
        "cognito-identity:*",
        "connect:GetFederationToken",
        "dynamodb:BatchGetItem",
        "dynamodb:GetItem",
        "ec2:GetPasswordData",
        "ecr:GetAuthorizationToken",
        "ecr:GetLogin",
        "gamelift:RequestUploadCredentials",
        "gamelift:GetInstanceAccess",
        "lightsail:DownloadDefaultKeyPair",
        "lightsail:GetInstanceAccessDetail",
        "lightsail:GetKeyPair",
        "lightsail:GetKeyPairs",
        "iam:*",
        "kms:*",
        "redshift:GetClusterCredentials",
        "sdb:*",
        "secretsmanager:*",
        "sso:*",
        "sso-admin:*",
        "sso-oidc:*",
        "storagegateway:DescribeChapCredentials",
        "sts:*",
        "s3:GetObject",
        "s3:HeadObject",
        "snowball:GetJobUnlockCode"
      ],
      "Effect": "Deny",
      "Resource": "*"
    }
  ],
  "Version": "2012-10-17"
}

There is a strong overlap between that list and the ones provided on my list above.

If you are looking to prevent Data Exfiltration and Credential Exposure, I would suggest blocking the combination of both of these.

Note: I reflected this in a recent blog post: https://kmcquade.com/2020/12/sensitive-aws-api-calls/.