On July 1, the following article came across my feed.

However, the article alone does not explain what kind of vulnerability this actually is, and the relevant page on the Palo Alto Networks website is no clearer. I have been so busy lately that I had not had a chance to look into it, but I had decided not to work today, Saturday, so I did a little research. Though all I really did was consult other sources.
Of those, I found Tenable‘s explanation detailed and useful.
Prerequisites for a Successful Attack
According to that explanation, the following 2 prerequisites must be met for this attack to succeed.
- SAML authentication is in use.
- The system is configured not to validate the IdP’s certificate.

You may wonder, “Would anyone really configure a system not to validate the IdP’s certificate?” But this is quite common. This is what happens when a self-signed certificate is used; it is, in a sense, a raw key. According to the article above, the following products actually appear to recommend this configuration.
- Okta [Image]
- SecureAuth [Image]
- SafeNet Trusted Access [Image]
- Duo [Image]
- Trusona via Azure AD [Image]
- Azure AD [Image]
- Centrify [Image]
That is quite a lineup of major vendors. And from a security standpoint, there is nothing wrong with this.
What Is Happening?
Now, here is the security flaw you have been waiting for. With the setting shown in (Figure 1), only the certificate chain and revocation checks for the certificate the IdP uses to sign should be skipped, right? But it appears that the system was actually skipping verification of the IdP’s signature on the SAML Assertion as well. I do not know whether signature verification is skipped for every SAML Assertion or only under certain conditions, but it seems clear that, when those conditions are met, even administrator privileges can be obtained. That makes this a maximum-severity vulnerability—a situation in which you are not protected at all even though you think your VPN is protecting you.
When I first read the ITmedia article, it described the issue as “improper signature verification,” so I thought it was yet another signature bypass caused by XML canonicalization in an XML signature, and wrote:
But apparently that was not the case. It seems this was instead an instance of the “PKI came too early for humanity” problem.
Mitigations
There are 2 ways to address this.
- Apply the patch released by Palo Alto Networks.
- If the patch cannot be applied immediately, replace the self-signed certificate used by the IdP with one issued by a CA, and enable validation of the IdP’s certificate.
Those are the options. There do not yet appear to have been any actual attacks, but please be aware that this issue must be addressed as soon as possible.
Related posts

The Boy Who Cried Wolf: Another 1 Major Vulnerability Found in Popular Open-Source Security Software?!—CNET Gets It Completely Wrong
“Following the OpenSSL vulnerability ‘Heartbleed,’ another 1 major vulnerability has been found in popular open-source security software. This time, the vulnerability was found in the login…

Considering the Risks of Twitter’s 230 million-Person Data Leak
In 2023, during the early hours of January 6, Bloomberg’s report “Twitter May Have Leaked Information on More Than 230 million People” came across my feed,…

The WebSocket Unauthenticated Vulnerability in 1Password
In The XARA Vulnerabilities in MacOS X and iOS[1], I wondered why the original article[2] said that AgileBits, the maker of 1Password, also considered the issue…

You must be logged in to post a comment.