Attacking AWS: the full cyber kill chain
While it is quite common practice to do periodic security assessments of your local network, it is really rare to find a company who puts the same effort for testing the security in their cloud. We have to understand what new threats and risks appeared with the cloud and how should we change our attitude to testing cloud security. The goal of my presentation is to show how security assessment of cloud infrastructure it is different from testing environments in classic architecture. I'll demonstrate a hypothetical attack on a company which is fully deployed in the AWS environment. I’m going to show the whole kill chain starting from presenting cloud-applicable reconnaissance techniques. Then I’ll attack the web application server hosted on EC2 instance to access its metadata. Using the assigned role, I’ll access another AWS EC2 instance to escalate privileges to the administrator and then present how to hide fingerprints in CloudTrail service. Finally, I’ll demonstrate various techniques of silent exfiltrating data from AWS environment, setting up persistent access and describe another potential, cloud-specific threats, e.g. cryptojacking or ransomware in the cloud. The presentation shows practical aspects of attacking cloud services and each step of the kill chain will be presented in a form of an interactive, live demo. On the examples of presented attacks, I’ll show how to use AWS exploitation framework Pacu and other handy scripts.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Attacking AWS: the full cyber kill chain
Similaire à Attacking AWS: the full cyber kill chain (20)
Plus de SecuRing
Plus de SecuRing (20)
Dernier
Dernier (20)
Attacking AWS: the full cyber kill chain
- 1. Attacking AWS: the full cyber kill chain Pawel Rzepa (pawel.rzepa@securing.pl)
- 2. IDS SIEM DLP Firewall - Is it safe? - F@#ck it, deploy! Cloud environment
- 4. www.securing.biz source: https://technodrone.blogspot.com/2019/03/the-anatomy-of-aws-key-leak-to-public.html Commit including AWS keys Amazon notifies about the leak First attempt to use leaked keys 0 55 sec 122 sec
- 5. www.securing.biz #whoami • Senior Security Consultant in - Pentesting - Cloud security assessment • Blog: https://medium.com/@rzepsky • Twitter: @Rzepsky
- 10. www.securing.biz
- 11. What is metadata? • Data about your instance • It's a link-local address, accessible ONLY from your instance! • May include access keys to Instance Profile: www.securing.biz http://169.254.169.254/latest/meta-data/iam/security-credentials/ http://169.254.169.254/latest/meta-data/
- 12. Dark side of the story www.securing.biz
- 13. www.securing.biz Somewhere in the other end of the Internet...
- 15. Identify the IP owner www.securing.biz Public AWS IP ranges: https://amzn.to/2EbvP0J Or use AWS EC2 reachability test: https://bit.ly/30274Ag
- 16. Demo: https://vimeo.com/363519636 www.securing.biz Exploiting SSRF to get metadata
- 18. The real story… www.securing.biz Source: https://bit.ly/2mhhvRb
- 19. www.securing.biz
- 22. Enumerate, enumerate, enumerate! Pacu (Domain Analytics:ec2_pivot) > run ec2__enum (...) Pacu (Domain Analytics:ec2_pivot) > data EC2 (...) VS www.securing.biz
- 23. There's a stopped instance (i-08d6cf0eaf210a552) with instance-profile/admin attached! www.securing.biz What can we find out there?
- 26. www.securing.biz Port 80 from 0.0.0.0/0 SSRF admin User Data reverse shell getting administrator access ec2_role
- 28. Staying under the hoodStaying under the hood
- 29. CloudTrail by default monitors all regions
- 30. CloudTrail: ways to hide your fingerprints
- 34. Persist access • Bind shell in User Data with backdoor in Security Groups • Lambda backdoor which creates IAM user when specific CloudWatch Event occurs • Backdoor via cross-account Trust Policy • Add extra keys to existing user www.securing.biz
- 36. www.securing.biz Without monitoring it’s hard to detect a 2nd key pair… even for legit administrator ! Demo: https://vimeo.com/334856167
- 37. www.securing.biz The real story… Source: https://bit.ly/30qQo5c
- 38. Let's switch perspective to the blue team www.securing.biz
- 39. www.securing.biz Mitigation: dynamically lock role’s credentials More: https://bit.ly/2HFJYtk
- 40. www.securing.biz Mitigation: separate access to logs AWS Organizations
- 41. www.securing.biz Mitigation: follow the AWS CIS Foundations Benchmark Source: https://bit.ly/2lP8fnb
- 42. Mitigation: aggregate security events www.securing.biz Source: https://bit.ly/2kPhYtp
- 43. How to detect all security issues? www.securing.biz
- 44. • Are there any extra, undocumented resources? • Is the system architecture free from design flaws? Cloud security assessment: architecture review www.securing.biz
- 45. Cloud security assessment: configuration review • Are all cloud services configured in compliance with best practices? www.securing.biz
- 46. • Are your applications free from vulnerabilities like RCE/SSRF/XXE etc.? • Is the Serverless code secure (e.g. free from "event injections")? Cloud security assessment: pentesting sensitive services www.securing.biz
- 47. • Do you monitor sensitive actions? • Do you have defined incident response procedure? Cloud security assessment: verifying monitoring processes www.securing.biz
- 48. Audit your cloud infrastructure Harden it. Repeat. www.securing.biz
- 49. 7-Step Guide to SecuRing your AWS Kingdom www.securing.biz https://bit.ly/2EN7yAs
- 51. If so, contact me on: pawel.rzepa@securing.pl Do you have any questions? Could you give me any feedback?