Configuration in AWS is difficult

Least privilege vs complexity explosion

I’ve been doing some research on credentials compromise and abuse in AWS. In the process, it was obvious that the main mitigation would be (is) to minimise the permissions assigned to the EC2 instance profile, applying the “least privilege principle”.

When the path is difficult to follow

However, sometimes assigning permissions is tricky and it is not easy to understand what a specific permission means.

What follows is just one example I found on the Internet (i.e. not original research)

Imagine you get non-privileged access to an instance that has a role with ec2:StopInstances, ec2:StarInstances and ec2:ModifyInstanceAttribute (or much commonly, ec2:*). With that premise, apparently it is not difficult to make your non-privileged user can escalate into a full “own”.

As I came to think while reading the following tweet … “do I know the implications of 5985 different privileges?”

Do you know what are the implications of those 5985 privileges?

It turns out that I don’t, and below you can find what it could happen if you don’t fully understand either the implications.

This is what can happen when you don’t understand implications for one of those 5985 privileges

I haven’t tested the steps detailed in those tweets, but it seems you can take control of a machine just by changing some configuration (ec2:ModifyInstanceAttribute) and restarting the instance.

You may need ec2:ModifyInstanceAttribute for a different reason and not be aware of the risk.

Conclusion

Beyond the specific compromise the important part is the tension between “least privilege principle” and the complexity explosion of understanding and assigning proper permissions.

I used to think that cloud computing, having a saner set of defaults than on-premises, would lead to a more secure setup by default.

But now… well … in the cloud there are ways to make things more secure. But the configuration is more complicated.

Stay tuned for part two.