and non-expiring credentials. Generally tied to and IAM User. Temporary security credentials: short-term and expiring creds. Generally tied to AWS services.
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.
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
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
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
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
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
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
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"
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
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
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
Cognito and Identity Platform leading can provide an unautorised user with temporary credentials Casestudy Exploiting weak configurations in Amazon Cognito
- 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
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