GHSA-VQV5-385R-2HF8

Vulnerability from github – Published: 2025-02-05 21:30 – Updated: 2025-02-06 18:05
VLAI
Summary
Contrast's unauthenticated recovery allows Coordinator impersonation
Details

Impact

Recovering coordinators do not verify the seed provided by the recovering party. This allows an attacker to set up a coordinator with a manifest that passes validation, but with a secret seed controlled by the attacker.

If network traffic is redirected from the legitimate coordinator to the attacker's coordinator, a workload owner is susceptible to impersonation if either

  • they set a new manifest and don't compare the root CA cert with the existing one (this is the default of the contrast CLI) or
  • they verify the coordinator and don't compare the root CA cert with a trusted reference.

Under these circumstances, the attacker can:

  • Issue certificates that chain back to the attacker coordinator's root CA.
  • Recover arbitrary workload secrets of workloads deployed after the attack.

This issue does not affect the following:

  • secrets of the legitimate coordinator (seed, workload secrets, CA)
  • integrity of workloads, even when used with the rogue coordinator
  • certificates chaining back to the mesh CA

Patches

This issue is patched in Contrast v1.4.1.

Workarounds

The issue can be avoided by verifying the coordinator root CA cert against expectations.

  • At the first set call, keep a copy of the CA cert returned by the coordinator.
  • After subsequent set or verify calls, compare the returned CA cert with the backup copy. If it matches bit-for-bit, the coordinator is legitimate.
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.4.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/edgelesssys/contrast"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-285"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-05T21:30:35Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nRecovering coordinators do not verify the seed provided by the recovering party. This allows an attacker to set up a coordinator with a manifest that passes validation, but with a secret seed controlled by the attacker. \n\nIf network traffic is redirected from the legitimate coordinator to the attacker\u0027s coordinator, a workload owner is susceptible to impersonation if either \n\n* they `set` a new manifest and don\u0027t compare the root CA cert with the existing one (this is the default of the `contrast` CLI) or\n* they `verify` the coordinator and don\u0027t compare the root CA cert with a trusted reference.\n\nUnder these circumstances, the attacker can:\n\n* Issue certificates that chain back to the attacker coordinator\u0027s root CA.\n* Recover arbitrary workload secrets of workloads deployed after the attack.\n\nThis issue does **not** affect the following:\n\n* secrets of the legitimate coordinator (seed, workload secrets, CA)\n* integrity of workloads, even when used with the rogue coordinator\n* certificates chaining back to the mesh CA\n\n### Patches\n\nThis issue is patched in Contrast v1.4.1.\n\n### Workarounds\n\nThe issue can be avoided by verifying the coordinator root CA cert against expectations.\n\n* At the first `set` call, keep a copy of the CA cert returned by the coordinator.\n* After subsequent `set` or `verify` calls, compare the returned CA cert with the backup copy. If it matches bit-for-bit, the coordinator is legitimate.",
  "id": "GHSA-vqv5-385r-2hf8",
  "modified": "2025-02-06T18:05:15Z",
  "published": "2025-02-05T21:30:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/edgelesssys/contrast/security/advisories/GHSA-vqv5-385r-2hf8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/edgelesssys/contrast"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3455"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Contrast\u0027s unauthenticated recovery allows Coordinator impersonation"
}



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…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…