Security researchers in January discovered a critical vulnerability in the SAML implementation in Microsoft’s Office 365 service that could allow an attacker to log in to a victim’s account and gain full access to email, contacts, and other sensitive data.
The vulnerability was present in Office 365 for an unknown amount of time, and there is a long list of prominent companies that use the Web-based email and productivity suite, including Telefonika, British Telecom, Verizon, Microsoft, Cisco, Intel, and many others. The researchers who discovered the flaw said that an attacker targeting the vulnerability would be able to get to a wide range of important information on a victim’s account.
“A vulnerability in Microsoft Office 365 SAML Service Provider implementation allowed for cross domain authentication bypass affecting all federated domains. An attacker exploiting this vulnerability could gain unrestricted access to a victim’s Office 365 account, including access to their email, files stored in OneDrive etc.,” the researchers said in their vulnerability report.
SAML (Security Assertion Markup Language) is a standard that enables organizations to exchange authentication and other data, and it’s often used in single sign-on implementations. Microsoft’s Office 365 implements SAML, but does so in an odd way, according to Klemen Bratec from Šola prihodnosti Maribor, and Ioannis Kakavas from Greek Research and Technology Network, who discovered the vulnerability jointly.
“The first thing we noticed is that Office 365 SAML Service Provider disregards the Subject of the Assertion, even though it contains the ImmutableId value that should be the UUID of the user in the Azure AD that would uniquely identify him,” the researchers wrote.
“From an attacker’s perspective, the fact that the correctness of the NameID is not checked, makes things easier since the ImmutableID usually comes from AD objectGUID and it’s hard to guess or brute force.”
The problem comes in when Office 365 fails to prevent one identity provider from creating assertions for another domain’s users.
“As it turns out, the Service Provider used the Issuer of the Assertion only to find the mathing certificate in order to verify the SAML Response/Assertion signature, but didn’t perform any sanity checks on the supplied value of the IDPEmail attribute. That basically means that it would happily consume assertions, asserting that Identity Provider X has authenticated users of Identity Provider Y,” the researchers wrote.
The researchers were able to exploit the vulnerability on a test Office 365 tenant they had set up. They notified Microsoft of the vulnerability in early January and the company rolled out a mitigation and update later the same day. The researchers only disclosed the flaw on Wednesday, however.
Although the vulnerability is in the SAML implementation in Office 365, it is not limited to organizations that use SAML for single sign-on.
“So, this left us with another open question – what happens if we try to login with a user that has its domain federated using Active Directory Federations Services? Luckily, Šola prihodnosti Maribor (one of the partners in the discovery of this vulnerability, not a randomly selected victim) uses Office 365 with ADFS and it was therefore quite simple to answer this one. We added [email protected] to our someorg-attacker’s user directory, repeated the procedure described above and it worked!” the researchers said.
“The SAML Service Provider consumed the SAML assertion from the attacker’s org Identity Provider even though the spmb.si domain is configured to be federated with WS-Trust, forwarded it to the token translation service which translated it to an WS-Trust token and … we were in.”
