Microsoft Office365 SAML Vulnerability: Authentication Bypass
The vulnerability in the Microsoft Office 365 SAML implementation, published last week, dramatically underlines how important it is to handle account federations with due diligence. In the light that such a drastic authentication bypass can happen, not only at a small SaaS and cloud player, but at a provider of the size and importance of Microsoft, everyone should be aware that testing of SSO implementations should not be neglected and it should be an ongoing process.
We do not want to fully recap the vulnerability as there are detailed descriptions published by the researches Kakavas [1] and Bratec [2] who discovered the flaw. In this post we just want to quickly outline the flaw and describe how the vulnerability could be tested with a simple test procedure leveraging our SSOCheck services.
Quick outline and exploit of the Microsoft Office365 Authentication Bypass Vulnerability:
During a SAML single sign on flow the service provider receives a SAML assertion which contains the username (UPN). Office365 examined the SAML message and correctly checked that the assertion was signed by a trusted issuer proofing authenticity and that the assertion was not modified.
You should pay special attention to the phrasing “correctly signed by “a” trusted issuer”. Office365 did not check whether the username actually belonged to the organization of the assertion issuing IDP. In other words, they did not verify whether the IDP was entitled to vouch for the user.
That said the exploit was as follows: If you could control either a SAML IDP which was configured for SAML SSO with Office365 (basically any customer) or the user attributes, you could basically send an assertion with an arbitrary username of any other customer
Guide to test the Office365 SAML vulnerability with SSOCheck:
- Set-up an Office365 instance (say: mycompany.com) for SAML SSO and integrate it with the SSOCircle SAML Identity Provider (or our hosted IDP service)
- Enable the SSOCheck API for your user or hosted IDP
- Configure the SAML test #15 as depicted in the image below
- Run the test case
As a result of the flaw, the authentication to Office365 was successful and you were authenticated as user “bill” of the microxxx.com company -having access to emails, files, calendar and user data.
Remember: In that scenario Office365 should have accepted only assertions from the SAML IDP configured for the instance which include usernames of the mycompany.com domain.
It is really not easy to find such a flaw. But isn’t it easy to test against the vulnerability with SSOCheck?
If you are interested in our SAML test services, please check at our web site or drop us a message through the contact form.
References:
[1] Blog of Yiannis Kakavas
