Package Instance

Directus has MySQL accent insensitive email matching
## Password reset vulnerable to accent confusion

The password reset mechanism of the Directus backend is implemented in a way where combined with (specific, need to double check if i can work around) configuration in MySQL or MariaDB. As such, it allows attackers to receive a password reset email of a victim user, specifically having it arrive at a similar email address as the victim with a one or more characters changed to use accents. 

This is due to the fact that by default MySQL/MariaDB are configured for accent-insenstive and case-insensitve comparisons.

MySQL weak comparison:
```sql
select 1 from directus_users where 'julian@cure53.de' = 'julian@cüre53.de';
```

This is exploitable due to an error in the API using the supplied email address for sending the reset password mail instead of using the email from the database.

### Steps to reproduce:

1. If the attacker knows the email address of the victim user, i.e., `julian@cure53.de`. (possibly just the domain could be enough for an educated guess)
2. A off-by-one accented domain `cüre53.de` can be registered to be able to receive emails.
3. With this email the attacker can request a password reset for `julian@cüre53.de`. 
```http
POST /auth/password/request HTTP/1.1
Host: example.com
[...]
{"email":"julian@cüre53.de"}
```
4. The supplied email (julian@cüre53.de) gets checked against the database and will match the non-accented email `julian@cure53.de` and will continue to email the password reset link to the provided email address instead of the saved email address.
5. With this email the attacker can log into the target account and use it for nefarious things

### Workarounds
Should be possible with collations but haven't been able to confirm this. 

### References
- https://www.monolune.com/articles/what-is-the-utf8mb4_0900_ai_ci-collation/
- https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html

Directus vulnerable to Server-Side Request Forgery On File Import
### Summary
Directus versions <=9.22.4 is vulnerable to Server-Side Request Forgery (SSRF) when importing a file from a remote web server (POST to `/files/import`). An attacker can bypass the security controls that were implemented to patch vulnerability [CVE-2022-23080](https://security.snyk.io/vuln/SNYK-JS-DIRECTUS-2934713) by performing a [DNS rebinding attack](https://en.wikipedia.org/wiki/DNS_rebinding) and view sensitive data from internal servers or perform a local port scan (eg. can access internal metadata API for AWS at `http://169.254.169.254` event if `169.254.169.254` is in the deny IP list).

### Details
DNS rebinding attacks work by running a DNS name server that resolves two different IP addresses when a domain is resolved simultaneously. This type of attack can be exploited to bypass the IP address deny list validation that was added to [`/api/src/services/file.ts`](https://github.com/directus/directus/blob/main/api/src/services/files.ts) for the function `importOne` to mitigate the previous SSRF vulnerability [CVE-2022-23080](https://security.snyk.io/vuln/SNYK-JS-DIRECTUS-2934713). The validation in [`/api/src/services/file.ts`](https://github.com/directus/directus/blob/main/api/src/services/files.ts) first checks if the resolved IP address for a domain name does not a resolve to an IP address in the deny list:

```js
let ip = resolvedUrl.hostname;

if (net.isIP(ip) === 0) {
    try {
        ip = (await lookupDNS(ip)).address;
    } catch (err: any) {
        logger.warn(err, `Couldn't lookup the DNS for url ${importURL}`);
        throw new ServiceUnavailableException(`Couldn't fetch file from url "${importURL}"`, {
            service: 'external-file',
        });
    }
}

if (env.IMPORT_IP_DENY_LIST.includes('0.0.0.0')) {
    const networkInterfaces = os.networkInterfaces();

    for (const networkInfo of Object.values(networkInterfaces)) {
        if (!networkInfo) continue;

        for (const info of networkInfo) {
            if (info.address === ip) {
                logger.warn(`Requested URL ${importURL} resolves to localhost.`);
                throw new ServiceUnavailableException(`Couldn't fetch file from url "${importURL}"`, {
                    service: 'external-file',
                });
            }
        }
    }
}

