GHSA-8VG2-WF3Q-MWV7
Vulnerability from github – Published: 2023-03-23 19:47 – Updated: 2023-03-31 16:08Summary
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
- Set
LOG_STYLE="raw"and run Directus v9.23.1 - Log in to the application
-
Look at the shell output and see that
directus_refresh_tokenis logged > Note: This is different from the standardrawoutput format. I intentionally ran this withnpx directus start | pino-prettyso logs would be easier to read. It can also be reproduced by runningnpx directus startalone.
-
Exchange the
directus_refresh_tokenfor anaccess_tokenshell 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": [
{
"package": {
"ecosystem": "npm",
"name": "directus"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.23.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-28443"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2023-03-23T19:47:12Z",
"nvd_published_at": "2023-03-24T00:15:00Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nCWE-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. \n\n### Details\n\nUsing `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\n\nI\u0027m 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. \n\nA couple of examples of this are:\n- A disgruntled employee deletes all of the data to get even with a target team member before logging off on their last day\n- Under the guise of their unsuspecting boss, a mischievous engineer uploads _questionable_ images that get displayed on internal or external facing content sites\n\nThe list could go on but I think these communicate the risk of an internal threat that has access to this information \ud83d\ude06 \n\n### PoC\n1. Set `LOG_STYLE=\"raw\"` and run Directus v9.23.1\n1. Log in to the application\n1. Look at the shell output and see that `directus_refresh_token` is logged\n \u003e 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. \n\n \n\n1. Exchange the `directus_refresh_token` for an `access_token`\n\n ``` shell\n curl -X POST \\\n \u0027http://0.0.0.0:8055/auth/refresh\u0027 \\\n --header \u0027Accept: */*\u0027 \\\n --header \u0027Cookie: directus_refresh_token=$shh\u0027\n ```\n\n### Impact\nBecause this can be used to exploit other threats related to [CWE-284: Improper Access Control](https://cwe.mitre.org/data/definitions/284.html) 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. \n",
"id": "GHSA-8vg2-wf3q-mwv7",
"modified": "2023-03-31T16:08:10Z",
"published": "2023-03-23T19:47:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/directus/directus/security/advisories/GHSA-8vg2-wf3q-mwv7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28443"
},
{
"type": "WEB",
"url": "https://github.com/directus/directus/commit/349536303983ccba68ecb3e4fb35315424011afc"
},
{
"type": "PACKAGE",
"url": "https://github.com/directus/directus"
},
{
"type": "WEB",
"url": "https://github.com/directus/directus/blob/7c479c5161639aac466c763b6b958a9524201d74/api/src/logger.ts#L13"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "directus vulnerable to Insertion of Sensitive Information into Log File"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.