Administrating the Administrator, An OCI Identity Domains Permission Bypass

Quick OCI 101

Compartments/Tenants

Compartments can also be nested. At the top of this nested hierarchy is the root compartment, commonly referred to as the “tenant compartment”. For simplicity, you can think of the tenant compartment as any other compartment in that you can create resources in it as well. The tenant compartment just has a slightly different Oracle Cloud Identifier (OCID). An OCID as a quick aside is similar to an AWS ARN or GCP resource identifier, it’s just a unique identifier every cloud resource has.

OCI IAM Policies

In other words, a policy attached higher in the compartment hierarchy may grant access to resources in compartments beneath it, subject to any conditions included in the policy.

Interestingly these OCI statements are created and gathered as shown above, as lexical sentences. There is no JSON, YAML, etc. serialization methods OCI offers. This would involve a ton of regex and parsing to even begin analyzing a large list of statements.

I built a tool to convert these OCI IAM policy statements into JSON for easier analysis: github.com/netspi/oci-lexer-parser. This can be used in any tools to analyze a list of JSONS instead of a list of freeform sentences.

Identity Domains

Moving into more OCI-specific territory, OCI has identity domains. An identity domain is a logical grouping of IAM-related resources such as users, groups, dynamic groups, federation settings, password policies, and related identity configuration.

Identity domains are just like any other OCI resource and can be created in compartments with arbitrary names. From what I have seen, a default identity domain at the tenant level is created automatically and is often used when an identity domain is not explicitly referenced. In general, I’ve observed this default identity domain is just called “Default”. Identity domains names are used when identifying a principal.

Applications and AppRoles

I should note I have found the documentation for app roles, applications, and grants a bit sparse or hard to understand. The descriptions below are how I understand the mechanisms at this point in time but would encourage you to do your own research if a point does not seem to align with behavior.

Within identity domains, OCI supports “applications” and users/groups can be assigned to “AppRoles” on those applications through “grants”. Per the name, AppRoles are not the same thing as classic OCI IAM policies. OCI IAM policies authorize access to OCI resources such as buckets, instances, and compartments. Identity domain AppRoles, on the other hand, authorize actions within the identity domain itself, such as administering users, groups, applications, or identity-domain settings. They involve more direct assignments of users and groups to the specified roles which in turn are scoped or assigned to a specific application.

Now, when you click into an identity domain in the OCI console, you will see there are some predefined roles like “Identity Domain Administrator” or “User Manager” under the “Administrators” tab that are already present upon identity domain creation. As I just mentioned, OCI documentation generally describes AppRoles as being assigned to applications. But the default administrator roles, such as Identity Domain Administrator and User Administrator, are already present in a new identity domain. So, the natural question is: what application are these roles attached to if I did not create one?

My understanding is that this is related to Oracle’s earlier Identity Cloud Service (IDCS) product being integrated into OCI. As part of that integration, the identity-domain administration model appears to be represented through this built-in IDCS application and its associated AppRoles. The TLDR is the “IDCS_Application” appears to be a system defined pre-existing background application that is tied to all the default administrator roles, so being assigned a role on the IDCS_Application would allow access to all identity resources.

Using the Python SDK, we can enumerate the applications and AppRoles in an identity domain. Tools such as OCInferno shown below can also surface this relationship. When doing so, these built-in administrator roles appear as AppRoles associated with a pre-existing IDCS application.

Built-in IDCS Application

Two Workflows for One Goal

By now, you may have noticed that OCI can expose two separate authorization paths for similar resources: classic OCI IAM policies and Identity Domain application roles. For example, suppose we want to create a long-lived API key for an IAM user named WebbinRoot, who resides in the Default identity domain. Assume that IdentityDomainA also exists elsewhere in the tenancy, such as within CompartmentABC.

There are two ways we can potentially obtain the required permissions:

1. OCI IAM policies: If the caller has permissions through a classic OCI IAM policy, such as: Allow group CallerGroup to manage users in compartment CompartmentABC the caller can create an API key through the classic OCI IAM API.
2. Identity Domain roles: If the caller has been assigned an administrator role such as Identity Domain Administrator in the Default domain, the caller can also obtain user-management permissions over WebbinRoot.

These are separate and additive authorization models.
A principal can have the relevant OCI IAM policies without having any Identity Domain application roles, or have an Identity Domain role without having the corresponding OCI IAM permissions. In either case, the principal may be able to perform the same logical operation against the same underlying user resource.

The API Path Depends on the Identity Domain

Before continuing, it is worth taking a brief aside to explain how the API paths relate to these permission models.

Each authorization model can be exercised through its own API endpoints, but there is some nuance around when each API can actually be used. Both authorization models can apply to resources associated with Identity Domains, but the API you use depends on the domain and, in some cases, how the required permissions were granted.

The following examples demonstrate each scenario:

Finding the Vulnerability

Having gone through the basics of OCI and untangled the classic OCI IAM and Identity Domain AppRole authorization models, I began looking more closely at what each AppRole could actually do.

The documentation is somewhat sparse in this area in my opinion, and the capabilities of each administrator role are often left to a degree of common sense and inference. My initial expectation was that Identity Domain AppRoles would provide interesting avenues for lateral movement and privilege escalation within an Identity Domain. For example, if I compromised a user with the User Administrator role, could I then target other users in the same Identity Domain who had additional permissions through classic OCI IAM policies?

