In light of the SolarWinds attack, should your organization migrate to Azure AD SSO?
How did they get in?
…and what your organization can do to stop them.
If you haven’t heard, a breach affecting the Texas-based IT monitoring and management solutions company, SolarWinds, has resulted in a global cyber espionage campaign. This campaign is believed to have compromised the networks of various US government agencies, Fortune 500 companies, and leading telecommunications giants.
Hackers behind the breach, widely-believed to be Russian-sponsored, did so by compromising the SolarWind’s Orion build system which delivered malicious code within the “normal” system updates process.
This malicious code allowed for the hackers to execute an Active Directory Federation Services (ADFS) bypass technique (now labeled "Golden SAML”), which enabled them to maintain continuous access of systems and services that leverage ADFS for authentication, even if those services are otherwise unrelated. Examples of services include:
Travel systems
Hosted business intelligence applications
File storage services like SharePoint, hosted email services, and time-card systems
The Golden SAML attack is based on the ADFS authentication method. Ok... but how should a “normal” authentication process work?
Employees attempt to access a service like Office 365 or AWS
The service redirects the employee to ADFS to be authenticated
ADFS applies a domain policy, such as multi-factor authentication to verify a user
ADFS returns signed SAML response to the employee's computer
The employee presents the signed SAML response and gains access to the service
Source: Sygnia.co
How does a Golden SAML attack compromise ADFS?
During a Golden SAML attack, an attempt to access a federated service redirects a user to request ADFS authentication. The attackers can use the stolen keys to forge a SAML response and gain unauthorized access. ADFS attack vector enables hackers to gain unauthorized access to critical infrastructures without escalating access permissions across the victims' environments. The ADFS attack vector provides hackers with continued access unless the ADFS private key is replaced and invalidated. However, such a task would require administrators to alter or terminate all federated services and systems' connectivity.
The figure below shows how attackers first compromise the target ADFS to extract the private key and certificate, forge SAML response, and use it to access critical services and information.
Cyber adversary accesses the target ADFS and extracts the private key and certificate
An attacker attempts to access a service
The service redirects the hacker to ADFS for authentication
The attacker signs a forged SAML response using the stolen key to bypass ADFS authentication.
The cybercriminal presents the signed the SAML response to gain access to services holding critical and sensitive information
Source: Sygnia.co
…but what about access controls?
Yes, many of the affected organizations understood that ADFS servers are critical infrastructure and took steps to implement proper access controls; however, the SolarWinds’ Orien tool is used as a monitoring solution - which requires privilaged access… access to servers like ADFS.
Once hackers compromised their victims internal networks (via the SolarWinds malicious code), they used the associated privilaged SolarWinds accounts to gain access to their victim’s ADFS servers, and then execute the Golden SAML attack to steal private keys and signed certificates from the ADFS servers.
These stolen private keys and signed certificates gave the hackers unrestricted access to their victim's network despite the implemented access controls.
Hackers are the worst… How do we mitigate this attack?
The SolarWinds attack has drawn attention to the ADFS attack vector, raising the likelihood that other hackers will try this (or similar) exploits in the future.
Migrating from the ADFS to other, more secure, identity management solutions like Azure Active Directory Single Sign-On (Azure AD SSO) may be the best way to mitigate this risk.
In contrast to the ADFS approach that requires users to request a signed certificate and private key, Azure AD SSO is designed to sign-in users automatically once their corporate devices connect to the organization's corporate network. When the option is enabled, users aren't required to type in their usernames/passwords to sign in into the Azure Active Directory. This feature provides a more secure and easy way of accessing cloud-based applications without the need to access additional on-premise infrastructure components.
Why migrate?
Protect companies from Golden SAML: Unlike ADFS, Azure AD SSO does not require additional components or servers to authenticate and sign in users. It prevents hackers from hijacking and redirecting sign-in requests to gain unauthorized access to a user's environment.
Supports multiple authentication methods: Azure AD SSO can automatically sign in users connected to the corporate network, and still enable them to sign in to Office 365 if the AD Connect or corporate network is unavailable. The method provides a combination of SSO, pass-though authentication, and password hash synchronization.
Azure Active Directory supports Seamless Single Sign-On: Azure AD SSO provides both Office clients and web browser-based clients with seamless single sign-on. The support is instrumental in ensuring that Azure AD SSO can be applied in platforms with a modern authentication method or web browsers using Kerberos authentication.
Supports unique application certificates: Compared to the standard deployment model for ADFS where a shared certificate is used for many applications, Azure AD SSO supports each application getting its own certificate - mitigating the risk of a compromised certificate being used to access various systems within an environment.
Not sure if this is the right solution for your organization?
Please fill out our contact form to see how we can help.