ThirdSpace ThirdSpace
ThirdSpace Contact Us
Close 0 Reset Search Run Search What are you looking for? Type at least three characters to search. Filter Search Results
  • All Content
  • Blog
  • Page
  • Case Studies
  • Event
  • Resources
  • News
  • Careers
  • Access Centre
  • Technologies
  • Workshops
  • Service
  • Solutions
  • People
Load more
11 February 2021

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

Written by David Guest

Why you should view the SolarWinds news as an opportunity to improve your security by moving away from ADFS to cloud-based authentication.

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.

“One of the issues with the SolarWinds attack was the potential for an on-premises ADFS service to be broken.”

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.

Watch – Is it time to rethink your federated identity strategy?

Watch – Is it time to rethink your federated identity strategy?

Discover how to protect your key cloud-based assets by applying cloud-native authentication to your on-premises infrastructure. Watch and learn about:

  • Why relying on legacy authentication processes is such a risk
  • How to identify which authentication method is right for you
  • Top tips to mitigate the risks posed from SolarWinds-style attacks
Watch now

So, what can you do to prevent spoofing?

In my previous blog on ADFS, I talked about moving from ADFS to cloud-based authentication using password hash synchronisation (PHS) or pass-through authentication (PTA) with a strong recommendation to use PHS.

This is now much more important. 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

  • Monitor for unexpected communications from on-premises services to the cloud.
  • Investigate the move to cloud-based authentication instead of using ADFS.
  • Monitor your internal network for signs of a breach similar to the SUNBURST attack.
  • Don’t give up on patching – it’s still best practice to keep applying those updates.
Want more great security content? Subscribe to the ThirdSpace mailing list!

Want more great security content? Subscribe to the ThirdSpace mailing list!

Keep your finger on the pulse of security and Microsoft technology. Submit your business email to get the latest content and event invites straight to your inbox.

Next steps

About David Guest

Solution Architect and Technology Evangelist

As ThirdSpace’s Solution Architect and Technology Evangelist (yes, he knows it’s a long title), Dave has a background in IT that goes back to installing a piece of kit called a Microsoft Softcard in...

READ AUTHOR'S FULL BIO

You may also like...

Blog

What is Microsoft Identity Manager (MIM)? Everything you need to know

Blog

Uniting disparate directories: What is Azure AD Connect cloud provisioning?

Blog

The definitive guide to Azure AD: Everything you need to know

Recent Blog Articles

View All
Related topics

Watch – Rethinking federated identity

And discover top tips to mitigate the risks posed from SolarWinds-style attacks.

Watch now

Need some help?

Send us your questions or feedback.

Friendly folks are standing by!

Contact Us
Award-winning solutions Award-winning solutions

Eight-time winner of the Microsoft Partner of the Year Award for Identity Management, Enterprise Mobility, and Security and Compliance.

ThirdSpace Please upgrade your browser

You are seeing this because you are using a browser that is not supported. The ThirdSpace website is built using modern technology and standards. We recommend upgrading your browser with one of the following to properly view our website:

Windows Mac

Please note that this is not an exhaustive list of browsers. We also do not intend to recommend a particular manufacturer's browser over another's; only to suggest upgrading to a browser version that is compliant with current standards to give you the best and most secure browsing experience.