SolarWinds & SuperNova Cyber Attacks
The Case for Better Secrets Management

In our last blog, we argued the case for decentralization & passwordless identity in the wake of the SolarBurst & related cyberattacks. Eliminating shared credentials like passwords goes a long way to enhance the zero-trust security posture of any organization. But a complete zero trust identity solution must go well beyond simple user identity.

The SolarBurst attacks have reinforced our concern about weaknesses around identity federation tools like SSO, SAML & OAuth. The weaknesses do not emanate from SAML or OAuth technologies themselves, but in the management of secrets (encryption keys) that are crucial for identity federation. Microsoft released customer guidance that highlights how SAML private keys, particularly those managed on-premises, could be compromised to bypass authentication to affect federated services including cloud hosted email.

https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/

While SAML keys were compromised in the above attack, other federated tools like OAuth also carry a similar risk. Encryption secrets that are stored inside applications, authentication or federated servers carry significant security risks as the recent security incidents have highlighted. Compromise of these secrets can negate a good authentication by the end user to the IdP server.

The SolarBurst attacks could also have had an attack vector that bypassed MFA authentication. An insightful research by Volexity details how attackers bypassed MFA authentication by compromising the secret keys that are vital to MFA.

https://arstechnica.com/information-technology/2020/12/solarwinds-hackers-have-a-clever-way-to-bypass-multi-factor-authentication/

A latest advisory by US CERT also alludes to API authentication bypass in the recent attacks. API usage has surged in the recent past while API access is still not sufficiently protected against loss or misuse of API tokens.

https://www.kb.cert.org/vuls/id/843464

It is clear that strong identity & access management is not achieved until shared secrets used in federation, MFA & API access are strongly protected. There are ways security around identity secrets can be strengthened:

• Conduct a thorough review of existing secret management to correct risky implementations.
• Where possible, use Hardware Security Module (HSM) to protect private keys behind SAML, OAuth or MFA. Most cloud providers offer Key Management Service (KMS) based on HSM.
• HSM offers strong security, but can be expensive & increase latency, especially for applications that operate near edge & also with voluminous need for secrets. Also, a number of organizations will continue to need to manage secrets on-prem. For on-prem secret management needs, HSMs are not practical. Also, despite the pitch to move Active Directory completely to cloud, it is not possible in a number of use cases. Another alternative would be a software, cloud-based alternative to HSMs that can be deployed easily on any secure hardware.
• Ensurity’s EnSafe cloud native secret management platform offers a scalable alternative to HSMs. EnSafe can be used to manage secrets on cloud as well as on-prem. EnSafe eliminates the risk of storing secrets in one location. Secrets are split & stored on both EnSafe & IdP servers (EnSafe agents sitting near the IdP/App server). Neither EnSafe nor IdP servers (EnSafe agents) store full secret at any point of time.
• For making a SAML assertion, the IdP server sends assertion request after authenticating to the EnSafe server. Upon authentication, EnSafe server sends its part secret to the EnSafe agent. The EnSafe agent creates the full secret to complete the signing. Memory of EnSafe agent is dog-washed – the secret is not stored in the agent after the signing. The secrets can be time bound as well, which means re-authentication is necessary to complete the signing

• EnSafe implementation can be done without agents as well, but the approach based on agents is highly scalable & reduces latency significantly.
• EnSafe instance can be deployed in enterprise’s own secure hardware, on-prem or cloud.
• EnSafe secret management can be incorporate in DevSecOps such that secret management errors are eliminated.
• When EnSafe is combined with a strong passwordless solution like XSense, federated access can be integrated with user authentication, ensuring continuous protection from theft of SAML or other federation keys.
• For protecting app to app access, XSense app security module can be deployed to offer a built-in two factor for API keys. API auth bypass as seen in the SolarWinds case can be prevented with an additional challenge-response using XSense. XSense is a zero-trust, distributed, complete passwordless solution from Ensurity to eliminate the single biggest source of recent cyber attacks.

Strengthening identity & access management will greatly enhance an organization’s ability to withstand cyberattacks similar to those seen in the SolarWinds case. Deploying a passwordless identity solution will strengthen user identity management. However, comprehensive security in identity & access is achieved only when federation is handled securely. A comprehensive look beyond mere user authentication is required to achieve zero-trust identity.