Here's a good example of why SHA-1 collisions are so serious:
Let's say there's a cloud service where you configure SAML by setting the SHA-1 thumbprint of your identity provider's response signing certificate instead of uploading the IdP's XML metadata or its signing certificate directly.
If an attacker can create their own SAML response signing certificate that hashes to the same value as your identity provider's, the attacker can forge seemingly valid SAML responses that would give them access to the cloud service. This attack would work because in SAML, the following things are true:
1. The public half of the key used to sign a SAML response is embedded in the response alongside the signature.
2. SAML does not use PKIX's hierarchy of certificate authorities, only the X.509 public key certificate format.
Trust relationships between SAML identity providers (a/k/a credential service providers) and SAML service providers (a/k/a relying parties) are normally established by directly exchanging entity metadata that includes at a minimum the identity provider's signing certificate or by using metadata aggregates signed by a trusted third party (e.g., all multilateral trust federations—eduGAIN, JISC, InCommon, INFED, etc.) But in this thought experiment, an attacker would be able to generate their own signing key-pair and append whatever junk to the user-defined fields of the X.509 public key certificate is needed to cause a SHA-1 collision.
That's basically how the Shattered proof of concept works, only using junk JPEG data embedded in a PDF:
Here's a good example of why SHA-1 collisions are so serious:
Let's say there's a cloud service where you configure SAML by setting the SHA-1 thumbprint of your identity provider's response signing certificate instead of uploading the IdP's XML metadata or its signing certificate directly.
If an attacker can create their own SAML response signing certificate that hashes to the same value as your identity provider's, the attacker can forge seemingly valid SAML responses that would give them access to the cloud service. This attack would work because in SAML, the following things are true:
1. The public half of the key used to sign a SAML response is embedded in the response alongside the signature.
2. SAML does not use PKIX's hierarchy of certificate authorities, only the X.509 public key certificate format.
Trust relationships between SAML identity providers (a/k/a credential service providers) and SAML service providers (a/k/a relying parties) are normally established by directly exchanging entity metadata that includes at a minimum the identity provider's signing certificate or by using metadata aggregates signed by a trusted third party (e.g., all multilateral trust federations—eduGAIN, JISC, InCommon, INFED, etc.) But in this thought experiment, an attacker would be able to generate their own signing key-pair and append whatever junk to the user-defined fields of the X.509 public key certificate is needed to cause a SHA-1 collision.
That's basically how the Shattered proof of concept works, only using junk JPEG data embedded in a PDF:
https://shattered.io/static/pdf_format.png