On the face of it, Avast is in a bit of a pickle. One of its headline applications, CCleaner, has just infected over two million consumer PCs across the globe with quite a sophisticated piece of malware. How it as a company handles the cleanup process is going to be quite telling.  

First, a little bit of a timeline is in order here, as CCleaner has not actually been an Avast product that long.  “What,” you say? “I was installing it on my PC years ago!” This is true, but at that time, it was owned by a company called Piriform. In fact, Avast has only owned Piriform, and by default CCleaner, since July 18, 2017. The infected version of the product, although released under its watch, would have been written and prepared for delivery well before the purchase went though.

The worrying part of this compromise is that the infected code was hidden in the binaries of a commercial (albeit free) product. Even more worrying is that this binary was signed by a trusted certificate issued to Piriform by Symantec.

From a damage limitation perspective, Avast has, in my opinion, done a good job so far. The post on its site outlining the issue and its timeline for remediation are open and frank. It is to be applauded for this.

Now, Avast has intimated in its post that the original compromise was undertaken whilst Piriform was still an independent company. This is evidenced by the time stamp on the infected code’s SSL certification stating July 3, 2017. Further, on its first notification of the infection (four weeks after the original release date by Morphisec), it pulled the affected version, fast-tracked the next release to close the exploit, and together with law enforcement agencies forced the shutdown of the CnC server; further, Talos registered all the secondary DGA domains, effectively pulling the rug out from under the exploit.

What worries me is the apparent ease with which this code was released into the wild. Think a minute about the complexity of this attack. The attack:

  • Compromised Piriform
  • Compromised the development environment
  • Inserted new code into the product with the payload (remember, the payload also included a new DLL)
  • Got that code through the QA process
  • Sealed it in a verified Setup executable

What I find is difficult to believe is that such a large change was not picked up at some point in the development cycle. I am loath to say this, but it points towards an inside job, perhaps somebody disgruntled with the Avast acquisition, considering the timeline. If this is the case, how would Avast move to:

  • Understand where the compromise happened?
  • Alter process to make sure it does not happen again?
  • Find the culprits?

More to the point, what exactly could it do if it did find out it was an inside job?

The important thing here is to understand intent. There is no doubt that this issue is unlawful, but what exactly is the offense committed? Now, this is where things get murky and grey. It may surprise you to know that there is no law against creating a virus, trojan, worm, or any other attack. The law as it currently stands is codified in the US under 18 USC 1039, which makes it a federal crime to knowingly access a protected computer without authorisation. This is also the case in the UK under the Computer Misuse Act of 1990. If this was an inside job, then criminal prosecution would be difficult, as the perpetrators would have had authorised access to those machines.

This will, then, leave civil sanctions or employment disciplinary actions. Avast could possibly pursue damages for loss of reputation against the writers of the code, but it is more likely that if this was an inside job, then the management at Avast would simply fire the offending personnel under a gross misconduct charge and refuse them a reference. Personally, I believe that this has either already happened or that those who did it have moved on.

Avast will want this to just go away. It does not want any further bad press on this matter and will want to draw a line under it. As such, it likely will not pursue the perpetrators if they are internal. Even if the attack was external and even though the access was unauthorised, the damage to anything other than reputation was minimal. To pursue them would keep the issue fresh in people’s minds and could potentially cause even more reputational damage to Avast then the original compromise.