Scoped User Identifiers

Recently a serious flaw was found in Office 365:

http://www.economyofmechanism.com/office365-authbypass.html

You should of course review the report and make your own determination but here’s a spoiler: The Office 365 application neglected to scope-check a user identifier, which allowed an arbitrary identity provider to assert any identifier whatsoever and thereby gain unauthorized access to the application.

Here are a few lessons learned from the Office 365 vulnerability.

The Office 365 incident revolved around the following SAML attribute:

<saml2:Attribute FriendlyName="IDPEmail"
      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
      Name="IDPEmail">
   <saml2:AttributeValue
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:type="xsd:string">ikakavas@mymail.example.com</saml2:AttributeValue>
</saml2:Attribute>

From a SAML perspective, there are a number of problems with the IDPEmail attribute shown above but the point that matters most is: The IDPEmail attribute is not an email address at all. Its value may look like an email address, but in fact, the IDPEmail attribute corresponds to the User Principal Name (userPrincipalName or UPN) of the existing account of the user in Azure AD.

That’s an important observation: The IDPEmail attribute is an identifier, and moreover, it is actually used by the Office 365 application for access control. That leads directly to our next observation.