Several sources have recently reported the discovery of a ‘flaw’ in certain SAML implementations that could allow a ‘bad actor’ to alter the identity carried in a Single Sign-On SAML assertion and legitimately log in as a different user as reported by TechTarget.
Wow – that’s bad! That was my initial reaction, and I envisioned a case where the ‘flaw’ would allow the bad actor to substitute *ANY* username as the identifier in the Single Sign-On SAML assertion. Fortunately, that is *NOT* the case! Kudos to Kelby Ludwig at Duo Labs for the excellent detailed analysis and description of the exploit.
Kelby shows how some Service Provider implementations of certain SAML packages allow for NameID *TRUNCATION* if the SAML Assertion is intercepted and a comment is inserted into the NameID string.
So, that’s a LOT better than a wholesale change to the NameID! The exploit then is subject to some very specific constraints and conditions. Here’s a sample scenario:
The bad actor wants to gain access to the CFO@corp.com account in the GlobalBrokers Software as a Service (SaaS) application on the Internet.
The bad actor could then:
Now, with a valid account at GlobalBrokers that uses SAML Single Sign-On from PublicIDP, the bad actor can:
The GlobalBrokers logon service will honor the assertion as signed by PublicIDP, but use only the portion of NameID that precedes the comment string : “CFO@corp.com”
The bad actor then gets a legitimate logon to the CFO@corp.com account in the GlobalBrokers application! Not good.
Note that some articles/vendors suggest using Two Factor Authentication as a protection against this exploit. However, the Two Factor Authentication transaction is typically enforced by the Identity Provider and precedes the construction of the SAML assertion. In that case, the exposure remains the same. For Two Factor Authentication to be a protection against this exploit it would need to be enforced by the Service Provider (SaaS application) after consuming the SAML assertion.
So, how exposed are your enterprise and SaaS subscriptions? Probably not very exposed at all. For this exploit to be effective, the bad actor needs to craft a username in the application that has the target username as the leading characters in the identifier, and the application needs to honor the single Identity Provider assertion for any user in the system. Most applications use the domain name as part of the identifier and segregate tenants by domain name, requiring a unique trust with the Identity Provider for each domain/tenant, so a SAML signature for “.badactor.com” would not be valid for, nor have visibility to, “corp.com” accounts.
With SaaS applications typically using user@domain.com as the account identifier format, this exploit cannot be used since it requires appending a distinguishing string to the target identifier and that effectively makes it a different domain and thus a different tenant.
However, if your application does not use the “@domain.com” format as the trailing part of the username/identifier you should examine all the user accounts and identify those where the whole username/identifier is also the leading substring of another username/identifier:
With the cited SAML packages and configurations in service, the “Cforest” account could gain access to the “CFO” account using this exploit. (Cfo<!—->rest)
Although frightening at first blush, the details reveal that it is likely not a threat to most enterprises and applications that use SAML Single Sign-On – but you *MUST* check! Enterprise Information Security is a never-ending process. It requires vigilance and evolving/adapting applied technologies to protect the enterprise and thwart the assaults.
As part of the team at CTI, we proactively share this potential exploit with our clients and help them assess their potential exposure. Certainly, worthy of a discussion with your security team or security partner.