What is privilege escalation and why is it important to understand for security? Privilege escalation is when an adversary uses a number of techniques to gain higher-level permissions within a system or network, often the stage after initial access and discovery.
Adversaries can often enter a network with unprivileged access, but require elevated permissions to follow through on their objectives, according to MITRE. They’ll often take advantage of system weaknesses, misconfigurations and vulnerabilities to gain elevated permissions.
When it comes to detecting this type of attacker technique for cloud infrastructure, it can prove to be a more complex process. Why is privilege escalation identification challenging in AWS?
To start, let’s cover the normal process that someone might go through in order to set up an administrator role used to manage their AWS account.
{
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123456789012:role/Administrators"
}
]
}{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "sts:AssumeRole"
}
}
}
]
}Awesome – we just created the policy pieces that allow the user Admin to leverage the AdministratorAccess AWS managed policy by assuming the role called Administrators.
So how can this be abused?
First, realize that any user that has been granted rights to attach a role to a group and add someone to that group, potentially, can also grant themselves full administrative access.
Here’s a simple example of how this might occur:
Let’s say user Bobby is given attacher privileges to the group Dev_Test, where the resource section is * for the policy that grants this access. This would allow Bobby to attach Administrators to Dev_Test, allowing Bobby to assume the Administrators role and grant himself AdministratorAccess assuming they could also add accounts to the group.
Or let’s say Bobby has been granted the ability to create policies and creates a new version of a DevTestingPolicy that is already attached to the Dev_Test that’s identical to the first example – with one small tweak, it includes the “IsDefaultVersion”: true. In this example, “IsDefaultVersion”: true might mean that Bobby’s policy is leveraged instead of the intended policy (remember AWS can accommodate up to 5 versions of the same policy).
{
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123456789012:role/Administrators"
}
]
"IsDefaultVersion": true
}
This problem grows even more complex given that for any AWS Service to communicate with another service, it must leverage an IAM service role (think Lambda, Cloudwatch, S3, etc). Any misconfiguration or incorrectly configured policy, role, or group could potentially create a scenario where a user could have a path to escalate their privileges.
So what’s the answer?
The answer is specificity – use one rule for one resource and avoid wildcard usage if at all possible. Understand that granting AWS users the ability to modify a single policy, group, or role could potentially create a path to privilege escalation.
How do I detect and correct misconfigurations that may lead to privilege escalation in my AWS account?
Learn more about how Blumira can help with cloud security monitoring to help you identify misconfigurations and quickly respond to indicators of privilege escalation. Try it out by signing up for a free trial of Blumira’s cloud SIEM.