GHSA-M6F8-HJRV-MW5F

Vulnerability from github – Published: 2023-03-27 22:17 – Updated: 2023-03-27 22:17
VLAI
Summary
Apiman vulnerable to permissions bypass due to missing check on API key URL
Details

Impact

Due to a missing permissions check, an attacker with an authenticated Apiman Manager account may be able to gain access to API keys they do not have permission for if they correctly guess the URL. The URL includes Organisation ID, Client ID, and Client Version of the targeted non-permitted resource, and each of these can have arbitrary values.

While not trivial to exploit, it could be achieved by brute-forcing or guessing common names.

Access to the non-permitted API Keys could allow use of other users' resources without their permission (depending on the specifics of configuration, such as whether an API key is the only form of security).

Patches

Apiman 3.1.0.Final and later resolves this issue.

Workarounds

Only provide Apiman Manager accounts to known users, do not allow anonymous/unknown users to create an Apiman Manager account.

Note that this does not affect the Apiman Gateway.

References

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 3.0.0.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.apiman:apiman-manager-api-rest-impl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.0.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-28640"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-280",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-27T22:17:57Z",
    "nvd_published_at": "2023-03-27T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nDue to a missing permissions check, an attacker with an authenticated Apiman Manager account may be able to gain access to API keys they do not have permission for if they correctly guess the URL. The URL includes Organisation ID, Client ID, and Client Version of the targeted non-permitted resource, and each of these can have arbitrary values.\n\nWhile not trivial to exploit, it could be achieved by brute-forcing or guessing common names.\n\nAccess to the non-permitted API Keys could allow use of other users\u0027 resources without their permission (depending on the specifics of configuration, such as whether an API key is the only form of security).\n\n### Patches\n\nApiman 3.1.0.Final and later resolves this issue. \n\n### Workarounds\n\nOnly provide Apiman Manager accounts to known users, do not allow anonymous/unknown users to create an Apiman Manager account.\n\nNote that this does **not** affect the Apiman Gateway.\n\n### References\n\n* [Blog post disclosing issue](https://www.apiman.io/blog/potential-permissions-bypass-disclosure/)\n",
  "id": "GHSA-m6f8-hjrv-mw5f",
  "modified": "2023-03-27T22:17:57Z",
  "published": "2023-03-27T22:17:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apiman/apiman/security/advisories/GHSA-m6f8-hjrv-mw5f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28640"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apiman/apiman"
    },
    {
      "type": "WEB",
      "url": "https://www.apiman.io/blog/potential-permissions-bypass-disclosure"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apiman vulnerable to permissions bypass due to missing check on API key URL"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…