How the SolarWinds breach highlights the dangers of federated authentication – and what you can do to protect against it

The SolarWinds breach (also known as Solarigate or Solorigate) that made headlines in December 2020 opened many eyes to the issues of indirect attacks.

My aim here is not to go through the actual attack in great detail – more than enough has been written about that to keep people reading for hours.

Instead, my aim is to get you to examine whether this style of attack is something that you can discover and react to. I’ll also offer advice on what you can do to remove as much risk as possible from your environment by addressing how you authenticate.

SolarWinds: A quick recap

As we now know, the attackers gained access to the SolarWinds source code and injected malicious code directly into it. This code was then included in the distributed code from March 2020 until it was detected.

This breach is a particular cause for concern as SolarWinds are a leading IT infrastructure supplier, spanning network, systems, database, applications, and security management. This means that their systems are deeply ingrained across thousands of organisations.

Typically, organisations are encouraged to patch servers regularly and keep them up to date. With SolarWinds, this became the dispersal method for the attack. As the core software is updated, the malware is installed and starts to send details out to the attackers.

This was not a quick, smash and grab breach but a long-term, planned, patient attack. The timeline is extensive and has been traced back as far as September 2019.

• September 4 2019: Attackers start accessing SolarWinds.
• September 12 – November 4 2019: Attackers inject test code.
• February 20 2020: Solarigate backdoor is compiled and deployed.
• March – May 2020: Estimated start of Solarigate backdoor distribution, SUNBURST and target-profiling.
• May 2020: Estimated start of hands-on-keyboard attacks and activation of TEARDROP.
• June 4 2020: Attackers remove malware from SolarWinds build environment.
• December 12 2020: Solarigate supply chain attack disclosed.

Examining the attack shows a very careful approach that involves deliberate delays before the real breach began.

Since the initial disclosure, MimeCast, Malwarebytes, Palo Alto Networks, Qualys, and Fidelis have all reported that they were targeted following the breach. Quite a prominent set of organisations.

When this attack was being investigated, it showed that there was an opportunity for the attacker to access the federation services on-premises and use these to attack other services that used the federation for authentication.

Why is federated authentication an issue?

In the past, federated authentication has been used to provide security and single sign-on to external services and was recommended by organisations like the NCSC. I’ll come back to this in a moment.

Just because a third-party provides a security function doesn’t mean that you can take them at face value. As with other attacks, the communications from the malware to its host can be monitored and reported on.

When management software is installed, it should communicate internally, collating data from servers and systems to do its job. It may contact an external server, perhaps to validate a license or check for updates, but these external access points should be documented and provided as part of an allow list.

However, if the system starts to reach out to other services – ones that have not been disclosed by the vendor – then an alert should be raised, and the communications blocked. This monitoring and reporting should be put in place as soon as possible to ensure that any services you add are not communicating with outside systems that they shouldn’t be.

So, why did I mention federation earlier? Well, one of the issues with the SolarWinds attack was the potential for an on-premises ADFS service to be broken. This break may allow the attacker to spoof the identity of any individual and access a third-party service.

Once in that service, they could add in their own IDP, create additional accounts or anything else that a system administrator might do.

So, what can you do to prevent spoofing?

Moving from ADFS to cloud-based authentication using password hash synchronisation (PHS) or pass-through authentication (PTA) is critical.

If a third-party service can authenticate against Azure AD rather than ADFS, the ability for an attacker to spoof the identity is reduced. Even with full administration access to the internal directory services, an attacker can’t gain access to the certificates needed to spoof an identity.

It is worth remembering at this point that the on-premises administration accounts should NOT have any form of administration access to the cloud services. One thing we don’t want is to lose the administration to both cloud and on-premises through a single account being compromised.

You should ensure that the cloud administration accounts are cloud-only and do not have any presence on-premises.

Moving from ADFS (or another federation provider) is not the scary prospect that it was a few years ago. A staged migration, allowing you to migrate some users and test how they work in real life, means that you can be confident in the migration going well.

Moving any relying parties from ADFS to Azure should be performed one service at a time, as that provides the option of a simple roll-back should that be required. Since Azure AD supports “seamless single sign-on” from domain-joined devices without using ADFS, the user experience can be enhanced.

Conclusion

While the Solarigate (or Solorigate) event has brought working with third-party software into focus, it’s not something you should be panicking about. Instead, use it as an opportunity to consider the potential risks of software being used within your network and its communications with outside services.

It should also provide a catalyst to make the move from ADFS authentication to Azure-based authentication with the options for single sign-on to third-party services.

This can ensure that authentication is secure (supporting multi-factor authentication using an app, FIDO 2 or OATH tokens) and much harder to co-opt for nefarious purposes.

The integration of the seamless SSO functionality for domain-joined devices ensures that the user experience is maintained or enhanced through direct authentication.

Key takeaways