An attacker’s guide to AWS Access Keys 

get-speaker-identity Bharath Kumar Product Security Engineer AWS Certified Security Specialist 0xbharath https://disruptivelabs.in 

What are AWS Access Keys? AWS Access Keys are the credentials used to provide programmatic or CLI-based access to the AWS APIs. 

Types of AWS Access Keys? AWS Access Keys: Long term and non-expiring credentials. Generally tied to and IAM User. Temporary security credentials: short-term and expiring creds. Generally tied to AWS services. 

Components of AWS Access Keys Access Key ID: Unique identifier for a set of AWS Access Keys you’re using. (== username) Secret Access Key: the secret component of any set of credentials. (== password) Session Token - Required with temporary keys, passed in the X-Amz- Security-Token header or as query string. 

More on Access Key ID AWS does not consider an access key ID to be a secret as there negligible security impact. However, you can retrieve the AWS Account ID (not a secret) using a AWS Access Key ID which can be used in cross-account role enumeration and assume role attacks. aws sts get-access-key-info --access-key-id $AWS_ACCESS_KEY_ID 

Identifying Access Keys Key prefix Key type ABIA AWS STS service bearer token AKIA Access key tied to an IAM user ASIA Temporary (AWS STS) access key IDs 

How are AWS Access Keys used? Generally, they are added to a AWS Named Profile in ~/.aws/credentials Sometimes credentials are stored in OS Environment variables There are other secure alternatives such as AWS Vault aws configure --profile profile-name 

How/Where do attackers find AWS Access keys? Searching for leaked access keys in code repositories in application source code misconfigured CI/CD pipelines etc Gaining foothold into places where creds are stored (dev workstation) Exploiting application vulnerabilities to gain access to temporary credentials 

Searching for leaked AWS Access Keys There are pleothra of tools that can search for AWS Access Keys in files/ code repos based on regex and entropy. Trufflehog - https://github.com/trufflesecurity/trufflehog trufflehog github github --repo https://github.com/trufflesecurity/test_keys Gitleaks - https://github.com/zricethezav/gitleaks 

Service specific Access Key exploitation - EC2 Credentials associated with EC2 Instance Profiles are accessible via the Instance MetaData Service (IMDS), which lives at 169.254.169.254 An RCE/SSRF will provide you with access to IMDS service and in-turn AWS temporary credentials 

IMDS v1 An example curl command to get access keys from an instance running IMDSv1 is shown below: curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE-NAME Casestudy An SSRF, privileged AWS keys and the Capital One breach Finding SSRF via HTML Injection inside a PDF file on AWS EC2 

IMDS v2 AWS built a hardened version of the IMDS following breaches involving SSRF attacks. IMDSv2 has been launched but it is not made default yet. Request a token by submitting a PUT request to http://169.254.169.254/latest/api/token Make a request to other endpoints on the metadata service, passing the aforementioned token in the X-aws-ec2-metadata-token header. TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token"` && curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE-NAME \ -H "X-aws-ec2-metadata-token: $TOKEN" 

IMDS v2 Casestudy Exploitation of an SSRF vulnerability against EC2 IMDSv2 

Service specific Access Key exploitation - Lambda Lambda provides role credentials as environment variables An RCE/file read vulnerability will provide you with access to AWS temporary credentials In case of linux server with arbitrary file read vulnerability, you can access the credentials by accessing /proc/self/environ 

Service specific Access Key exploitation - Lambda Environment variables with AWS Temporary creds AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN 

Service specific Access Key exploitation - ECS ECS uses an IMDS but it is accessible at 169.254.170.2 and also the URI to access temporary creds contains a UUID. http://169.254.170.2/v2/credentials/ The AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variable in the container contains the UUID 

Service specific Access Key exploitation - ECS You’ll need an SSRF along with arbitrary file read vulnerability or an RCE to gain access to temporary credentials curl 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI SageMaker Notebooks, CodeBuild, App Runner, Batch etc are built on top of ECS so the exploitation steps stay the same for them 

Service specific Access Key exploitation - Amazon Cognito Mis-configured Amazon Cognito and Identity Platform leading can provide an unautorised user with temporary credentials Casestudy Exploiting weak configurations in Amazon Cognito 

AWS API calls that return access keys codepipeline:PollForJobs cognito-identity:GetCredentialsForIdentity iam:CreateAccessKey iam:UpdateAccessKey iot:AssumeRoleWithCertificate sso:GetRoleCredentials 

AWS API calls that return access keys sts:AssumeRole sts:AssumeRoleWithSaml sts:AssumeRoleWithWebIdentity sts:GetFederationToken sts:GetSessionToken 

What to do when you find AWS Access Keys? whoami - AWS equivalent After finding or stealing IAM credentials during an assessment you will need to identify what they are used for, or if they are valid. The most common method for doing so would be the get-caller-identity API call. aws sts get-caller-identity --profile PROFILE-NAME 

whoami - AWS equivalent sns:Publish will return the ARN of the calling user/role without logging to CloudTrail. To use this method, you must provide a valid AWS account id in the API call. This can be your own account id, or the account id of anyone else. aws sns publish --topic-arn arn:aws:sns:us-east-1:*account id*:aaa --message aaa 

Access Keys Enumeration Arsenal Enumerate IAM Trivy ScoutSuite Cloudsplaining CloudMapper 

References AWS Access Keys - A Reference AWS Access Key ID formats 

END 

No content