Summary
An attacker can bypass authorization checks and force a Step CA ACME or SCEP provisioner to create certificates without completing certain protocol authorization checks.
Details
Most Step CA provisioners (like the JWK provisioner) require a valid token to interact with the provisioner. The token specifies which provisioner handles the verification. Some provisioners, such as ACME and SCEP, do not require a token because these protocols define their own authorization mechanisms.
However, ACME and SCEP provisioners were provided a token if the token claimed to be issued for that provisioner. Unexpected tokens were not validated on these provisioners. As a result, the request would be treated as authenticated, bypassing the authorization checks normally enforced.
Authorization webhooks and regular CA policies, such as allowed names and restrictions on certificate validity periods, remain in place.
Mitigations
If you are unable to upgrade to v0.29.0 or newer, the attack can be mitigated by blocking access to the /sign endpoint.
Fix
In v0.29.0, ACME and SCEP provisioners were updated to block requests providing a token.
Acknowledgements
This issue was identified and reported by Stephen Kubik of the Cisco Advanced Security Initiatives Group (ASIG).
Embargo List
If your organization runs Step CA in production and would like advance, embargoed notification of future security updates, visit https://u.step.sm/disclosure to request inclusion on our embargo list.
Stay safe, and thank you for helping us keep the ecosystem secure.
Summary
An attacker can bypass authorization checks and force a Step CA ACME or SCEP provisioner to create certificates without completing certain protocol authorization checks.
Details
Most Step CA provisioners (like the JWK provisioner) require a valid token to interact with the provisioner. The token specifies which provisioner handles the verification. Some provisioners, such as ACME and SCEP, do not require a token because these protocols define their own authorization mechanisms.
However, ACME and SCEP provisioners were provided a token if the token claimed to be issued for that provisioner. Unexpected tokens were not validated on these provisioners. As a result, the request would be treated as authenticated, bypassing the authorization checks normally enforced.
Authorization webhooks and regular CA policies, such as allowed names and restrictions on certificate validity periods, remain in place.
Mitigations
If you are unable to upgrade to v0.29.0 or newer, the attack can be mitigated by blocking access to the /sign endpoint.
Fix
In v0.29.0, ACME and SCEP provisioners were updated to block requests providing a token.
Acknowledgements
This issue was identified and reported by Stephen Kubik of the Cisco Advanced Security Initiatives Group (ASIG).
Embargo List
If your organization runs Step CA in production and would like advance, embargoed notification of future security updates, visit https://u.step.sm/disclosure to request inclusion on our embargo list.
Stay safe, and thank you for helping us keep the ecosystem secure.