An attack technique, christened “Golden SAML”, has recently been documented in an article published on CyberArk’s blog. Although novel in the way it is carried out, the attack presented here makes use of a tried and tested principle.
This attack method concerns all services using SSO solutions that are based on the SAML2 protocol (excluding HSM implementation).
What is golden SAML?
The title of the blog post isn’t innocuous since “Golden SAML” is a nod to the “Golden Ticket” attack which targets the Kerberos protocol. Like Golden Ticket, Golden SAML allows an attacker to access to resources protected by SAML agents (for example: Azure, AWS, vSphere, Okta, Salesforce, etc.) using enhanced privileges provided by a “golden ticket”. It also allows the attacker to work in the shadows without being identified, because after the attack, tokens can be generated outside the information system without making a request to the Identity Provider (IdP).
In a standard series of SAML process steps:
- The client tries to access an application (the Service Provider).
- The application generates a “SAML AuthRequest” to authenticate the user.
- The Identity Provider (IdP) authenticates the user and sends a “SAML response” to the user, which can be used to access resources exposed by a Service Provider (SP).
- The SP checks the response and identifies the user, who is now authorized to use the service.
The attack is based on the falsification of the SAML response that identifies and authenticates the user. The response is signed by the Identity Provider’s private key, and may be encrypted, depending on the implementation. By verifying the integrity of the SAML response checking its signature, the application ensures that this has definitely been generated by the Identity Provider and has not been modified in transit.
To falsify the answer, several pieces of information are needed:
- The Identity Provider’s private key
- The Identity Provider’s public certificate
- The Identity Provider’s name
- The name of the role to be spoofed (e.g. administrator).
The only information that is genuinely complicated to obtain is the private signature key of the SAML response. The other three data items can be easily accessed, especially in the responses.
It’s possible to export the private key by accessing the IdP using an AD FS admin account. An initial attack on this account is a prerequisite for compromising the key.
Once the relevant information has been gathered, the attacker will be able to freely generate genuine responses, outside the domain, without being spotted. Setting up strong authentication on the accounts being targeted provides no protection from attack because the proof of this authentication is provided by the SAML response, something that can now be falsified.
As long as the IdP certificate is not modified, and the change is not taken into account by all Service Providers, the attack can keep up.
Decoding the attack
Despite the alarmist tone of the blog post, the vulnerability described can be attributed to questionable design choices in the SAML 2 protocol—which uses signed tokens—but not to a real security breach. Indeed, the necessary condition is that an AD FS administrator account has been compromised to retrieve the domain’s private key. However, the impact is high since the attacker can—in an unconstrained fashion and from outside the domain—access services protected by SAML agents that trust the domain. The retrieval of an IdP account can be detected, but the falsification of responses can be carried out with total discretion after the event.
In addition, if the compromise of an IdP administrator account is detected, changing the password on the account will not give back it confidentiality to the private key, and will not allow a Golden SAML attack to be countered. Therefore, the only solution to block an attacker is to change the private key, which can have a major impact on Service Providers who rely on the IdP: it means the temporary rejection of the signed responses signed with the new key.
Ultimately, private key theft renders identity federation vulnerable, which is not a new idea. SAML IdPs are concerned here, just as any security protocol that issues signed items would be (OpenID Connect, PKI, etc.).
How to prevent risk?
The security of SAML tokens relies primarily on the IdP’s private key—and it’s imperative that all necessary means to protect it are put in place.
There are two approaches for storing and using this key: a software solution and a hardware solution.
The software solution
In this solution, the key is stored on a server responsible for keeping it secret and performing the signature operations of the responses. This will ensure that the machine and its environment are well protected. For this, it is recommended that several normal security recommendations are applied: isolating the machine on an administration VLAN, restricting its access to essential operators, securing—via multi-factor authentication—the privileged accounts that have access to the key, regularly applying security patches to the machine, logging access, and setting up SIEM rules adapted to the IdP, to detect intrusions, etc.
While these preventive measures help limit the risks of the key being compromised, they cannot guarantee with any certainty that it has not been, or will not, be misappropriated. Therefore, it makes sense for the IdP certificate and its private key to be renewed at regular intervals, or when there is doubt relating its confidentiality. When an IdP certificate is renewed, the Service Providers will need to accept the tokens without interrupting access by ensuring that they can seamlessly retrieve the certificate, and accept the tokens signed by the key,whileinvalidating the old certificate. This can be done by exposing the new certificate on a dedicated endpoint.
However, some edge effects often appear during key rotation (impacts on the Service Provider, for example). Similarly, it’s rare that a Service Provider can support key revocation via a CRL.
The hardware solution
The hardware solution, which relies on the use of a Hardware Security Module (HSM), is much more robust because it guarantees the total security of the signature key. The module is responsible for protecting the key and performing all the cryptographic operations required for the signing process. The key never leaves the HSM, and the generation of a token outside the IS becomes impossible.
However, the IdP will have to protect the secret information that allows it to request the HSM by following the normal recommendations set out above. f this secret is compromised, it can be regenerated without impacting the Service Providers because the signing key is not modified.
