[Wroclaw #7] AWS (in)security - the devil is in the detail
1. AWS (in)security - the
devil is in the detail
Paweł Rzepa
OWASP Chapter Wroclaw
05.12.2017
2. • Senior Security Consultant in SecuRing
• OWASP member:
• Helping arrange meetups in Wroclaw
• Contributor in OWASP MSTG project
• OSCP, eMAPT holder
• @Rzepsky
Who am I
3. 1. Intro to cloud technology
2. S3 leaks
3. Access keys leaks
4. New life of old vulns in cloud
5. Final recommendations
Agenda
4. • Amazon Web Services (AWS) – cloud solution provider
• Identity and Access Management (IAM) – a service for
controlling access to AWS resources
• Simple Storage Service (S3) – storage service through web
services
• Bucket – a container to store objects via S3 service
• Amazon Elastic Compute Cloud (EC2) – a service allowing
users to rent a virtual machine instance
Terms we’re going to use today
8. 7% of all S3 buckets have unrestricted public access*
* - based on https://www.skyhighnetworks.com/cloud-security-blog/verizon-data-breach-two-easy-steps-to-prevent-aws-s3-leaks/
21. • Some vulns can be much more dangerous in cloud:
CWE-200: Information Exposure
CWE-441: Unintended Proxy or Intermediary
CWE-611: XXE
CWE-918: SSRF
…because any of them may reveal your metadata.
Old vulns gain new life
22. SSRF in practice
Source: https://www.netsparker.com/statics/img/blogposts/exploiting_ssrf_vulnerability.png
23. Stories from HackerOne
SSRF reported, but
marked as “Won’t fix”,
because the risk was
marked as very low.
08.03.2015
Bounty granted: 0$ Bounty granted: 300$
Same bug reported,
but this time pointing
to exposure of
“meta-data”.
23.03.2015
24. • Data about your instance:
• Accessible only from within the instance
itself via link:
http://169.254.169.254/latest/meta-data/
What is “meta-data”
26. Restrict access to your data (ACLs, bucket policies, IAM
roles)
Audit your policies (e.g. cloudsploit)
Whitelist IPs
Define IAM roles
Use MFA for each role (you may find helpful aws-recipes)
Create an access keys management process
Sum up