Solar Winds: The Hunter Hunted
TEMPEST OR STORM IN A TEACUP?
The constellation of Orion the Hunter has long been pivotal in human mythology. In particular Orion’s Belt are three stars easily visible to the naked eye. More than one creation myth surrounds it.
We have no idea why the marketing guys at major US enterprise software company Solar Winds chose to name their IT network monitoring application ‘Orion’. The fact is, in early 2020, rather than being ‘the hunter’ it became the hunted when hackers broke into it, surreptitiously adding malicious code that would later cascade into the systems of Solar Winds’ own clients.
The clandestine attack was very clever - even after de-compiling the code it was still concealed within hashes and encryption. It was also highly intelligent - after installation it made every attempt to check if it was running in a sandbox/VM and, after that, it waited for two weeks moving very carefully before attempting to compromise host systems. Smarter still its command-and-control signals all looked like standard SolarWinds activity.
However, this initial code was only just the foot in the door of the compromised network. In order to deploy further, the attackers used a well know vulnerability in the Windows authentication schema to create authorised accounts and then expand out.
The strategy was so well disguised that even FireEye, one of the top intrusion detection systems (IDS) software vendors, did not detect this malware for several weeks. If that’s the case, what hope do mere IT managers have?
The fact is that once a hacker has compromised your network, they tend to use established vulnerabilities to land and expand. On that basis a network needs to be patched for all known vulnerabilities at a similar level to any outside facing servers.
To effect this, properly planned patching windows need to be organised and service users should not be the ones to accept the risk of not patching as the service is “essential” and shutdown is not an option. The business needs to agree that if the service is so important, it must be fully patched and not running at risk.
Cyber security professionals need to fully understand the security processes their third-party suppliers operate with regard to security software development and changes to code within their software release management. It seems fair to assume that in the case of SolarWinds there was insufficient code control. Otherwise, this situation could have never happened.
As it transpired, the creation of new privileged accounts across the network, using established trusts, leveraging some issues inherent within the Microsoft configurations, helped the attackers expand. Privileged accounts must only have the rights they need for their immediate process and, when created, must have an authorisation path linked to real “live” users and linked to service requests. Physical two factor authentication for these approvals and the new privileged account is a good additional control.
For many years the Jericho model (de-perimeterisation) has been discussed. Here we do not rely on ever more complex and colander-like outside boundaries, accepting there may always be vulnerabilities to exploit. In this case every service/server lives in its own domain bubble, where it trusts no one.
The result. Multiple perimeters. Whilst this effectively means a “no trust” route, given strong management it could be advantageous. In conclusion there is no one quick fix to this form of compromise, in which case the only answer is the ever reliable cyber strategy of defence in depth with control mitigations across people, processes and technology.
So often in IT security we see ‘storms in a teacup’ – issues that are high profile but comparatively easily fixed and short lived, albeit preventable and damaging. However, given the subtlety and long-lasting and, in effect yet to be seen, impacts of the Solar Winds attack, the hackers may well have created the perfect storm.