ghsa-58vj-cv5w-v4v6
Vulnerability from github
Published
2024-09-20 14:51
Modified
2024-09-20 22:07
Summary
Navidrome has Multiple SQL Injections and ORM Leak
Details

Security Advisory: Multiple Vulnerabilities in Navidrome

Summary

Navidrome automatically adds parameters in the URL to SQL queries. This can be exploited to access information by adding parameters like password=... in the URL (ORM Leak).

Furthermore, the names of the parameters are not properly escaped, leading to SQL Injections.

Finally, the username is used in a LIKE statement, allowing people to log in with % instead of their username.

Details

ORM Leak

When adding parameters to the URL, they are automatically included in an SQL LIKE statement (depending on the parameter's name). This allows attackers to potentially retrieve arbitrary information.

For example, attackers can use the following request to test whether some encrypted passwords start with AAA:

GET /api/user?_end=36&_order=DESC&password=AAA%

This results in an SQL query like password LIKE 'AAA%', allowing attackers to slowly brute-force passwords. (Also, any reason for using encryption instead of hashing?)

SQL Injections

When adding parameters to the URL, they are automatically added to an SQL query. The names of the parameters are not properly escaped.

This behavior can be used to inject arbitrary SQL code (SQL Injection), for example:

GET /api/album?_end=36&_order=DESC&_sort=recently_added&_start=0&SELECT+*+FROM+USER--=123 HTTP/1.1

This is only an example, but you should see an error message in the logs.

Authentication Weakness

When retrieving the user for authentication, the following code is used:

go func (r *userRepository) FindByUsername(username string) (model.User, error) { sel := r.newSelect().Columns("").Where(Like{"user_name": username}) var usr model.User err := r.queryOne(sel, &usr) return &usr, err }

This relies on a LIKE statement and allows users to log in with % instead of the legitimate username.

Proof of Concept (PoC)

See above.

Impact

These vulnerabilities can be used to leak information and dump the contents of the database.

Credit

Louis Nyffenegger from PentesterLab

Show details on source website


{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/navidrome/navidrome"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.53.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-47062"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-89"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-20T14:51:56Z",
    "nvd_published_at": "2024-09-20T19:15:16Z",
    "severity": "CRITICAL"
  },
  "details": "# Security Advisory: Multiple Vulnerabilities in Navidrome\n\n## Summary\n\nNavidrome automatically adds parameters in the URL to SQL queries. This can be exploited to access information by adding parameters like `password=...` in the URL (ORM Leak).\n\nFurthermore, the names of the parameters are not properly escaped, leading to SQL Injections.\n\nFinally, the username is used in a `LIKE` statement, allowing people to log in with `%` instead of their username.\n\n## Details\n\n### ORM Leak\n\nWhen adding parameters to the URL, they are automatically included in an SQL `LIKE` statement (depending on the parameter\u0027s name). This allows attackers to potentially retrieve arbitrary information.\n\nFor example, attackers can use the following request to test whether some encrypted passwords start with `AAA`:\n\n```\nGET /api/user?_end=36\u0026_order=DESC\u0026password=AAA%\n```\n\nThis results in an SQL query like `password LIKE \u0027AAA%\u0027`, allowing attackers to slowly brute-force passwords. (Also, any reason for using encryption instead of hashing?)\n\n### SQL Injections\n\nWhen adding parameters to the URL, they are automatically added to an SQL query. The names of the parameters are not properly escaped.\n\nThis behavior can be used to inject arbitrary SQL code (SQL Injection), for example:\n\n```\nGET /api/album?_end=36\u0026_order=DESC\u0026_sort=recently_added\u0026_start=0\u0026SELECT+*+FROM+USER--=123 HTTP/1.1\n```\n\nThis is only an example, but you should see an error message in the logs.\n\n### Authentication Weakness\n\nWhen retrieving the user for authentication, the following code is used:\n\n```go\nfunc (r *userRepository) FindByUsername(username string) (model.User, error) {\n    sel := r.newSelect().Columns(\"\").Where(Like{\"user_name\": username})\n    var usr model.User\n    err := r.queryOne(sel, \u0026usr)\n    return \u0026usr, err\n}\n```\n\nThis relies on a `LIKE` statement and allows users to log in with `%` instead of the legitimate username.\n\n## Proof of Concept (PoC)\n\nSee above.\n\n## Impact\n\nThese vulnerabilities can be used to leak information and dump the contents of the database.\n\n## Credit\n\nLouis Nyffenegger from PentesterLab",
  "id": "GHSA-58vj-cv5w-v4v6",
  "modified": "2024-09-20T22:07:50Z",
  "published": "2024-09-20T14:51:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/navidrome/navidrome/security/advisories/GHSA-58vj-cv5w-v4v6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47062"
    },
    {
      "type": "WEB",
      "url": "https://github.com/navidrome/navidrome/commit/3107170afd9f557a10f7031f23cb3c9e975a71f9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/navidrome/navidrome"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Navidrome has Multiple SQL Injections and ORM Leak"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.