Sensitive AWS API Calls That Return Credentials and Data

This morning, I was reading about how to link up AWS Chatbot to Slack. For one, I thought it would be cool to do this myself, and two, I thought about the potential for using Slack as an attack vector.

While reading the documentation, I saw that AWS has anticipated the potential to abuse AWS via Slack to some extent and designed accordingly. They have some limitations to running AWS CLI commands in Slack chat rooms. The ones that stood out:

• AWS Chatbot does not support commands to create, delete, or configure AWS resources (for example, to delete an S3 bucket).
• Users cannot display or decrypt secret keys or key pairs for any AWS service, or pass IAM credentials.

Previous work: AWS API calls that return Credentials

This reminded me of a previous Twitter exchange that Aidan Steele and I had about sensitive AWS API calls that return credentials of some sort:

What are all the #aws APIs that can vend AWS credentials? Off the top of my head:

* The sts:* family
* iam:CreateAccessKey
* sso:GetRoleCredentials
* iot:AssumeRoleWithCertificate

Any others? I’m sure I’m missing a bunch — and that worries me 😱

— Aidan W Steele (@__steele) December 26, 2019

We compiled an initial list of those API calls in my GitHub gist here, which I have also listed below with the corresponding links.

• 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

Other potentially sensitive AWS API calls

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. However, I noticed a few things missing:

• codepipeline:PollForJobs
• connect:GetFederationTokens (they provide connect:GetFederationToken, but not the tokens variation)
• mediapackage:RotateChannelCredentials
• mediapackage:RotateIngestEndpointCredentials

Conclusion

Given that my GitHub gist was the result of a Twitter conversation, and that AWS Chatbot documentation has an SLA and expectation of accuracy, I would suggest keeping an eye on that particular page for hints of what high impact API calls you might want to prevent via Permissions Boundaries or just more restrictive IAM roles.

Secondly, AWS should update their documentation to include the 4 missing API calls mentioned above.

And finally, if you are looking to prevent Data Exfiltration and Credential Exposure, I would suggest blocking the combination of both of these. That would be covered by the following Deny policy.

{
  "Statement": [
    {
      "Action": [
        "appsync:ListApiKeys",
        "chatbot:*",
        "codecommit:GetFile",
        "codecommit:GetCommit",
        "codecommit:GetDifferences",
        "codepipeline:PollForJobs",
        "cognito-idp:*",
        "cognito-identity:*",
        "connect:GetFederationToken",
        "connect:GetFederationTokens",
        "dynamodb:BatchGetItem",
        "dynamodb:GetItem",
        "ec2:GetPasswordData",
        "ecr:GetAuthorizationToken",
        "ecr:GetLogin",
        "gamelift:RequestUploadCredentials",
        "gamelift:GetInstanceAccess",
        "lightsail:DownloadDefaultKeyPair",
        "lightsail:GetInstanceAccessDetail",
        "lightsail:GetKeyPair",
        "lightsail:GetKeyPairs",
        "iam:*",
        "kms:*",
        "mediapackage:RotateChannelCredentials",
        "mediapackage:RotateIngestEndpointCredentials",
        "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"
}

Have any thoughts? Reach out to me over Twitter @kmcquade3. Public threads encouraged :)