If you are generating SAML signing certificates externally, STOP!!

Earlier thought impossible, there is now a way to forge security assertion markup language (SAML) authentications even for applications that have adopted a cloud identity solution.

Application providers, such as Salesforce and ServiceNow, that moved their SAML authentication workload to a cloud identity system such as Entra ID are still open to the Golden SAML attack used in the SolarWinds hack in 2020, according to a research by Semperis.

A new technique, dubbed Silver SAML, has been demonstrated in a proof-of-concept (POC) put together by Semperis researchers Tomer Nahum and Eric Woodruff. The POC is capable of forging SAML responses generated by identity providers (IdP).

“In the wake of the SolarWinds hack, CISA and cybersecurity experts encouraged organizations to move SAML authentication to a cloud identity system such as Entra ID,” Semperis said in a note. “This new attack path will take advantage of even those organizations that followed the security recommendations meant to defend against Golden SAML.”

SAML is a protocol for the exchange of authentication and authorization data between two trusted parties, generally an identity provider and an application. Authentication is carried out through the “SAML signing certificates,” which follow an asymmetric form of cryptography using a combination of private and public keys to authenticate access.

What are SAML forging attacks

Golden SAML was a post-breach attack used in the SolarWinds breach where attackers abused access to Solarwinds’ network (servers and applications) gained through a primary infection to get into a customer’s Active Directory Federation Services (ADFS) component, a Single Sign-on (SSO) service developed by Microsoft.

Once inside the ADFS, the attackers “could steal data, a private key, needed to speak SAML to the business applications, impersonating authentication, and users,” Semperis researcher, Woodruff, said.

Switching to a cloud identity provider was recommended by cybersecurity experts as it promised better private key security.

With Entra ID, the private key used to perform a Golden SAML attack is stored in a way that only Microsoft services can access it, Woodruff explained. While with ADFS, an administrator, or an attacker who has administrator access, can write and read the private key, with Entra ID, only administrators can write it, so an attacker cannot read it.

Silver SAML abuses externally generated certificates

When applications are configured with Entra ID to carry out SAML authentications, generation of the SAML signing certificates is defaulted to Microsoft. Therefore, by default, because you cannot export the private key portion of the certificate, an attacker will never be able to obtain it, Woodruff explained.

However, owing to enterprise policies and requirements, an administrator can sometimes obtain this certificate externally, subsequently uploading the private and public key portion to Entra ID. “It’s the exposure that occurs between wherever and however they got that externally generated certificate and uploaded it to Entra ID that becomes a risk, as it leaves places that an attacker could try to find the private key,” Woodruff added.

Organizations, according to the POC, often tend to generate signing certificates on a client system, through an enterprise public key infrastructure (PKI), such as Active Directory Certificate Services (AD CS), or from an external certificate authority (CA). There on, to add to the risks, they use these certificates through insecure channels such as Teams or Slack, on client machines, leaving the certificates available for export in the machines’ local certificate store, or on web servers, typically running Microsoft Internet Information Services (IIS), leaving the certificates available for export.

“With Golden SAML, the attack was very straightforward — you get administrator access to ADFS, you repeat specific steps to obtain the private key, and you are speaking SAML,” Woodruff said. “Silver SAML, from an attacker’s perspective, would have a lot more chance to it — if the target is not performing these bad habits with certificate management, there is no chance of the attack happening.”

Mitigation can be tricky

Silver SAML attacks can be avoided entirely by sticking to using certificates generated within Entra ID (or similar cloud-based SSO services).

However, this is not ideal for many organizations as they tend to lack a chain of trust with self-signed certificates from Entra ID, have an inability to leverage certificate revocation with self-signed certificates, or have a subjective feeling that self-signed certificates are “less secure.”

Certain features can also be configured within SAML to help protect from such attacks, but not without a cost. “Application developers can implement certain features of SAML that prevent this attack. However, they might bring a trade-off for end-user usability, and complicate troubleshooting if something breaks with SAML,” Woodruff added.

Often, an enterprise security team will require that administrators use externally generated certificates when configuring SAML. These certificate management and lifecycle practices have valid and required use cases in many security scenarios that use certificates, but they’ll all leave the applications open to Silver SAML attacks, according to Woodruff.