Improper Verification of Cryptographic Signature in dashbit nimble_zta Cloudflare strategy

Improper Verification of Cryptographic Signature vulnerability in dashbit nimble_zta allows an unauthenticated remote attacker to authenticate as an arbitrary Cloudflare service token. Applications using the Cloudflare Zero Trust authentication strategy are affected.

verify_token/2 in lib/nimble_zta/cloudflare.ex matches the result of JOSE.JWT.verify/2 against {_, token, _s}, which discards the boolean verification result and returns the decoded token after a failed signature check. The attacker sends a forged JWT in the cf-access-jwt-assertion header, carrying the expected iss claim and the seven service token claims. verify_iss/2 reads the iss claim from the forged token, so it rejects nothing, and the service token path then returns those claims as the authenticated identity.

This issue affects nimble_zta: from 0.1.2 before 0.1.3.

1. Build a JWT payload that carries the aud, common_name, exp, iat, iss, sub and type claims. Use the iss the application expects, set exp to a future timestamp, and set common_name to the service token to impersonate.
2. Append any signature segment. The segment must be present, because JOSE.JWT.verify/2 needs three segments to parse the token. The signature does not need to verify against the Cloudflare keys.
3. Send a request to the application with the forged JWT in the cf-access-jwt-assertion header.
4. NimbleZTA.Cloudflare.authenticate/3 returns the claims of the forged token as the authenticated identity, with the strategy field set to service_token.

Disable the Cloudflare authentication strategy.

To keep the user identity strategy available, reject the service token requests yourself. Examine each request before you call NimbleZTA.Cloudflare.authenticate/3, and reject it if its JWT carries the common_name claim and the type claim.

The application must add NimbleZTA.Cloudflare to its supervision tree and authenticate requests through it.