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.

References

• GHSA-vqv5-385r-2hf8