Executive Summary – CVE-2020-2021
On June 29, 2020, Palo Alto released information on a Security Assertion Markup Language (SAML) authentication bypass CVE-2020-2021. Palo Alto published the advisory PAN-148988 for a critical issue affecting multiple versions of PAN-OS.
Following the disclosure, the United States Cybersecurity and Infrastructure Security Agency (CISA) advised all affected organizations to take immediate action. They stated the belief that foreign actors would likely move quickly to exploit the vulnerability.
The Randori Attack Team is looking into this vulnerability and has successfully developed a working POC in a local test environment. Leveraging this vulnerability, an adversary with network access to an affected PAN-OS device, including those running GlobalProtect VPN, that is configured to use Security Assertion Markup Language (SAML) authentication, could bypass authentication controls and gain access to protected resources.
CVE-2020-2021 is a serious issue, and affected organizations should take immediate action to ensure the security of impacted devices. PAN-OS is widely adopted in the enterprise and has been observed in roughly 25% of Randori clients. It’s important to note that this vulnerability only affects resources using SAML. Organizations not using SAML are not at risk.
The mitigation steps by Palo Alto Networks are clear, but the Randori Attack Team has not yet been able to validate if/how IAM providers, such as OKTA, would be affected by the mitigation, or if the recommended mitigation could negatively impact IAM provider integrations.
We are continuing to test the POC and will update this blog as we learn more.
Vulnerability Analysis & Proof of Concept
From the Palo Alto disclosure, “improper verification of signatures in PAN-OS SAML authentication enables an unauthenticated network-based attacker to access protected resources.”
PA documentation regarding the configuration of SAML indicates the “Validate Identity Provider Certificate” is used to validate the certificate chain (verify the certificate itself is from a trusted source), but the cert should still be utilized to validate messages.
Our initial assumption based on the disclosure and the documentation was that some error exists in the code such that a SAML Identity Provider (IdP) assertion can be signed with an unknown key and still be trusted by the PANOS device. This assumption has proven to be correct.
Randori assembled a test configuration consisting of a virtual machine PAN-OS 8.1.4 device on a closed network with an IdP. The PAN is configured to provide GlobalProtect access authenticated via the IdP which is implemented using pysaml2. The tested PAN-OS version is old, but is in the vulnerable set, and no additional SAML related issues are known to exist in this family of devices. The OKTA guidance for SAML configuration of GlobalProtect is the baseline for the tested configuration.
Authentication via the IdP is confirmed to work when configured according to the provided guidance, and then the IdP key is changed. Subsequent authentication assertions continue to be accepted by the PAN device, which is consistent with the CVE report.
Acceptance of the IdP response and assertions by the PAN GlobalProtect service, with “Validate Identity Provider Certificate” un-set, appears to only require that sufficient fields in the response match the request, but does not appear to require a signature.
Configuration of an IdP to authenticate for a service requires that metadata is exchanged between the service (the PAN device) and the identity provider (OKTA, etc). Two separate configurations were compared: first, the “Validate Identity Provider Certificate” case, and then the (recommended) alternate case. The metadata for each case reveals a likely issue.
Figure 1: Validate Identity Provider Certificate set
Figure 2: Selection of metadata for the “Validate” case
Figure 3: Validate Identity Provider Certificate unset
Figure 4: Selection of metadata for the normal case
The SAML metadata specification indicates that the “WantAssertionsSigned” attribute indicates that assertions should be signed, and also that the default condition is “False” meaning that by default, assertions do not need to be signed. In this case, the “nominal” configuration indicates that the PAN GlobalProtect does not want signed assertions, and it seems that there is no need to sign an assertion or response at all. The test configuration appears to confirm this, as unsigned assertions and responses are accepted by the PAN device as valid from the IdP. According to the SAML profile specification, the responses must be signed whenever using an HTTP POST binding.
OKTA documentation shows the following diagram
In this scenario, the Service Provider (SP) and IdP do not directly communicate. In a correct implementation, the SP and the IdP should use signatures on messages to assure that the messages are authentic. Because the PAN implementation asks for no signatures, therefore there is no protection between the IdP and the SP.
In practice, “blind” exploitation is still hampered as it requires knowledge of several metadata elements. This data is almost certainly attainable, but may not be obvious in all situations.
A successful attack yields access to the protected resource in the context of an authenticated user. This means that a user could “log in” to the VPN. In the case where an administrative interface is authenticated via SAML, it is possible that an attacker could login to that interface. In general, Palo Alto Networks has done a good job in recommending configurations that reduce the likelihood that an administrative interface is exposed to the internet. This increases the complexity required for an adversary to gain access to such an administrative interface.
Recommended Actions
Based on our initial research, we can confirm that CVE-2020-2021 is a serious issue and affected organizations should take immediate action to ensure the security of impacted devices. It is important to note that this vulnerability only affects resources using SAML. Organizations not using SAML are not at risk.
Organizations leveraging SAML for authentication on affected systems should assume that an adversary may have gained access to their network and review historical logs for anomalous behavior, such as abnormal usernames or source IP connections, and signs of compromise.
For organizations leveraging SAML, Randori recommends they follow the outlined mitigation steps from Palo Alto. Further details on securing your SAML deployment is available here: Securing Your SAML Deployments.
The mitigation steps provided for CVE-2020-2021are clear, but as of 07/03/2020, the patched versions have not yet been tested by the Randori Attack Team to confirm the efficacy of the fixes.
Sources
- https://security.paloaltonetworks.com/CVE-2020-2021
- https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-admin/authentication/configure-saml-authentication.html
- https://saml-doc.okta.com/SAML_Docs/How-to-Configure-SAML-2.0-for-Palo-Alto-Networks-GlobalProtect.html
- https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
- https://developer.okta.com/docs/concepts/saml/
