The announcement Tuesday from the NSA about the new cryptographic vulnerability in the Microsoft Windows operating system sent ripples of shock through our entire community. In case you missed it, this devastating vulnerability (CVE-2020-0601) allows attackers to bypass trust mechanisms to falsify certificates, making them appear to come from a trusted source. It also allows attackers to falsely authenticate themselves on vulnerable HTTPS connections and remotely execute code. Let’s hope everyone is on top of their Microsoft security patches or there could be some serious damage done.
This week’s warning isn’t the usual story of forged certificates or somebody using stolen keys. We all remember Stuxnet (read more on that here), but that exploit required the attackers to penetrate and then steal the code signing keys from two trusted software manufacturers. The theft was non-trivial and the stolen keys were only dangerous while the theft remained undiscovered. Once the world learned about the theft, any certificate created from the stolen keys could be revoked and rendered useless. In other words, the Stuxnet code signing problem was serious but the fix was simple.
But what happens to trust when you can’t trust the trust system? With this latest vulnerability, we’re talking about the very underpinnings of digital signing and software validation for any software running on any current Windows-based platform. And while the vulnerability doesn’t impact the actual controllers on the plant floor, I’m willing to bet that 99.9% of today’s industrial systems are running the Windows operating system for all the operator HMIs, engineering stations and historians and management servers. In other words, while this vulnerability doesn’t impact the actual PLCs, it will allow counterfeit and malicious software to sneak onto all the computers that communicate with, manage, or report on industrial processes.
This isn’t the first time that the limitations of code signing have been laid bare. In 2017, researchers at the University of Maryland showed that there are currently over a million malware files in the wild that are signed. These are signed by bad guys as a means of fooling poorly-written antivirus software into thinking the malware is legitimate software and skipping over it.
So, as I point out frequently at conferences, code signing and digital certificates are necessary but not sufficient to ensure software is tamper-free and legitimate. This is especially true in critical infrastructures, where the use of code-signing is limited* and multiple validation mechanisms are necessary to keep our industrial processes reliable and our people safe.
This all ties back to why, over a half-decade ago, I became interested in alternative methods of validating software. My current project, the Framework for Analysis and Coordinated Trust (FACT), provides a collection of validation checks for vulnerabilities, malware, subcomponent analysis, and does a deep-dive into a file’s full certificate chain. Then after thorough scrutiny, the platform provides a “FACT trust score” that technicians and managers can use to be confident in the decision to install a package (or the decision not to).
Certainly, any single test that FACT performs could be misled by a vulnerability like this latest one. However, by combining multiple tests and enabling the community to share intelligence, we stand a much better chance of outing rogue packages, counterfeits, and deprecated versions.
The ICS world needs ways it can trust software and firmware that cannot be signed (e.g. controller binaries) and confirming the validity of files that are signed, but with invalid certificates. I hope you’ll join the FACT community and help make ICS safer and more secure.
If you want to learn more, check out a quick video on how FACT handles Code Signing Validation.
If you want to kick the tires for yourself, try the FACT platform for free.
* For most embedded devices in the industrial world, code signing isn’t even an option. The operating systems found in most industrial devices don’t have the ability to validate certificates. ICS vendors are making progress in having the newest controllers offer validation features, but it will be many years before we can expect code-signing to be broadly deployed in ICS.