Recently there has been a rash of software supply-chain attacks. Compared to malware, where we tend to talk about hundreds of thousands of events per day, having only eight reported software supply-chain attacks since January might not seem like a lot.

In fact, it may have you thinking I'm overstating things. However, when you consider that we often only see one or two software supply-chain attacks in a year, eight in the last ten months is a veritable deluge!

The two most-publicised among these are the recent CCleaner incident and the M.E.Doc attack. In the former, an illicitly-modified copy of the very popular “system cleaner” CCleaner, including signed executables in signed installer packages was available from the official download site for a month. Subsequent forensic analysis of the C-C server at the heart of the attack showed that at least 40 machines at 12 companies were compromised further.

Popular Ukrainian tax accounting software M.E.Doc was backdoored multiple times with the modified versions made available from the official download servers, and mostly installed on victim machines via the software's auto-update feature. On 27 June, a few days after the third backdoored version of the software was released, the DiskCoder.C (aka NotPetya) data-trashing malware was pushed to M.E.Doc's compromised users. Although probably unintentional, DiskCoder.C spread widely outside of Ukraine, via stolen credentials and VPN LAN connections.

Why would the attackers – whoever they are – behind the CCleaner compromise, or the others, go to this much trouble?

In one case the “attackers” are known and might reasonably be described as researchers or “concerned users” wishing to improve the state of security in popular programming language ecosystems. However, in the other cases, including those listed above, all of which involve actual malware, it is unlikely we will know for sure unless the attackers are caught and carefully interrogated. However, we can speculate.

A supply-chain attack, at least involving specialist software, is logically a form of watering-hole attack. These are so-named because the attackers focus their attention on a conventional “gathering place” for people in a community of shared interests, where the whole group, or perhaps just a few of its members, are the attackers' actual target. Typical watering-hole attacks have involved compromising a legitimate website and installing malware on the devices of the site's visitors via a drive-by download, or by social engineering (“you must update Flash Player,” or “you must install this codec to view this video”).

Compromising a software distribution server, or the build-chain that delivers a software update to such a server, has significant advantages for the attackers. They do not need a good supply of zero-day vulnerabilities with which to pull off a drive-by compromise, nor do they have to be able to socially-engineer their intended victims into installing an “update” that is really malware.

Furthermore, it is entirely unsurprising to the victims that some software is installed on their devices, as that is what they were expecting, either directly through their own actions, or indirectly if the software checks for and installs its own updates. The latter is especially favourable, as it gives the attacker a “least surprise” advantage. Their victims are very unlikely be doubtful after installing the software, allowing the malware more time to achieve its intended goal.

Perhaps this dramatic, recent increase in supply-chain attacks suggests that other attack methods are getting harder to pull off? If so, it is likely that this is because endpoint security software, firewalls and other security measures are more difficult to bypass? Or, it might just show that well-funded – and perhaps predominantly state-sponsored – cybercriminals are even more active and determined than ever?

Most modern software systems are far too massive for any individual to fully understand. Modern office suites, database programs, system maintenance utilities and, yes, security products, are huge, and have hugely-complex codebases. The teams who write these programs have to trust others who produce the development tools that they need to build and ship their own products, and of course, the operating systems that they run on.

When you think about it, there is actually a circle of trust, as the developers of these tools are also users of office suites, databases, system maintenance utilities, security products and operating systems.

We are, you could say, all in the same boat…