GHSA-QW9G-7549-7WG5

Vulnerability from github – Published: 2024-03-01 16:58 – Updated: 2024-03-01 18:58
VLAI?
Summary
Directus has MySQL accent insensitive email matching
Details

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:

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. 
POST /auth/password/request HTTP/1.1
Host: example.com
[...]
{"email":"julian@cüre53.de"}
  1. 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.
  2. 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
Severity ?
8.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.8.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "directus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-27295"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-706"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-03-01T16:58:20Z",
    "nvd_published_at": "2024-03-01T16:15:46Z",
    "severity": "HIGH"
  },
  "details": "## Password reset vulnerable to accent confusion\n\nThe 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. \n\nThis is due to the fact that by default MySQL/MariaDB are configured for accent-insenstive and case-insensitve comparisons.\n\nMySQL weak comparison:\n```sql\nselect 1 from directus_users where \u0027julian@cure53.de\u0027 = \u0027julian@c\u00fcre53.de\u0027;\n```\n\nThis 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.\n\n### Steps to reproduce:\n\n1. 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)\n2. A off-by-one accented domain `c\u00fcre53.de` can be registered to be able to receive emails.\n3. With this email the attacker can request a password reset for `julian@c\u00fcre53.de`. \n```http\nPOST /auth/password/request HTTP/1.1\nHost: example.com\n[...]\n{\"email\":\"julian@c\u00fcre53.de\"}\n```\n4. The supplied email (julian@c\u00fcre53.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.\n5. With this email the attacker can log into the target account and use it for nefarious things\n\n### Workarounds\nShould be possible with collations but haven\u0027t been able to confirm this. \n\n### References\n- https://www.monolune.com/articles/what-is-the-utf8mb4_0900_ai_ci-collation/\n- https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html\n\n",
  "id": "GHSA-qw9g-7549-7wg5",
  "modified": "2024-03-01T18:58:40Z",
  "published": "2024-03-01T16:58:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/security/advisories/GHSA-qw9g-7549-7wg5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27295"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/commit/a8ef790ea2d28b1727f9027d99bd360920d57919"
    },
    {
      "type": "WEB",
      "url": "https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/directus/directus"
    },
    {
      "type": "WEB",
      "url": "https://www.monolune.com/articles/what-is-the-utf8mb4_0900_ai_ci-collation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Directus has MySQL accent insensitive email matching"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

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.



Detection rules are retrieved from Rulezet.