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?”
There are 5985 AWS privileges. 2505 (42%) have no condition restrictions possible (other than the global conditions) and can only use a resource of *.— Scott Piper (@0xdabbad00) August 13, 2019
ec2 is the "worst" service with 259/338 (76%) privileges that cannot be restricted beyond * access. :(
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.
A brief reminder why you should disable Cloud-Init after bootstrapping your AWS EC2 instances. If not, an attacker with EC2 'ModifyInstanceAttribute' permissions - which doesn't appear to be resource limitable - could trivially backdoor / shell EXISTING instances. (1/N) pic.twitter.com/oeydB0AcqG— Darkarnium (@Darkarnium) November 22, 2018
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*.*
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.
First published here