When I started my career I got super excited entering these dark rooms, with blinking lights and cold air. Yes, I'm talking about good old data centers, with old-fashioned server racks belonging to various clients. Whether you were replacing faulty hardware, debugging uplink issues or updating HP iLO, you felt like Mr. Robot before it was cool.

Then innovation happened! The average client noticed they did not want to buy servers, HDDs, racks and maintain all of that anymore. It was difficult to scale economically and fast, of course you could buy multiple dedicated servers in advance, ship them to the data center, mount and set them up but you locked up so much capital only to find out later that your capacity prediction was wrong leading to downtime or wasted resources.

As early as 2006, the market leader Amazon AWS started to offer its services as something called cloud computing. Today Amazon has a market share of more than 30%, leaving behind its competitors like Microsoft Azure or Google Cloud. With the cloud new business models and services were introduced:

• Infrastructure as a Service (Amazon EC2)
• Platform as a Service (AWS Beanstalk)
• Software as a Service (machine learning services like AWS Personalize)

No data center, server and server rack maintenance anymore! Cost-efficient elasticity for everybody! But wait, if you are not responsible for maintaining all of that anymore who does that? The cloud provider takes care of this but still the cloud requires your attention! Serverless doesn't mean you have no responsibility to keep your data secure and that's where the cloud gets complex.

Let's get started

BishopFox published a very cool testing environment that helps you understand the most common privilege escalation paths affecting your AWS IAM configuration. If you like it, buy Seth and Catherine a beer or coffee, they deserve it!

You can pretty much follow the Quick Start instructions but I want you to prevent running into the same issue as me. If the ARNs were not filled out in role trust policies in the terraform plan output and your terraform apply fails with MalformedPolicyDocument, don't start diving into the rabbit hole of AWS API race conditions like me but instead go to terraform.tfvars.example, uncomment aws_assume_role_arn and place the ARN of your account in there. Finally rename the file to terraform.tfvars and check if it was fixed.

privesc1-CreateNewPolicyVersion

Now the exciting stuff finally happens! Always make sure you are using the right profile (not your default admin account) before you start by running aws sts get-caller-identity --profile profile_name. You can think of this command a bit like "whoami".

I wanted to get some insights into what privileges I actually have but I quickly found out, that you need a specific privilege to list privileges. This was my first learning, I need a tool to bruteforce what functionality I'm allowed to access.

Fortunately there's a really cool one by Andres Riancho: https://github.com/andresriancho/enumerate-iam

After executing this I checked CloudTrail...well, I think everybody would notice that something is going wrong when looking at the logs. So be careful, this is very noisy! Apparently there was a way to enumerate privileges in a completely stealth way last year, unfortunately AWS fixed this though. Still, I recommend checking out: https://frichetten.com/blog/aws-api-enum-vuln/.

Note: I'm aware that I'm doing way too much enumeration because the targeted role only has the iam:CreatePolicyVersion and sts:AssumeRole privileges.

Quick insights into how a policy looks like, it will help you understand why access to CreatePolicyVersion is problematic:

Version = "2012-10-17",
    Statement = [
      {
        Action = "iam:CreatePolicyVersion"
        Effect   = "Allow"
        Resource = "*"
      },
    ]

Action defines what resources you are allowed to access or denied, the effect is either a deny or allow and resource defines which resources are affected (* means all). As the name indicates CreatePolicyVersion allows you to create a new policy, and it could look like this:

"Version": "2012-10-17",
   "Statement": [
       {
           "Sid": "Admin",
           "Effect": "Allow",
           "Action": "*",
           "Resource": "*"
       }]

This new policy allows you to access everything and anything now. You can apply it using aws iam create-policy-version --profile profile_name and start taking over the AWS account. ;-)

If you want to get quick visual insights what privilege escalation paths are possible within your account use PMapper, it builds beautiful graphs explaining the paths. Combined with manual checks for potential paths this will help you harden your AWS configuration.

I'll provide some more write-ups about my journey as I fully leverage the environment. Stay tuned!