CVE-2020-2021 PAN-OS: Authentication Bypass in SAML Authentication

When Security Assertion Markup Language (SAML) authentication is enabled and the ‘Validate Identity Provider Certificate’ option is disabled (unchecked), improper verification of signatures in PAN-OS SAML authentication enables an unauthenticated network-based attacker to access protected resources. The attacker must have network access to the vulnerable server to exploit this vulnerability.

Recent assessments:

wvu-r7 at June 29, 2020 6:32pm UTC reported:

Technical details are a little sparse in the advisory, but this reads more like a bad software configuration or design than a vulnerability – one that may be indicative of a systemic problem in SAML implementations, not unlike the issues with SSL/TLS in practice.

Disabling identity provider (IdP) verification is akin to disabling SSL/TLS certificate verification, which is similarly the case here: many IdPs will generate self-signed certs, rendering verification all but impossible unless the software supports trusting individual certs. It is easier to leave a box unchecked. A box that seems to imply verifying only CA-signed certs. Palo Alto states as much in their advisory:

> Many popular IdPs generate self-signed IdP certificates by default and the ‘Validate Identity Provider Certificate’ option cannot be enabled.

It would not surprise me if many organizations have this option disabled, regardless of what the default configuration may be (I haven’t been able to check), since widespread documentation suggests doing so. Case in point is Okta’s documentation on setting up SAML for Palo Alto products:

Many other IdPs, including Microsoft’s Azure Active Directory, suggest the same. This sets a dangerous precedent for other software to follow. In the worst case, this problem is already endemic in SAML implementations, regardless of the circumstances here. An audit of SAML implementations may be a worthy endeavor.

You should still patch or otherwise fix this configuration if at all possible. Palo Alto suggests using a CA-signed cert when available. Ideally, certificates should be trusted on a one-by-one basis, which is an unsustainable model for SSL/TLS but adequate for SAML. Of course, the software must support this, and the documentation must advise it. This was not the case here, apparently.

Assessed Attacker Value: 5
Assessed Attacker Value: 5Assessed Attacker Value: 4