Cloud penetration testing: Not your typical internal penetration test
There seems to be a common path for experienced penetration testers who are thrown into the world of cloud penetration testing. I'm talking about internal (aka assumed breach) tests, where the goal is to demonstrate the impact of a compromised user with access to the cloud or a compromised application in the cloud.
The path usually starts with ignorance, is followed by total confusion and questioning everything you know about penetration testing, and ends with… well, it never ends. Why? Because the cloud providers and the cloud native technologies running in these clouds keep evolving at a remarkable rate. There's always more to learn and more attack paths waiting to be found.
I hope walking through my own path and defining the stages of ignorance and awareness I encountered in a playful way might help others progress through the early stages more quickly than I did.
Level 1: This is just like any other Internal Penetration Test, right?
You connect to your assumed breach starting point within the internal cloud network: something like Kali running on an EC2 instance. You run nmap against the VPC’s internal /16 and hope for the best. You quickly realize there might be a better way to do this.
Level 2: You get your first spark of harnessing cloud magic
You realize if you ask for and receive IAM credentials for the target environment, you can use those cloud credentials and the AWS API to enumerate the IP addresses of all the EC2 instances in the account, and then nmap only those IP addresses. You pat yourself on the back and think you might actually be a cloud security expert now. Unfortunately, you still think that the scope of the cloud attack surface is limited to the services running on EC2. Such a level 2 move.
Level 3: Woah. There is more than just EC2!?!
You realize if you have Route53 access, you can enumerate all of the A records in AWS managed DNS zones, and this makes you very happy. Lots of new attack surface area. You start to find things hosted by other services, like Kubernetes, ECS, API Gateway, ELB, etc. You might not yet realize what Kubernetes, ECS, API Gateway, and ELB do yet, but that's OK at level 3. The important thing is that you have more things to hack. Go find those services with default credentials, SSRF vulns, missing authentication, etc., and have some fun!
Level 4: You become woke to IAM PrivEsc
You start to learn about what IAM is and how it can be misconfigured. You learn about IAM privilege escalation. You exploit the ec2:RunInstance + iam:PassRole attack path and gain administrative access to the AWS account. Or, you pop a service and realize that service has an IAM role that can assume other IAM roles. You realize, like all of those before you, that Spencer Gietzen was a really smart dude who shared a ton of amazing info with the community, and you get hungry to learn more about IAM privesc. You should probably check out IAM Vulnerable at this point.
Level 5: A secret in the wrong place can be pretty bad
You start to look at other key AWS services like S3, Lambda, ECR, EKS, CloudFormation and you start to see patterns that lead to other (non-IAM) types of privilege escalation: A secret stored in the wrong place (S3 bucket object, Kubernetes secret, Lambda environment variable, EC2 user-data, etc.) can provide unintended privilege escalation opportunities. It reminds you of finding passwords in powershell scripts accessible via SMB shares and you get nostalgic.
Level 6: You start to think in graphs, and even work backwards
You are now always looking for secrets, vulnerable software, and misconfigured IAM policies in the environment. But when you find these, you now work backward and focus on who has access to that secret/vuln software/IAM policy, and you build and execute attack paths that demonstrate that user X has paths to the penetration test trophy targets. You also realize there can be relationships between AWS accounts, like how multiple Active Directory domains can be connected in a single forest. You look for ways that access from a lower-trust account can be used to gain access to the higher-trust accounts (e.g., role trusts) and your attack chains become even more impactful.
Level 7: CI/CD Tooling is a freaking gold mine
You're testing ACME corp, an organization that is fairly mature from a security perspective. Nobody has write permissions to the production cloud environments except for the Ops team and the automated deployment tooling. But, you realize all of the developers DO have access to the continuous deployment tooling, and as it turns out RBAC is not enforced here. You realize this means all developers have access to all of the secrets in the CI/CD tooling software, so you grab the admin creds to the production cloud environment, complete the assessment objectives, and do a victory dance. You file this in the "things I always need to look for" category. It rarely disappoints.Level 8: You start to think tech monopolies are a good thing
Level 9: I know nothing about the cloud
Honorable mentions:
- Why isn't Responder working as expected in the cloud?
- Hey Google: "What is cloud native?", "What is serverless?", and "What is Kubernetes?"
- Azure Active Directory is Azure's managed Active Directory, right? RIGHT!?
Comments