Security Think Tank: Attackers leveraging the supply chain

One of the biggest and most publicised cyber attacks of the past 12 months was against SolarWinds, where hackers placed a backdoor into a software update to its Orion product.

Supply chain attacks on software suppliers often aim to exploit companies higher up in the supply chain and are nothing new – one of the earliest I remember was an attack on a company developing website design software.

In that instance, attackers planted malware in the website design code so that it created a backdoor in every website built using that code. Those websites could then be weaponised to download malware to users browsing the sites.

This approach leverages the original attack on one organisation to successfully compromise their customers as well as their customers’ customers, in turn.

Aspects of the SolarWinds attack give rise to several lessons about how we must protect software development environments, how we assess our suppliers and how we manage and monitor some of the software products we use, particularly as a service provider.

SolarWinds Orion was a particularly good target, as it is a network management product and therefore has access to anything that is manageable over a network.

Orion is widely used by governments and enterprises, including those providing network management services to other organisations. It was this leverage that gave the attackers access to at least 18,000 companies, as well as possibly many more that are still unaware of the compromise. It should be noted however that a much smaller number of companies were actually exploited. SolarWinds announced the actual number of customers who were hacked through Sunburst to be fewer than 100.

These involve large tech, security companies and government departments, including the Pentagon. However, this attack on SolarWinds had no impact on their systems and so went undetected for a very long time.

The original attack on the SolarWinds development environment was one of the most sophisticated to date. Not only did the attackers modify sealed software, but they also used domain names to select specific targets and replicate the Orion communications to remain undetected. Once the job was done, they also removed all traces of the attack to hinder attribution.

The SolarWinds development environment was not insecure and there were several security checks in place to ensure that alterations to source code could be detected before compilation. The final code was digitally signed as part of the compilation process, ensuring that changes to the compiled code could be detected. The approach used by the attackers therefore interfered with the compilation process itself to switch in the malicious code during the compilation process. No source code was modified and no signatures were forged.

It is very important that the final executable code is exactly what was tested, not just for security reasons, but also from a quality point of view. However, the SolarWinds attack shows that existing checks are not enough.

While it is good practice to have a build environment separate from the development environment, the first one now clearly needs to be locked down with minimal external access – and the integrity of the whole environment (software and build scripts used in compilation, etc) must be monitored and checked before the final code is compiled.

You could also consider executing the final compiled code in a sandbox to try to detect any unexpected behaviours before releasing it. In extreme circumstances, the build environment could even be rebuilt from a “golden image” each time it is used – although this may be impractical in some cases.

From a user viewpoint, we have in the past tended to trust software from reputable suppliers and given it full access to whatever it needs to do its job, which could mean devices in client networks.

So, we now need to start from an assumption that applications may be compromised. This means enhancing supply chain security in order to ensure software suppliers have appropriate cyber protection in the light of this attack, together with reviewing and updating the protection and monitoring of systems to increase protection against software compromised through supply chain attacks, as well as earlier detection of any compromise.

Although the SolarWinds attack was very sophisticated, it demonstrates to other malicious actors what is possible and we can consequently expect to see more of the same. Therefore, we must learn from this and upgrade our protection of software development and build environments, encourage our suppliers to secure their development environments and not assume that the software applications we use every day are free from malware.