Am I affected?

type your mpp version to check

Description

Authentication Bypass by Capture-replay in ZenHive mpp allows an attacker holding a captured subscription activation credential to charge the payer repeatedly.

The payer signs a Tempo KeyAuthorization over the chain id, key type, key id, expiry, limits and scopes only, with nothing tying it to the challenge that prompted it. MPP.Methods.Tempo.KeyAuthorization.verify/3 in lib/mpp/methods/tempo/key_authorization.ex pins each of those signed fields against the subscription request, and the access key it pins is a static per-endpoint server key, so one signed authorization verifies against every challenge the server issues for the same subscription terms. MPP.Methods.Tempo.Subscription.activate/4 deduplicates activations by challenge id, so presenting the captured credential under a fresh challenge produces a different dedup key, claim_activation succeeds, and the subscription transaction is built and broadcast again. Each replay charges the payer's wallet a new first-period settlement and re-authorizes the server key, bounded only by the subscription expiry and the chain's own semantics for re-installing an existing key.

This issue affects mpp: from 0.14.0 before 0.16.2.

Weaknesses & attack patterns

Weakness

CWE-294 · Authentication Bypass by Capture-replay in catalog → MITRE ↗

Attack patterns

CAPEC-60 · Reusing Session IDs (aka Session Replay) MITRE ↗

An attacker who obtains a payer's subscription activation credential (from a non-TLS hop, a log, a compromised intermediary, or the client's own retry buffer) can present it under fresh challenges to settle repeated first-period charges against that payer's wallet and re-authorize the server's access key. The payer bears the on-chain cost, limited only by the per-period subscription limit and the subscription expiry.

Affected — Hex / mpp Hex.pm ↗ Repository ↗

0.14.0 < 0.16.2 affected
every other version: unaffected
cpe cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*
modules · source files · routines
modules 'Elixir.MPP.Methods.Tempo.KeyAuthorization' · 'Elixir.MPP.Methods.Tempo.Subscription'
source files lib/mpp/methods/tempo/key_authorization.ex · lib/mpp/methods/tempo/subscription.ex
routines 'Elixir.MPP.Methods.Tempo.KeyAuthorization':verify/3 · 'Elixir.MPP.Methods.Tempo.KeyAuthorization':wallet_params/2 · 'Elixir.MPP.Methods.Tempo.KeyAuthorization':from_rpc/1 · 'Elixir.MPP.Methods.Tempo.Subscription':verify/2

Affected — GitHub / zenhive/mpp Repository ↗

db464df < 4b6eaec affected
every other version: unaffected
cpe cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*
modules · source files · routines
modules 'Elixir.MPP.Methods.Tempo.KeyAuthorization' · 'Elixir.MPP.Methods.Tempo.Subscription'
source files lib/mpp/methods/tempo/key_authorization.ex · lib/mpp/methods/tempo/subscription.ex
routines 'Elixir.MPP.Methods.Tempo.KeyAuthorization':verify/3 · 'Elixir.MPP.Methods.Tempo.KeyAuthorization':wallet_params/2 · 'Elixir.MPP.Methods.Tempo.KeyAuthorization':from_rpc/1 · 'Elixir.MPP.Methods.Tempo.Subscription':verify/2

Configurations

Only deployments offering Tempo subscriptions are affected, which requires subscription_access_key_private_key in the Tempo method_config. Exploitation further requires the attacker to have obtained a payer's signed activation credential, in transit over a hop that is not TLS-protected or at rest in a log, an intermediary, or a client retry buffer.

References

Credits

E.FU Finder Remediation developer
Jonatan Männchen / EEF Coordinator

CVSS breakdown

CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
« All CVEs