To build the relevant edges in my BloodHound graph for OCInferno (see the talk recordings above), I needed to understand the actual authorization boundaries of each Identity Domain AppRole. Because the documentation did not fully spell out limitations, I resorted to testing the roles individually and building my own authorization matrix.

One of the first questions I wanted to answer was whether administrator roles could modify other administrator roles within the same Identity Domain. For example, could a User Administrator modify a user who had been assigned the Identity Domain Administrator role? If so, that could potentially provide a path from User Administrator to Identity Domain Administrator. And if that worked in one direction, was the reverse also possible?

To keep the testing isolated, I assigned my test principals to a dedicated test Identity Domain and gave them zero traditional OCI IAM permissions. This meant that any access observed during testing had to come exclusively from their Identity Domain AppRoles.

I quickly found that, although these boundaries are not clearly documented, OCI does appear to enforce protections between the different Identity Domain administrator roles. For example, when I authenticated as a user with the User Administrator role and attempted to change the email address of a user assigned the Identity Domain Administrator role, the request failed.

Looking at the underlying network traffic made the boundary even more explicit. The error indicated that the principal did not have permission to modify an Identity Domain Administrator. I unfortunately did not capture a screenshot of the response, but the network-level error was essentially along the lines of: "You can't modify this user because they are an Identity Domain Administrator."

It was during this testing that I encountered the unexpected behavior described below, which ultimately led to the issue I referenced in Oracle’s advisory. The procedures for this are listed below. My hypothesis is the API key belongs both to OCI classic IAM policies and Identity Domain AppRoles and the duplication of APIs and permissions led to this being missed.

Procedures

1

I created a brand new identity domain at the tenant compartment level.

Note: I created a starting user, “StartingUserIdentityAdmin” with an email I owned.

2

Clicking into the domain – StartingUserIdentityAdmin is an identity domain administrator ( as expected )

Note: the user is inherently in the Domain_Administrators group by default in the same domain.

3

Create a second user within the IdentityDomainPOC domain. This user is placed in NO starting groups. 

4

Add the second user, who is in no groups, to the User Manager administrator role.

Set the user to be able to manage all users.

5

At this point, sign in as both users in separate browser sessions.

As seen below, a browser session for StartingUserIdentityAdmin and LowerLevelUser.

6

As the lower level user, navigate to the Identity Domain user.

Try to change the Identity Domain admin’s email and recovery email. Note this is not allowed.

Note this is not allowed

7

Lower level user could NOT prompt a password reset or factor reset for the identity domain admin.

Seems to reinforce you shouldn’t be able to make an API key for the user.

8

As the lower-level user, navigate to the API Keys tab. Choose to add a key ( no authorization bugs )

A User Manager (not even User Administrator) can privilege escalate and become an identity domain admin with one API call.

The key is valid when I fetch the namespace ( below )

# cat ~/.oci/config
[DEFAULT2]
user=ocid1.user.oc1..aaaaaaaab4[REDACTED]
fingerprint=bb:fb:f6:1a:a8:fd:d5:6d:68:91:62:37:38:5b:99:2a
tenancy=ocid1.tenancy.oc1..aaaaa[REDACTED]
region=us-phoenix-1
key_file=/home/kali/Downloads/[TRUNCATED]
# oci os ns get --profile DEFAULT2
[TRUNCATED]
{
  "data": "ax[REDACTED]"
}

9

A User Manager could also create SMTP credentials and Auth tokens

10

Ensure this was not a policy granting permissions ( lower level user was purposefully placed in NO groups )

In addition, the latest policy in IAM statements is from February while this identity domain was created in March highlighting no IAM policies were granted/auto-created.

This image (below) was taken using a higher privileged user in my tenant since, as you know, the identity domain users used in the previous steps do not have permissions to see the policies.

OCI VDP Timeline

After submitting the initial report, Oracle handled the issue through its Vulnerability Disclosure Program (VDP).

The following is a timeline of the disclosure and remediation process.

Overall the process took approximately 3 months from the initial report to final validation. Unfortunately Oracle does not have a dedicated VDP portal similar to other cloud platforms so communications throughout the process was handled primarily through email as part of Oracle’s VDP.

One additional note for others considering research: Oracle’s VDP process does not currently provide monetary rewards for reports of this type, so there was no monetary bounty associated with this disclosure.

Conclusion

The boundary between OCI IAM and Identity Domain AppRoles provides an interesting avenue for lateral movement and privilege escalation. I incorporated some of these relationships into my OCInferno tool, which can be found here: github.com/NetSPI/OCInferno/.

It is important to clarify what Oracle’s fix does, and does not, prevent. The fix does not prevent a principal with appropriate OCI IAM permissions from creating API keys for users in an Identity Domain. For example, a policy such as Allow group MyGroup to manage users in MyCompartment can legitimately provide the necessary permissions, because OCI IAM policies and Identity Domain AppRoles represent two distinct authorization boundaries.

If you’re interested in testing OCI security in a real-world environment, reach out to the NetSPI team to learn more about their OCI security research and cloud pentesting services.