I generally don't like writing about current events, because the inherent ephemeral nature of the news means that your words become less meaningful with each passing day. As a professional, I find wasting other people's time in poor taste.
However, the topic of supply chain attacks has come up repeatedly in the recent months, so I'd like to take a moment to reflect on these incidents, as well as the work I've done through Paragon Initiative Enterprises (PIE for short) to be able to solve this problem at scale.
In general, a supply chain attack involves first hacking a trusted third party who provides a product or service to your target, and then using your newly acquired, privileged position to compromise your intended target.
More narrowly, we're only interested in supply chain attacks which involve compromising the companies that produce software used by other companies. Hardware based supply chain attacks have been demonstrated by leaked documents concerning nation state actors.
Rather than rehash the long history of supply-chain attacks (both theoretical and actual) and the motivation for virtually every Linux distro to PGP-sign their update information, let's just look at what's happened in the year 2017.
The industry's first wake-up call in recent months was a ransomware called NotPetya that was spread throughout Ukraine through the auto-update mechanism for M.E.Doc, one of the few government-approved accounting softwares.
Last month, Kaspersky Lab's research teams published a write-up about a malware campaign called ShadowPad, which infected a software update for an unspecified product by a company called NetSarang. The product in question is reportedly used by hundreds of large firms, especially in the energy sector, so the long-term impact of such an infection (if undetected) is best left to the imagination.
Most recently, but certainly not finally, we learned that the most recent updates for a common Windows utility called CCleaner had also been infected with malware.
In each of these recent cases, malicious actors had compromised a software company and infected the "legitimate" copy of the software that users would download and install.
In some of these cases, an automatic update mechanism was used to deliver the payloads. However, it is erroneous to call out auto-update features as the reason for infection. If a malicious and signed binary was uploaded to a company website, the fact that updates have to be performed manually would not have helped the victims. They would just happily install it, none the wiser.
In all of these cases, the malicious software update was spread to everyone who installed it, rather than a targeted attack against only networks of interest. I'd wager that there are some of these going on in the wild as I type this, but they're inherently much more difficult to detect.
The real security problem here has very little to do with automation.
The reason that supply chain attacks are viable, effective, and often difficult to detect is that very little (if any) industry attention is given towards guaranteeing Software Authenticity.
This is a topic we have covered extensively:
- Quick and dirty guide to secure automatic updates (August 2017)
- A technical tutorial on the ins and outs of automatic update implementations for PHP developers (October 2016)
- A detailed write-up of the implementation in our Free Software content management system, CMS Airship (May 2016)
- Our very first blog post introduced Asgard, our first attempt to solve this problem for the PHP community (April 2015)
If you read only one of the above links, read the one from August 2017.
Our company has done a lot of work in between client engagements to make it easier for developers to make their software updates signed, auditable, and reproducible. This does several things:
- Signed: If the signing key is kept offline, even if the webserver or update server is compromised, the malware will not be accepted by the end user's computer. This is a nontrivial impediment to supply chain attacks, provided the company in question has adequate discipline to keep their signing key secret.
- Auditable: Even with a pilfered signing key, with this guarantee in place, attacks will be unavoidably detectable due to each update being committed to an append-only data structure (e.g. a Merkle tree or hash chain). This also ensures that everyone gets the same update and prevents targeted attacks (which, as mentioned above, haven't yet been detected, but cannot be ruled out).
- Reproducible: With open source software and reproducible builds, users can verify that the binary they received corresponds to the expected version of the software they intended to install. Combined with the auditability guarantee, if even one power user or security expert inspects the source code for backdoors, that's sufficient to ensure that all other copies of the same update are authentic.
If all three guarantees are provided, it's even generally safer to deploy your updates automatically (by default; power users should be allowed to disable this mechanism).
Furthermore, because of these guarantees, most attackers will be dis-incentivized to even attempt such an attack: The success of their campaign hinges on their ability to steal a cryptography key, they can't target networks or persons of interest, the likelihood of being caught very early is extraordinarily high.
If we can make all software updates come with authenticity guarantees, I believe we will all-but-eliminate supply chain attacks in the real world.
We've consistently focused on the problem of ensuring software updates are secure enough to automate since our company's inception.
We strongly believe that solving this problem at scale will have a more profound impact on the security of the Internet than almost any other problem in all of information security and applied cryptography.
If you're looking for a killer app cybersecurity solution to these sort of attacks, the answer involves a lot of inglorious janitorial work cleaning up the software ecosystem and assisting open source software projects to get on board with scalable and trustworthy solutions.
This is not a problem that necessarily needs a blockchain to solve.
It's not a problem that traditional endpoint security (read: anti-virus software) is even in the correct genre to a solution.
No, we're going to need to solve this as a community, not an industry. That means a lot of dedicated security experts and developers working together. That means a lot of short-term developer hours expended to improve the long-term health of your companies.
I fully anticipate that charlatans and snake-oil salesmen will come out of the woodwork to pitch their poorly thought-out solutions to supply chain attacks as increasing number of computer criminals find them to be an effective way to infect victims. Even more hours will likely be expended on debunking their fraudulent claims and alerting the uninformed of their deception.
But in the end? If we, as a community—as a society—can work together to solve the problem of secure software updates for the Internet at large? It will all be worth it.
This was originally published on the PIE blog