Demystifying privilege escalation in Oracle Cloud

As a security company, Tenchi has been investing in research since day one, even before we had our product Zanshin! We have presented our findings at major international conferences in the past years like BSides Las Vegas and DEF CON Cloud Village, but today we are happy to share that we hit another milestone. Our research team will present their latest research at fwd:cloudsec, in the words of Google’s Gemini: 

“fwd:cloudsec is a niche security conference focused on the ever-evolving landscape of cloud security. It gathers experts and enthusiasts to discuss critical vulnerabilities, insecure defaults, and best practices for building secure cloud environments. Unlike broader security conferences, FWD:Cloudsec emphasizes in-depth technical discussions, making it valuable for those working on the frontlines of cloud security.”

In June 2024 we will present the talk “The Oracle Awakens: Demystifying Privilege Escalation in the Cloud” where we discuss the technical side of privilege escalation in the Oracle cloud! If you are not familiar with the concept of Privilege escalation, stick with us and we will clarify it.

Privilege Escalation

Privilege escalations happen when an attacker exploits weaknesses (vulnerabilities or misconfigurations) to obtain more control within a system or network. This concept applies to any system in which you have different roles or privileges. For example, in Linux a regular user could be able to somehow exploit a vulnerability or a misconfiguration to get root privileges, or a regular user in a Windows system that can impersonate NT/System tokens could become SYSTEM, and so on. 

This kind of behavior exists in cloud environments as well. The late Spencer Gietzen, during his stint at Rhino Security Labs was one of the first to investigate techniques of privilege escalation in AWS, some researchers found paths of privilege escalation in Azure, examples here and here and in Google (GCP) cloud that cover the majority of the market share in the cloud. Other Cloud providers are increasing their market share, and we need to start paying attention to them as well. Because the attackers certainly will.

The Oracle Awakens

As Oracle Cloud Infrastructure (OCI) improved its presence among our clients, we started to research more about Oracle’s services to improve our ruleset of misconfiguration detections for Zanshin. We will divide this blog post into two parts: This one, with the basics of Oracle IAM and how it is possible to break privilege boundaries, and a second one with more examples and mitigation.

Oracle Cloud Infrastructure’s IAM

OCI’s IAM is divided into multiple identity domains. Your tenant will have at least one identity domain at all times, but you can also create additional ones as desired or needed.

Identity domains can contain users, authentication configurations, groups, and more. It can be useful to create an additional Identity Domain, for example, to segregate between production and development users. 

Policies, on the other hand, are scoped to compartments and their children. Each policy contains one or more rules that specify users’ permissions to certain resources. Unlike other cloud providers, OCI uses a policy syntax that is very close to our natural language. This makes the policies extremely easy to read and understand but makes performing automatic operations or analysis harder. For example, a common policy may look something like this:

“ALLOW group HelpDesk to MANAGE users in TENANCY”

Another interesting aspect of policies is that you can only grant permission to groups, never specific users. This helps maintain an organized IAM inside your tenancy.

However, inspecting which resources a user has access to is hard, because it involves manually reviewing the policies that mention each group they belong to. It is also hard to verify which users have access to a specific resource for the same reason. You can use access governance for this, but it is a separate solution with a cost for each user you’re analyzing.

So, to make things clear: you may have one or more Identity Domains with multiple users and groups of users, and then inside your compartments, you have policies that grant permission to these groups. 

Unfortunately, this can become complex: although you have these different “containers” for users and permissions, they all grant permissions to the same environment (that is, your OCI tenant). To put it in perspective, it’s as if you had multiple, isolated ADs that grant permissions for the same Windows domain, or if you had multiple IAM configurations for the same AWS account, or even if your phone had multiple passwords you could use.

In practice, this means that you must ensure the safety of each Identity Domain separately. For each one, you must check for inactive users, unsafe password policies, weak MFA settings, and if there are no groups with unnecessary members. It can be easy to place a user in a privileged group they should not belong to, and if you have several domains, it may be hard to find such a misconfiguration.

Another interesting aspect of OCI’s IAM is Dynamic Groups. These are groups of instances that are defined in one of your Identity Domains using special rules. If a policy grants permission to a Dynamic Group, then all instances that belong to said group will have these permissions. This is extremely similar to how you can grant a role to an Amazon EC2 instance, or how you can attach a Service Account to a GCP instance. However, coupled with OCI’s natural language approach, fragmented Identity Domains, and the fact that there is no easy way to check which dynamic groups an instance belongs to (or which instances belong to a dynamic group), you may easily have an instance with excessive permissions in your environment.

Privilege Escalation through excessive privileges

Now that we’ve given a general overview of how OCI’s IAM works, we can talk about the first category of privilege escalation methods: excessive privileges.

This type of privilege escalation happens when a user or group has sufficient permissions to grant themselves further permissions. 

An obvious case is:

• If a user has permissions to modify existing policies, they may grant administrative privileges to themselves or other users.

However, some cases are not obvious:

• If a user has permission to USE or MANAGE both GROUPS and USERS, they can add users to groups. Since privileges are assigned to groups, they can add themselves to groups to gain more privileges.
• If a user has access to an instance that belongs to a dynamic group with more privileges than they have, they can enter the instance and run commands using the instance’s privileges
• Similarly, if a user has permission to create instances, they may create an instance designed to be part of an existing dynamic group (e.g.: by using a specific tag), and then log into that instance to use its privileges.
• If a user has permission to MANAGE USERS, they can create API keys for other users, which in practice allows them to impersonate these users.

Let’s see an example in practice:

Here we have a regular user, inside a group with  only a single policy referencing it:

Logging in as this user, we can see he can read instances and use groups and users, but there are still many objects he cannot access.

However, due to his USE permissions for USERS and GROUPS, he is able to include users (including himself) into any group. He can use this to insert himself into a group which has more privileges, such as this one:

After adding himself to this privileged group, he has gained permission to manage all resources in the tenant. For example, he can now see the buckets he couldn’t before, and can also create new ones. He is an admin, in practice.

Mitigation

Currently there is no easy way to mitigate this kind of problem. You have to be very vigilant in your IAM deployment and manually review the policies in your compartments and groups in your Identity Domains.

For the next blogpost we will further explore other privilege escalation techniques in OCI, if you are a current user of Zanshin expect new rules detecting this and other privilege escalation techniques! Stay tuned !

Meet us!
Tenchi Security is heading to RSA Conference 2024 this May! We're excited to connect with security professionals like you who are passionate about Third-Party Cyber Risk Management, and building robust cloud security posture.Whether you're facing challenges managing your third parties or want to learn more about our innovative solution, get in touch!.

‍