if (env.IMPORT_IP_DENY_LIST.includes(ip)) {
    logger.warn(`Requested URL ${importURL} resolves to a denied IP address.`);
    throw new ServiceUnavailableException(`Couldn't fetch file from url "${importURL}"`, {
        service: 'external-file',
    });
}
```

Once it validates that the resolved IP address is not in the deny list, then it uses `axios` to `GET` the url and saves the response content.

```js
try {
    fileResponse = await axios.get<Readable>(encodeURL(importURL), {
        responseType: 'stream',
    });
} catch (err: any) {
    logger.warn(err, `Couldn't fetch file from url "${importURL}"`);
    throw new ServiceUnavailableException(`Couldn't fetch file from url "${importURL}"`, {
        service: 'external-file',
    });
}
```

However, this validation check and fetching the web resource causes to DNS queries that enable a DNS rebinding attack. On the first DNS query, an attacker controlled name server can be configured to resolve to an external IP address that is not in the deny list to bypass the validation. Then when `axios` is called, the name server resolves the domain name to a local IP address.

### PoC
To demonstrate we will be using an online tool named [rebinder](https://lock.cmpxchg8b.com/rebinder.html). Rebinder randomly changes the IP address it resolves to depending on the subdomain. For an example, `7f000001.8efa468e.rbndr.us` can resolve to either `142.250.70.142` (google.com) or **`127.0.0.1`**. Sending multiple `POST` requests to `/files/import` using this domain will eventually cause a resolution to `142.250.70.142` first to bypass the validation then fetch the sensitive from an internal server when `axios` is called.

The following screenshots show what it looks like when a successful attack occurs.

*Downloading a file named `secret.txt` from a webserver running from `http://127.0.0.1/secret.txt`*
![image](https://user-images.githubusercontent.com/6276577/218124035-26f7f0c3-47b3-424d-b4d4-bd3b47161983.png)

*Receiving the request from the internal server. Note that the incoming connection is from **127.0.0.1**.*
![image](https://user-images.githubusercontent.com/6276577/218124119-87b8d5d6-934d-4e07-be4d-066616a9a435.png)

*After downloading the file it leaks the content of the secret file.*
![image](https://user-images.githubusercontent.com/6276577/218122210-87b2e478-1081-4830-a9ea-e5d9f39bb129.png)

### Impact
An attacker can exploit this vulnerability to access highly sensitive internal server and steal sensitive information. An example is on Cloud Environments that utilise internal APIs for managing machine and privileges. For an example, if `directus` is hosted on AWS EC2 instance and has an IAM role assigned to the EC2 instance then an attacker can exploit this vulnerability to steal the AWS access keys to impersonate the EC2 instance using the AWS API.

Session Token in URL in directus
### Impact

When reaching the /files page, a JWT is passed via GET request. Inclusion of session tokens in URLs poses a security risk as URLs are often logged in various places (e.g., web server logs, browser history). Attackers gaining access to these logs may hijack active user sessions, leading to unauthorized access to sensitive information or actions on behalf of the user.

### Patches

_Has the problem been patched? What versions should users upgrade to?_

### Workarounds

There's no workaround available.

### References

_Are there any links users can visit to find out more?_

Directus affected by VM2 sandbox escape vulnerability
### Impact
In vm2 for versions up to 3.9.19, Promise handler sanitization can be bypassed, allowing attackers to escape the sandbox and run arbitrary code. Within Directus this applies to the "Run Script" operation in flows being able to escape the sandbox running code in the main nodejs context.

### Patches
Patched in v10.6.0 by replacing `vm2` with `isolated-vm`

### Workarounds
None

### References
https://github.com/patriksimek/vm2/security/advisories/GHSA-cchq-frgv-rjh5

URL Redirection to Untrusted Site in OAuth2/OpenID in directus
### Summary
The authentication API has a `redirect` parameter that can be exploited as an open redirect vulnerability as the user tries to log in via the API URL https://docs.directus.io/reference/authentication.html#login-using-sso-providers /auth/login/google?redirect for example.

### Details
There's a redirect that is done after successful login via the Auth API GET request to `directus/auth/login/google?redirect=http://malicious-fishing-site.com`, which I think is here: https://github.com/directus/directus/blob/main/api/src/auth/drivers/oauth2.ts#L394. While credentials don't seem to be passed to the attacker site, the user can be phished into clicking a legitimate directus site and be taken to a malicious site made to look like a an error message "Your password needs to be updated" to phish out the current password.

### PoC
Turn on any auth provider in Directus instance. Form a link to `directus-instance/auth/login/:provider_id?redirect=http://malicious-fishing-site.com`, login and get taken to malicious-site. Tested on the `ory` OAuth2 integration.

### Impact
Users who login via OAuth2 into Directus.

Directus vulnerable to unhandled exception on illegal filename_disk value
The Directus process can be aborted by having an authorized user update the `filename_disk` value to a folder and accessing that file through the `/assets` endpoint. 

The vulnerability is patched and released in v9.15.0.

You can prevent this problem by making sure no (untrusted) non-admin users have permissions to update the `filename_disk` field on `directus_files`.

### For more information

If you have any questions or comments about this advisory:
* Open a Discussion in [directus/directus](https://github.com/directus/directus/discussions)
* Email us at [security@directus.io](mailto:security@directus.io)

### Credits

This vulnerability was first discovered and reported by Witold Gorecki.

Directus version number disclosure
### Impact

Currently the exact Directus version number is being shipped in compiled JS bundles which are accessible without authentication. With this information a malicious attacker can trivially look for known vulnerabilities in Directus core or any of its shipped dependencies in that specific running version.

### Patches

The problem has been resolved in versions 10.8.3 and newer

### Workarounds

None

Directus vulnerable to extraction of password hashes through export querying
### Impact

Users with read access to the `password` field in `directus_users` can extract the argon2 password hashes by brute forcing the export functionality combined with a `_starts_with` filter. This allows the user to enumerate the password hashes.

### Patches

The problem has been patched by preventing any hashed/concealed field to be filtered against with the `_starts_with` or other string operator.

### Workarounds

Ensuring that no user has `read` access to the `password` field in `directus_users` is sufficient to prevent this vulnerability. 


### For more information
If you have any questions or comments about this advisory:
* Open a Discussion in [directus/directus](https://github.com/directus/directus/discussions/new)
* Email us at [security@directus.io](mailto:security@directus.io)

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
1. Set `LOG_STYLE="raw"` and run Directus v9.23.1
1. Log in to the application
1. 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](https://user-images.githubusercontent.com/13325146/224877190-54e12d7e-3c3e-42d3-9e21-0bd4439f4f44.png)

1. Exchange the `directus_refresh_token` for an `access_token`

     ``` shell
      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](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.

directus vulnerable to HTML Injection in Password Reset email to custom Reset URL
### Impact

Instances relying on an allow-listed reset URL are vulnerable to an HTML injection attack through the use of query parameters in the reset URL. 

### Patches

The problem has been resolved and released under version 9.23.0. People relying on a custom password reset URL should upgrade to 9.23.0 or later, or remove the custom reset url from the configured allow list.

### Workarounds

Disable the custom reset URL allow list.