Skip to content

GHSA-8vg2-wf3q-mwv7 CVE-2023-28443

directus vulnerable to Insertion of Sensitive Information into Log File

Medium npm
Severity
4.2 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
0.31%
Chance of exploitation in the next 30 days. Higher than 24.06% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-284 Improper Access Control
CWE-532 Insertion of Sensitive Information into Log File
Fix
9.23.3
Upgrade directus to this version or later

Description

Summary

CWE-532: Insertion of Sensitive Information into Log File discovered in v9.23.1. The directus_refresh_token is not redacted properly from the log outputs and can be used to impersonate users without their permission.

Details

Using v9.23.1, I am seeing that the directus_refresh_token is not properly redacted as indicated by https://github.com/directus/directus/blob/7c479c5161639aac466c763b6b958a9524201d74/api/src/logger.ts#L13

I'm classifying this as a security vulnerability because if someone has access to the log outputs, for example with a shared Cloud account or Splunk implementation, they could exchange the refresh token using /auth/refresh for an access token and use the token to perform actions on behalf of an unsuspecting user. This situation creates issues with accountability and non-repudiation because we can no longer have confidence that actions taken in the application were authorized or even performed by the logged-in user.

A couple of examples of this are:

  • A disgruntled employee deletes all of the data to get even with a target team member before logging off on their last day
  • Under the guise of their unsuspecting boss, a mischievous engineer uploads questionable images that get displayed on internal or external facing content sites

The list could go on but I think these communicate the risk of an internal threat that has access to this information 😆

PoC

  1. Set LOG_STYLE="raw" and run Directus v9.23.1

  2. Log in to the application

  3. Look at the shell output and see that directus_refresh_token is logged

    Note: This is different from the standard raw output format. I intentionally ran this with npx directus start | pino-pretty so logs would be easier to read. It can also be reproduced by running npx directus start alone.

    image

  4. Exchange the directus_refresh_token for an access_token

     curl -X POST \
       'http://0.0.0.0:8055/auth/refresh' \
       --header 'Accept: */*' \
       --header 'Cookie: directus_refresh_token=$shh'
    

Impact

Because this can be used to exploit other threats related to CWE-284: Improper Access Control I rank it with a Moderate severity. An insider with knowledge of this could do many mischievous things and get away with them for a long time without victims knowing about it.

Affected versions

npm

PackageVulnerableFixed in
directus
< 9.23.3
9.23.3

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 → 9.23.3

npm
npm install directus@9.23.3
yarn
yarn add directus@9.23.3
pnpm
pnpm add directus@9.23.3

Severity breakdown

CVSS 3.1 4.2

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

Attack vector
Local
Attack complexity
Low
Privileges required
High
User interaction
Required
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

Weakness

CWE-284: Improper Access Control

The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

How to prevent it
  • Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  • Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

CWE-532: Insertion of Sensitive Information into Log File

The product writes sensitive information to a log file.

How to prevent it
  • Architecture and Design, Implementation: Consider seriously the sensitivity of the information written into log files. Do not write secrets into the log files.
  • Distribution: Remove debug log files before deploying the application into production.
  • Operation: Protect log files against unauthorized read/write.
  • Implementation: Adjust configurations appropriately when software is transitioned from a debug state to production.

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