Golden SAML: A Tool, Not An Attack
A blog article has been circulating in the press with claims of new attack technique that allows forging of identities to cloud applications, dubbed “Golden SAML”: Golden SAML: Newly Discovered Attack Technique Forges Authentication to Cloud Apps.
The author Shaked Reiner’s choice of the word “attack” is unfortunate, as the distinction between attacks, exploits, vulnerabilities, tools and techniques are crucial in understanding information security disclosures.
Like many recent high-profile published security exploits such as Heartbleed and Dirty COW, Golden SAML includes a catchy name, graphic logo, technical jargon and even code. Heartbleed and Dirty COW exploited real vulnerabilities in security code and protocols, whereas Golden SAML and corresponding shimit tool use the SAML protocol as designed, needing highly-privileged access to the Identity provider’s infrastructure systems and private keys to forge identities. This makes Golden SAML and shimit a security tool, not an attack.
Reiner concedes this distinction in his summary that this is “not a vulnerability per se” and “This attack doesn’t rely on a vulnerability in SAML 2.0. It’s not a vulnerability in AWS/ADFS, nor in any other service or identity provider.” and goes on to say “Golden ticket is not treated as a vulnerability because an attacker has to have domain admin access in order to perform it. That’s why it’s not being addressed by the appropriate vendors.” Golden SAML and the shimit tool can only be used in a scenario where there is an untrustworthy administrator with highly-privileged access, or completely compromised identity system.
Nor is Golden SAML newly discovered. As Robb Reck, CISO of Ping Identity correctly points out in his excellent Golden SAML response, forgery was a consideration during the design of OASIS SAML 2.0 protocol back in 2005. Section 6.4.3 of the OASIS SAML V2.0 Security Considerations specifically calls out forgeries and provides message integrity and authentication as countermeasures. Security measures for message integrity and authentication go back even further to 1983-1985 in the DoD Trusted Computing System Evaluation Criteria(TCSEC) Orange book.
With these countermeasures designed in the protocol, Security Assertion Markup Language (SAML) Identity assertions are valid only for a few minutes and are signed using public key cryptography and verified by the partner in that short time window. This alone makes assertions tremendously difficult to forge from the outside.
Another practical limitation not mentioned in the article is this forging attempt is only mildly practical in an Identity Provider (IdP) initiated authentication flow, one would still need to grab and reuse the session identifier (usually a session cookie) to enact a session with the cloud application. Forging assertions as an IdP in a Service Provider (SP) initiated authentication flow would require setting up a whole rogue domain, certificates and circumventing DNS to capture the authentication request from the SP.
A SAML forgery with Golden SAML and the shimit tool would be akin to forging a passport at the passport printing authority. Passports would be easy to forge for someone who worked inside of the passport authority with access to the official printers, materials and systems. Even then, a forger with that high level of access to the passport printing office would be trivial to track down with sensible auditing and logging practices.
As with the passport security measures, any properly managed identity system has layers upon layers of security to protect their trusted systems and private keys from running forgery tools like shimit. Along with systems security, the SAML protocol itself provides many of these security layers in its design.
Signing key rotation for any identity security platform can be a chore. Along with cloud key management systems and hardware security modules, I expect recent developments in asynchronous forward secrecy algorithms such as Double Rachet to prove useful in confronting these key rotation challenges. Perhaps these types of key management algorithms will be incorporated into future versions of SAML and other related identity protocols.
While not an attack on the SAML protocol, Golden SAML/shimit provides another tool to build better identity systems. Golden SAML really shows its value bringing to light the importance of a comprehensive security strategy that incorporates strong key protection and key rotation.