Brief Description

An attacker can bypass authentication by presenting a JWT token with an issuer that is not in the provider list when Envoy’s JWT Authentication filter is configured with the allow_missing requirement under requires_any due to a mistake in implementation.

CVSS

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

CVSS score 8.2 (High)

Affected version(s)

Envoy 1.17.0

Affected component(s)

JWT filter

Attack vector(s)

An attacker can present a JWT token with an unknown issuer to bypass authentication when the JWT filter configuration allows missing JWT under a requires_any configuration.

Details

Envoy’s JWT Authentication filter can be configured with the allow_missing requirement that will be satisfied if JWT is missing (JwtMissed error) and fail if JWT is presented or invalid. Due to a mistake in implementation, a JwtUnknownIssuer error was mistakenly converted to JwtMissed when requires_any was configured. So if allow_missing was configured under requires_any, an attacker can bypass authentication by presenting a JWT token with an issuer that is not in the provider list. Integrity may be impacted depending on configuration if the JWT token is used to protect against writes or modifications.

This regression was introduced on 2020/11/12 in PR 13839 which fixed handling allow_missing under RequiresAny in a JwtRequirement (see issue 13458). The AnyVerifier aggregates the children verifiers’ results into a final status where JwtMissing is the default error. However, a JwtUnknownIssuer was mistakenly treated the same as a JwtMissing error and the resulting final aggregation was the default JwtMissing. As a result, allow_missing would allow a JWT token with an unknown issuer status.

PR 15194 fixes the issue by preferring JwtUnknownIssuer over a JwtMissing error, fixing the accidental conversion and bypass with allow_missing.

The vulnerability was originally reported via private disclosure to Istio Product Security Team on 2021/02/20. It was disclosed to the Envoy Security team on 2021/02/24 after a fix was accidentally pushed to the public Envoy repository during the investigation. Due to this, Envoy Security team treated this as a public zero day and released a fix on 2021/02/25. Because of the recent regression, the issue only impacted Envoy version 1.17.0 and Istio version 1.9.

Mitigations

Vulnerable users can mitigate this by using an RBAC filter that checks the dynamic metadata for the validation result. The JWT filter will write successfully verified JWT payloads to dynamic metadata when payload_in_metadata is enabled in the JWT filter. It will not be present if the JWT filter bypasses validation. For example, if payload_in_metadata has value auth_payload, you can configure RBAC like the following.

 - name: envoy.filters.http.rbac
    config:
      rules:
        action: ALLOW
        policies:
          "any":
            principals:
              - metadata:
                  filter: envoy.filters.http.jwt_authn
                  path:
                    - key: auth_payload 
                  value: 
                    present_match: true
            permissions:
              - any: true

Detection

A user could detect whether a bypass occurred if they have Envoy logs enabled with debug verbosity. Users can enable component level debug logs for JWT. The JWT filter logs will indicate that there is a request with a JWT token and a failure that the JWT token is missing.

References

#13839