Regardless of how Piriform was breached, for a tool as widely downloaded as CCleaner, with a userbase running into the hundreds of millions, there will be a large impact worldwide, even though only the 32-bit version was affected.
Before you start reading: if you think we are going to misuse the CCleaner incident in this article to ESET’s advantage, you will be disappointed. Yes, the incident that is currently widely publicized is used, but only as an illustration to some deeper understanding and considerations to understand the problem and potential prevention.
There are many possibilities for how Piriform could have been exposed that resulted in malicious versions of CCleaner (version 5.33.6162) and CCleaner Cloud (version 1.07.3191) being distributed from their servers. Of course, everything is speculation until the actual reason is determined or disclosed. This article discusses a few of the possible scenarios that could have led to this worldwide security incident.
Any of the following are security lapses that could have occurred to cause this incident (in no particular order):
- A disgruntled employee: after Avast acquired Piriform, perhaps someone didn’t feel appreciated, someone had to leave or someone didn’t like working for Avast and put in a backdoor.
- An outside hacker. An external hack would make this another supply chain attack, as with E.Doc and the distribution of DiskCoder.C.
- A compromised ISP or proxy redirecting a download from the real download site via an HTTP redirect to a temporary location with the trojanized version, similar to the recently discovered new FinFisher campaign. This is less likely as the trojanized version was digitally signed; thus is would involve an additional breach.
There can be many more (unlikely) scenarios, even those we didn’t even think of yet.
“Why only the 32-bit versions were trojanized remains, for now, a mystery.
Regardless of how Piriform was breached, for a tool as widely downloaded as CCleaner, with a userbase running into the hundreds of millions, there will be a large impact worldwide, even though only the 32-bit version was affected. This is weird, as the effect would have been significantly more dramatic if also the 64-bit version had also been backdoored. Why only the 32-bit versions were trojanized remains, for now, a mystery.
Was it only this version the cybercriminal(s) could get digitally signed? Perhaps in the (near) future, the company concerned will discover and publish the ins and outs of this for all to learn and to see if such an attack could have worked in your company as well.
The latter is important, because attacks such as these – so called supply chain attacks – are still rare, but on the rise. It could happen to anyone, so we’d better learn from the existing examples of how it was done, to build better protection against these kinds of attacks. Depending on the popularity of the software being targeted, the impact can be significant. While M.E.Doc’s compromised accounting software wasn’t spread that widely compared to CCleaner, the impact of that payload (DiskCoder.C) in affected corporates was significant. The final impact of the trojanized CCleaner still is unknown as the C&C server had already been shut down. So how many machines were affected is unknown.
When we look at the telemetry ESET collected from its participating customers, we see detections of this trojanized version of CCleaner totaling 338,000 detections, with the top 10:
- The Netherlands
Again this applies to the 32-bit version whereas the majority of users nowadays run 64-bit systems. But given that these countries are rather large and when we assume a normal worldwide distribution of the CCleaner application, it means that every country has approximately the same percentage of people affected. This is worrisome because it demonstrates how popular software that is compromised can have a worldwide impact.
Luckily, we have a diverse ecosystem in security, but think about what could happen if we had a monolithic ecosystem with just a single security vendor? Anyone making a trojanized version of a popular application would only have to bypass that single security product.
For one reason or another, people feel the need to “clean up” their registry, although it rarely results in improved performance. Microsoft does not recommend or even support the use of registry cleaners. An important reason for Microsoft to discourage registry cleaners is that such utilities can actually cause a negative impact on the system:
“A damaged Windows registry can exhibit a range of symptoms including excessive CPU utilization, longer startup and shutdown times, poor application functionality or random crashes or hangs. These random crashes and hangs can ultimately lead to data loss due to the systems inability to save data back to the storage location during the occurrence.
Even more interestingly, the article also says:
“Some programs available for free on the internet might contain spyware, adware, or viruses.
This incident should serve as a reminder that really there is no such thing as free software: whenever it doesn’t cost you any money, you and your data could be the value. If you want to learn more on free software issues, please read Tony Anscombe’s article “What’s the cost of a free lunch?”
The underlying danger of this statement, however, is that it is undermining the importance and trust in (free) software, something outlined in the recent Electronic Frontier Foundation (EFF) article “Attack on CCleaner Highlights the Importance of Securing Downloads and Maintaining User Trust”
Please keep faith with your software, free or otherwise, and the companies producing it, and make sure you keep it up to date. Yes, the risk of a supply chain attack is always there, perhaps even a growing risk, but not keeping the software up to date significantly increases the risk.
For developers of software, including ESET, it is (another) wake-up call to keep our protocols secure to prevent supply chain attacks, to verify each step, making sure the right software is digitally signed and made available to the user.
The security industry has been (rightfully) preaching about adding security layers using techniques such as 2FA (2 Factor Authentication), but of course the industry itself should safeguard supply lines, distribution lines and internal systems. 2PA (2 People Authentication), similar to the Two-Man rule, would be a good start!