Headline
GHSA-8vg2-wf3q-mwv7: directus vulnerable to Insertion of Sensitive Information into Log File
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
Set
LOG_STYLE="raw"
and run Directus v9.23.1Log in to the application
Look at the shell output and see that
directus_refresh_token
is loggedNote: This is different from the standard
raw
output format. I intentionally ran this withnpx directus start | pino-pretty
so logs would be easier to read. It can also be reproduced by runningnpx directus start
alone.Exchange the
directus_refresh_token
for anaccess_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.
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
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_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.
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.
References
- GHSA-8vg2-wf3q-mwv7
- directus/directus@3495363
- https://github.com/directus/directus/blob/7c479c5161639aac466c763b6b958a9524201d74/api/src/logger.ts#L13