This is the nightmare scenario for all software developers - malware somehow being inserted into the development or update stream at source. Not only does the developer handle the distribution, they even sign it for you!
The potential for this attack has been widely known for many years, although some in the security industry seemed to assume rather naively that it was something which should only concern the Open Source community, with a contributor to the project inserting the code unnoticed. But in reality all reputable developers, regardless of their size, should be having sleepless nights about this happening and, if they value their business at all, taking every precaution imaginable to prevent it. Yet there was anecdotal evidence that many were wilfully oblivious to the dangers.
Just consider the damage that could be done if this signed malware-laced executable was not the latest version of some utility software downloadable on demand from a web site, but instead had been inserted undetected into the automatic update system of say Windows (or Mac OS, or a popular Linux repository - all are equally targetable). Or maybe some popular anti-virus software, which conveniently for malware developer has not only already got Administrator/Root priviliges, but has gone one step further and already taken over or deliberately broken most of the security features built into the operating system. The damage could be apocalyptic!
The fact that the CCleaner installer released by Piriform was signed proves that it was their fault - they can’t claim some script kiddie hacked their web site (not that that is ever an excuse). Either the malware was inserted in-house and somehow evaded detection their final checks before signing & release. Or their private signing key has been stolen without their knowledge, and someone was then able to insert the modified installer back into the end of their system for release & distribution.
The target of exfiltration intellectual property, and apparent sophistication of the payload & its concealment, suggests this came from a well organised & funded source - possibly a competitor, but more likely a governmental department of a nation state. (Friend or foe? ) The range of companies it was targeting indicates it was a catch-what-you-can fishing expedition, which fits the long-established modus operandi of the usual suspects - especially China, an old hand at the IP theft game. But there are other countries (even apparently friendly ones) who would like to give their domestic IT industry a helping hand. Or use the information obtained to develop the tools for further attacks. As the products of these companies are so ubiquitous, such information would be priceless for attacking just about any target anywhere in the world - large or small, governmental or private.
Either way this is a massive failure by Piriform, regardless of who the attacker was. I wonder what their investigation will find? Were they making the one or more of the obvious, completely unforgivable blunders? Such as the custodian of their key routinely just signing the code presented to them without first verifying it with those upstream. Or in the latter scenario, allowing a file (especially an executable) to be uploaded to their public web server for distribution without confirming that its checksum matched that of the file previously signed & authorised for distribution.
Regardless of how careful (or careless) Piriform have been, we can be sure that there most certainly are developers out there who neglect to take even the most basic precautions to ensure that the code they release is what they intended and has not been interfered with - and they’re not just the small one-man shareware operations. These days there is absolutely no excuse for the likes of Dell to still be releasing unsigned binaries & executables, especially firmware updates for high-end business/enterprise products.
As for the ordinary end user, installing or executing unsigned code is a start. Even signed code must be treated with suspicion - don’t just check who signed it, but also consider how much you trust the owner of the signing key. You are in effect delegating the security of your system every time you install or execute the code signed with their key. Are their systems & procedures secure? The lesson here is that the signature only proves that it was signed with their key, not who actually signed it or if they knew what they were signing. And that even reputable names cannot be trusted blindly. Believe nothing, suspect everybody. Or…
Drink up, the world’s about to end.