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"
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 - 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
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