Blocking Privilege Escalation Attacks in Amazon Web Services (AWS)
By Gerben Kleijn
Security researcher Spencer Gietzen discovered and shared 21 privilege escalation attacks across Amazon Web Services (AWS) back in 2018. Gietzen’s work quickly became a valuable resource for others in the industry and I, personally, referred to it often as I hunted for privilege escalation paths in Bishop Fox client environments. I continually found myself wanting to create active tests in real-world environments for Gietzen’s theoretical attacks, and I decided to do exactly that and to share my findings with the community.
In this article, I’ll touch on these attacks at a high level, but the more technical breakdown and demo of each test are available on our Bishop Fox blog. We highly encourage you to share the technical post with your AWS administrator to ensure they know how to protect your organization against privilege escalation attacks.
During my threat modeling process, I realized that the techniques can be organized into five rough categories. My hope is that these categories can help IT and security professionals better understand how to secure their organizations against these real-world attacks.
- User Permissions – Avoid Unnecessary Risk by Controlling Access
User access permissions are some of the low-hanging fruit in the security world. It’s important to note that these simple misconfigurations should be assessed regularly to ensure that users only have the level of access that they need in order to do their work. The goal is to prevent attackers from easily gaining user access to your AWS instances, then going a step further to change passwords for users with more access privileges (or administrator privileges, in the worst case scenario), and pivoting into full access to your AWS.
Most AWS administrators know to prevent these types of attacks, but with many, many dangerous permissions, it can be a challenge to make sure your policies are sufficiently locked down and secured. An example of this is the fairly common use of policies allowingNotActions. When you use NotActions in policy Allow statements, you’re essentially creating a blacklist. All permissions not included on the blacklist are implicitly allowed. In our technical blog, we demonstrate some other permissions that can be used to escalate privileges and provide advice on how to lock down your identity and access management (IAM) permissions to prevent these types of attacks.
- Policy Permissions – Stop Users From Changing Permissions
- The Trust Policy (aka AssumeRolePolicy) – Lock Down This Powerful Access Gateway
While an AssumeRolePolicy (also referred to as a trust policy) could easily be part of the permissions policies category, we wanted to pay special attention to this powerful and often misunderstood policy. The AssumeRolePolicydefines which users are allowed to assume a role.
- iam:PassRole:* – Prevent Accidental Wildcard Resource Permissions
The iam:PassRole permission allows a user to pass a role to an AWS entity, which is a critical piece of AWS permissions and resource management. Many applications need to perform actions on the backend, which require extra permissions in order to function.
While created to allow for these permissions to be granted to trusted applications without administrator interaction, the iam:PassRole permission can be exploited by attackers unless appropriate roles are defined to block their access. One example we have seen in real environments is policies that allow the use of iam:PassRole on wildcard resources(iam:PassRole:*). This wildcard rule essentially allows users under this policy to pass any role that exists in the environment to AWS resources. The user could then escalate privileges by leveraging the affected resource to issue commands on the user’s behalf. In our technical breakdown, we walk you through what this looks like on the administrator side and demonstrate how to allow applications the access they need while still blocking privilege escalation attacks.
- Beyond Identity and Access Management (IAM) – Block Privilege Escalation Using AWS Services
The first four categories of attacks were directly tied to IAM permissions, but we want to focus now on the attack scenarios in which attackers escalate privileges using AWS services, such as Lambda and Glue. These two services can inadvertently allow attackers to execute unwanted commands to gain access to your AWS. Some other services, such as CloudFormation and Data Pipeline can also put your organization at risk if the attacker has the iam:PassRole permission we outlined above.
In Lambda, the permission to modify functions allows a user to update a Lambda function to perform privileged actions (password changes, etc.) on a user’s behalf. Similarly, the permission to modify a Glue development endpoint could allow an attacker to, for example, change the SSH key on an endpoint, log in, and then use it to perform privileged actions. For both of these types of attack, the risk depends largely on the function and endpoint permissions, but it’s best to block all unnecessary permissions in your AWS services to lower your inherent risk.
Key Takeaways
In each of these categories, organizations can mitigate the risk of privilege escalation attacks, or block them entirely, by carefully defining permissions and policies in their AWS instances. While time consuming, the best practice is to carefully list out the roles that each entity (user or service) is allowed to pass. Simply grouping your organization into “Users” and “Administrators” and granting them access accordingly can leave some significant risks built into your AWS instances, which would allow attackers to launch privilege escalation attacks against you.
Protecting against these types of attacks in AWS (as in most other environments) is to follow the principle of least privilege. What makes AWS more challenging to lock down than other environments is that many administrators are unfamiliar with some of the setup and access configurations. Alongside those tendencies to misconfigure AWS, new AWS services are continuously made available and they often carry their own distinctive configurations, adding to the confusion.
Our list isn’t exhaustive by any means, but we think this is a good start in helping your AWS administrators think about proactive ways to prevent privilege escalation attacks. We would also like to extend our special thanks to Spencer Gietzen for his original research.
