With the pressure to ship as early as possible, especially when it comes to hardware, what assurances do we have that the hardware is really clean, and that future updates won’t be hacked? Here at Virus Bulletin 2018, the conversation of how to keep the whole supply chain clean end-to-end and for the lifecycle of the device, is top of mind.
Ten years ago, hardware situated on the network was relatively simplistic, but not anymore. Even tiny IoT machines that may have a full operating system and network stack (now a commodity), often have the potential to contain broken or compromised code, and yet are positioned in trusted networks doing things like quietly watching an exit door in your building for bad guys. While these devices are out of mind for you, they’re not for scammers.
In traditional operating system software, linking to libraries that may be updated over time is a common functionality. Often, in the world of embedded devices, this is a nice way to have something of a future-proof build. If issues are discovered later, the updated libraries, or external resources, can be used to remediate them, hopefully without breaking the core functionality of the software.
But if the libraries targeted by that linking get modified, now or in the future, the software can execute it and (potentially) enable all kinds of rogue functionality.
It is common these days for a software vendor to provide a stub piece of software that gets installed, then calls a series of external resources, often as a successive chain of imported software, sometimes originating with third parties. But that can create similar problems if any link in that software delivery chain becomes compromised.
From a detection standpoint, it’s tough to declare the core piece of software clean, when it may eventually lead to an exploit buried in something it imports in the future.
Some software is very simple, and just quietly “lies in wait”, then wakes up in response to a remote command and launches malicious code. What if such a program is baked into a chipset, in much the same way as has been alleged in a breaking story from Bloomberg? (However, the story has been strongly denied by a number of the companies mentioned in the article.)
Often such samples can reside in software or hardware and be simple scripts, which are very difficult to detect, since they’re just a quiet listener, and don’t themselves do anything overtly malicious.
Then there’s old code on firmware that’s been declared end-of-life by the vendor, but still runs in thousands or millions of instances, like home routers. These machines typically have far less sophistication, security-wise, than current implementations, but still have access to trusted networks and can be zombified with rogue code and then used as a jumping off point for reconnaissance or other exploits. Code that’s quietly been retired from active development (unbeknownst to the customer), can provide quite an entry point into trusted environments.
Some more modern implementations have auto-update functionality, but then if they just “magically update” without user interaction, they can automatically pull vulnerabilities or exploits onto a device, and begin quietly exfiltrating sensitive data.
For rogue software makers, it is increasingly important to steal the certificates used to establish trust with other hardware or software, so researchers keep an eye on rogue certificate trends as an indicator of foul play.
But how tough is this to spot?
I was in a networking user group which debated whether a sharp operator could catch an exfiltration attempt using a standard, but well-configured, toolset and techniques. While a mass dump of documents in the middle of the night would raise a flag, a quiet exfiltration of a few text strings at some very low data rate would be very difficult to catch, especially on a large network.
Catching everything is tough, and as the network volume increases year-over-year, catching the “needle in a haystack” of credentials or tiny code represents a daunting challenge.
Luckily, here at Virus Bulletin there is a shared inclination towards putting together tools and techniques to address issues around compromised supply chains, including the collaboration of other security folks, the release of suitable free or widely available tools, and hallway conversations with researchers about the best techniques.
So while chains of trust used in modern software will still be suspect, padlocking the chain will help to keep the end users safe, and future-proof this swarm of devices everywhere around us.
