By Vinissius Fernandes
Privilege escalation in AWS consists of having sufficient permissions for access through other functions/users/groups, being able to chain escalations until gaining administrative access to an organization.
Threats arising from security incidents are often linked to:
- Compromised credentials: especially those with low entropy passwords and/or those that aren’t changed frequently;
- Vulnerabilities: sometimes unfixed. The lack of patching often results in security breaches;
- Misconfiguration: regarding the security options available;
- Malware: which often uses evasion and stealth techniques to steal information and/or grant remote access to the attacker;
- Social Engineering: which is the usual result of deficiencies in security awareness, which allows people’s knowledge to be compromised.
Specifically regarding misconfiguration, it’s not easy to solve this process, since it’s not common for a team to be qualified in cybersecurity. In these cases, when an application or other workload is implemented, often in search of some kind of convenience, it is possible to create faulty permissions.
Normally, the attack on an infrastructure follows a process known as the cyber kill chain, which, apart from the discovery processes, can be summarized as:
The document published by Cybersecurity Insiders 2023, entitled “Cloud Security Report” (available at https://global.fortinet.com/lp-en-ap-2023cloudsecurityreport), states that, for several reasons, 59% of those surveyed consider misconfigurations to be one of the major threats to cloud security:
It’s important to note that although we’re referring here to 2023, misconfiguration was also considered the main threat in 2022.
Exploiting IAMFullAccess
For any permission given, it’s necessary to assess the risks involved, especially regarding the use of wildcards, as, for example, in the AWS IAMFullAccess managed policy, which has the code:
{
“Action”: [ “iam:*“, (…)],
“Effect”: “Allow“,
“Resource”: “*”
}
Notice that the code above allows (“Effect”: “Allow”) actions on any resource (“Resource”: “*”), which wouldn’t be such a problem if the actions were specific. But there is an iam:* action that erroneously gives a list of permissions in IAM, which includes some of the following:
- iam:CreateGroup, iam:PutGroupPolicy and iam:AttachGroupPolicy allows you to manipulate group permissions;
- iam:CreateUser, iam:ChangePassword, iam:AddUserToGroup, iam:PutUserPolicy and iam:AttachUserPolicy allows you to operate user permissions;
- iam:CreateRole, iam:AttachRolePolicy and iam:CreateServiceLinkedRole to handle permissions related to roles;
- iam:CreateAccessKey and iam:CreateLoginProfile to use programmatic access;
- iam:CreateVirtualMFADevice, iam:EnableMFADevice to handle multi-factor authentication;
- Among many others.
Be aware that when you lose control of the permissions assigned, you increase the risk of compromise. This behavior is often unexpected due to the overuse of wildcards.
In the following example, we’ll create an IAM user with iam:AttachUserPolicy permission, being excessive and which we’ll exploit to grant the user administrative access::
Notice that the initial configuration was created using a user who had administrative permissions, but we’ll show you when the user who is the object of this escalation is used.
The following image shows the creation of the “scale” user, which will be used later to create privileges:
The misconfiguration occurring when the IAM FullAccess policy is attached to the “scale” user is shown below:
To do so, the following command was used:
aws iam attach-user-policy –user-name scale
–policy-arn arn:aws:iam::aws:policy/IAMFullAccess
Where –policy-arn is the identifier of the applied policy.
The image below shows the creation of programmatic access credentials:
In the image below, the original administrative credentials have been replaced by those of the “scale” user:
From this point on, only the “scale” user will be used.
Note that the “scale” user has limited permissions, as shown in the image above (no access to services such as S3 and EC2):
The “scale” user is attaching an administrative access policy (arn:aws:iam::aws:policy\AdministratorAccess) to itself.
Once these administrative permissions have been given, the “scale” user now has access to all services, including S3 and EC2. In other words, privilege escalation has taken place successfully.
New privilege escalation process
Once again we’ll explore similar privilege escalation. However, this time with a permission that also exists in iam:* called iam:CreatePolicyVersion, which allows you to create a new version of a policy.
As a result, the following image illustrates that the existing policies for the user “scale” have been deleted, and a managed policy called IAMFullAccess is assigned:
The “scale” user, despite existing, has limited permissions, with no access to S3 and EC2, as shown in the image below:
In the image above we see that the user “scale” is already created with:
- a policy assigned to the “scale” user that contains the privilege iam:CreatePolicyVersion;
- the access key that will be used next has already been created and is still being used in AWSCLI, as shown in the image below:
Next, as shown in the following image, a file called PermiteAdmin.json has been created.
And from this file, a managed policy can be created:
In the following image, the command was executed:
aws iam attach-user-policy –user scale
–policy-arn arn:aws:iam::742751911445:policy/PermiteAdmin
Where –policy-arn is the identifier of the applied policy, as shown in the previous image.
From the console we slightly alter the existing policy to create different versions of the same policy. Note that one of the versions is marked as “Default”:
The attacker’s intention is to make version 1 the default. To do this, it’s necessary to find out the “VersionId” of the policies in order to modify the default version:
The following figure shows the modification of the default policy:
After making this move, the “scale” user can execute the commands relating to S3 and EC2:
Conclusions
In order to protect against this type of escalation, it’s necessary to be aware of the risks of assigning too many privileges. It’s advisable to use specific policies, particularly when they allow access.
We haven’t observed similar behavior in policies that deny access, and even less so when it comes to actions that are double denied with the NotAction term.
Always try to give users as little permission as possible so that they can perform their duties.
Also, exercise extra caution when assigning a privilege, try to use “permission boundaries” to restrict the access that a managed policy can grant to IAM entities, such as users (these may or may not be federated), groups and roles (these may or may not be assumed).
In our specific case, we’re dealing with misconfiguration, but protection against other threats is also necessary. Having a multidisciplinary team that is well trained in the solutions used is an indispensable condition.
References
AWS Security Blog, “How to use the PassRole permission with IAM roles”, 2023. Available at: https://aws.amazon.com/blogs/security/how-to-use-the-passrole-permission-with-iam-roles/
Blog BeyondTrust, “Privilege Escalation Attack & Defense Explained”, 2023. Available at: https://www.beyondtrust.com/blog/entry/privilege-escalation-attack-defense-explained
Cybersecurity Insiders, “Cloud Security Report”, 2023. Available at: https://pages.checkpoint.com/2023-cloud-security-report.html
OWASP, “Testing for Privilege Escalation”, 2020. Available at: https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/05-Authorization_Testing/03-Testing_for_Privilege_Escalation/.
RhinoSecurityLabs. “Intro: AWS Privilege Escalation Vulnerabilities”, 2018. Available at: https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/.
