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.

  1. SAML authentication is in use.
  2. The system is configured not to validate the IdP’s certificate.
(Figure 1)  SAML Identity Provider Server Profile configuration screen (Source) Tenable

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.

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:

A static quotation is not available for this X post.

View the original post on X

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.

  1. Apply the patch released by Palo Alto Networks.
  2. 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