Share
Embed
An attacker’s guide to AWS Access Keys
An attacker’s guide to AWS Access Keys
Bharath
August 27, 2022
Transcript
27 slides
-
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" -
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/<random-uuid> 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