The blog post on Wiz.io (https://www.wiz.io/blog/storm-0558-compromised-microsoft-key-enables-authentication-of-countless-micr) provides an in-depth analysis of a security violation involving Microsoft and the Cybersecurity and Infrastructure Security Agency (CISA). This violation was linked to a Chinese threat actor, Storm-0558, who managed to secure a private encryption key (MSA key) and used it to generate fake access tokens for Outlook Web Access (OWA) and Outlook.com. Moreover, the threat actor took advantage of two security flaws in Microsoft's token verification system.
Despite Microsoft's claim that only Outlook.com and Exchange Online were affected by the token forging technique, the compromised MSA key was discovered to be more powerful than initially estimated and was not restricted to these two applications. In today's digital world, signing keys from identity providers are viewed as some of the most critical secrets. The leakage of a signing key from Google, Facebook, Okta, or any other major identity provider could lead to unimaginable consequences. The full impact of this incident is far greater than initially comprehended. Wiz researchers found that the compromised key could have allowed the threat actor to generate fake access tokens for various Azure Active Directory applications, including SharePoint, Teams, OneDrive, and customer applications that support the “login with Microsoft” feature. This incident underscores the risks and drawbacks of centralized Identity Provider Keys.
However, there is a silver lining for users of the “CodeB Identity Broker” and the “CodeB Authenticator”. It is possible to detect if a token was maliciously issued by a bad actor using a leaked key. CodeB does not rely on a centralized key. Instead, the mobile device itself acts as the Identity Provider using a key generated and stored securely on the device. Users can verify the authenticity of a logon token by enabling the built-in user attribute “Identity Provider” in the Azure AD B2C workflow, a practice likely already adopted by most users as token validation is generally good practice. If this feature is enabled, the issued OpenID Connect Token of Azure includes a claim “idp_access_token”. This value allows the retrieval and validation of the token issued by the CodeB Identity Broker, which should be enough to detect if the token was artificially created by a bad actor. For added security, the token issued by the mobile device using the mobile's signing key can also be validated by reading the attribute “m_token” from the CodeB’s Identity Broker's Token.
In conclusion, the incident underscores the importance of adhering to "good practices" in the realm of cybersecurity. By validating the complete chain of tokens, malicious activities by bad actors can be detected immediately, effectively eliminating any chance they might have to exploit the system. This incident serves as a reminder that vigilance and stringent security measures are our best defense against such threats. The use of tools like the “CodeB Identity Broker” and the “CodeB Authenticator”, and the practice of validating the authenticity of tokens, are crucial steps in maintaining a secure digital environment. By ensuring these measures are in place, we can significantly reduce the risk of security breaches and keep our systems safe from potential threats.
