A Breakdown of the New SAML Authentication Bypass Vulnerability
An in-depth look at the new SAML authentication bypass vulnerability: what it is, how it works, and how you can protect yourself against it.
Matt M.
Do you have any suggested XML libraries that support stripping out comments?
Antti Toivonen
The vulnerability is on Service Provider (SP) side. Okta is messaging, that they are not vulnerable. Does this actually mean, that Okta protects against this attack, when Okta is used as Identity Provider (IdP)? Otherwise it is a bit misleading communications.
Jim Mollé
No, this does not mean that Okta, in its IdP role, can protect against this attack. The context here is that many customers use Okta as a SP, via inbound SAML, and in THOSE cases, Okta (as a SP) has taken necessary steps to ensure we are not vulnerable.
Puneet T
For a custom app, Okta is being used and as IdP. The Python backend used the pysaml2 library [1] to process the SAML assertion coming in from Okta.
Is there any action required in the backend code to mitigate this vulnerability?
Antti Toivonen
Hi Jim, thanks for clarification. Makes very much sense. However this should be emphasised in the communications as well. Would suppose, that it is much much more common to use Okta as IdP than SP. In the case Okta is used as IdP, users might not understand that they are still vulnerable for this attack.
Okta could be protecting against some forms of the attack, by cleaning comments out of the attributes.
Guillaume
If I understand correctly, an attacker is able to edit an attribute of an existing, valid, signed SAML assertion, in such a way that the signature value does not change, but the interpretation of the attribute on SP side can vary (only a subpart of the attribute will be taken into account).
So, in order to exploit that vulnerability, an attacker needs to obtain a currently valid SAML assertion, and rely on the fact that the naming convention of the exchanged attributes allows to do that. The first condition alone assumes that the attacked is either a valid authorized user or has exploited another flaw to obtain that assertion during its validity period. The second conditions greatly depends on the deployment.
So I fail to see how that can be an authentication bypass vulnerability. It is at best a privilege escalation vulnerability, that can be rather difficult to exploit depending on the naming convention of authorisation related attributes exchanged during SAML authentication.
Also, IdP side probably need to be fixed as well, in order to process signed SAMLRequests properly (an attacker could for example edit a RequestedAuthnContext in a POST Binding signed request, even if that makes it even harder to exploit).
Randall Degges
Heyo! It is considered an authentication bypass vulnerability because an attacker who has the ability to register on the same IdP as the victim (and knows the victim’s email, let’s say), can create an an account strategically with the comment in the name.
While unlikely, it is theoretically possible that an attacker could register with an IdP using a ‘compromised’ email address and immediately assume login credentials for a victim account without authenticating as the victim.
appsian
The information you’ve shared in this blog is remarkable. Thanks for sharing such quality information
Ray Anna
sdf