CVE-2024-4142 Privilege Escalation in Jfrog Artifactory

When I was feeling bored and scrolling down the twitter, suddenly I catched up a status https://twitter.com/matthias_kaiser/status/1786264686146560251

Immediately I downloaded Jfrog artifactory to audit it.

1. Vulnerable fix

The code didn't change much, I got the change after a few minutes

Basically, in vulnerable version, Jfrog developer team checked the requested group names with the function AppliedPermissionsScopeToken.isIdentityToken, meanwhile in fixed one they removed that check.

Now let's start to find out what was happened.

2. Finding the source

I will summerize the way from source to that sink:

org.artifactory.rest.resource.token.TokenResource#createOrRefreshToken
  --> org.artifactory.rest.resource.token.TokenResource#createToken
    --> org.artifactory.security.access.AccessServiceImpl#createToken(org.artifactory.api.security.access.TokenSpec)
      --> org.artifactory.security.access.AccessServiceImpl#createToken(org.artifactory.api.security.access.TokenSpec, boolean, boolean)
        --> org.artifactory.security.access.AccessServiceImpl#assertLoggedInCanCreateToken
          --> org.artifactory.security.access.AccessServiceImpl#assertNonAdminUserCanCreateToken
            --> org.artifactory.security.access.AccessServiceImpl#assertValidScopeForNonAdmin(java.util.List<java.lang.String>)
              --> org.artifactory.security.access.AccessServiceImpl#assertValidGroupsForNonAdmin

The API that is handled by org.artifactory.rest.resource.token.TokenResource#createOrRefreshToken is /artifactory/api/security/token

This API is well described here https://jfrog.com/help/r/jfrog-platform-administration-documentation/access-tokens

This API is used to create a token, with the username and the scope is taken from user input (and basic authorization or bearer). The first parameter is username, which is equal with current context user

But, the funniest thing here is scope parameter, where user and input the scope for this API token. There are 9 types of scope that are accepted (well described in the above document, or you can take it when debugging)

I wont go to the detail of each one, but I will present more carefully about all that are related. The first 2 are applied-permissions/groups: and member-of-groups:, will assign group's permission for the token. And other is applied-permissions/user - provides user access. If left at the default setting, the token will be created with the user-identity scope, which allows users to identify themselves in the Platform but does not grant any specific access permissions.

We can grant one or more scopes for the token, by adding space character in scope value. It is handled by org.jfrog.access.util.TokenScopeUtils#splitScopeToList.

It checks if there is a character in the value of scope, it will break the string and add them to the list.

To sum up, if you want to grant permission of more than one group, you need to send a request with parameter like:

username=TEST&scope=member-of-groups:test%20applied-permissions/groups:readers

The scope will equal ["test","readers"].

Now, back to the vulnerable location.

I will explain briefly: they check if the number of group is not equal 1, or requested groups not contain *, and AppliedPermissionsScopeToken.isIdentityToken(scope) == false.

Go to org.artifactory.security.access.AppliedPermissionsScopeToken#isIdentityToken, it checks if scope has applied-permissions/user.

So, whenever in the scope has applied-permissions/user, the token is created (with permission of other groups we input).

Imagine if the server have a group with administrator permission, can we assign it to the token?

To verify my hypothesis, I created a uesrname test, a group named admin with admin privilege. Then I sent a request with 2 group: readers (test belongs to) and admin (test doesnt belong to)

The result show that it is not accepted. Then I changed to member-of-groups:admin%20applied-permissions/user

I got a token. Now, use that token to check if I can use it with admin privilege

Yes it is.

3. Summarize

This is a vulnerabilty that is hard to exploit in the real world in my opinion, because the server need to have a admin group first (we need to know the name), and enable for anonymous access if we want a full authentication bypass vulnerability.

I am not sure it is the original vulnerability of the author, maybe there is another way to exploit it with other scopes. Waiting for any experts to explain it if they did it.