Smash-and-Grasp Blackmail

Jul 10, 2024The Hacker NewsIoT Protection / Firmware Protection

The Issue

The “2024 Confrontation Understanding Report” from the workforce at Rapid7 [1] is a well-analyzed, well-crafted report that deserves thorough examination. Some noteworthy findings include:

1. 53% of the over 30 fresh vulnerabilities that were extensively exploited in 2023 and at the onset of 2024 were zero-days.
2. Greater mass breach occurrences came from zero-day vulnerabilities rather than from n-day vulnerabilities.
3. Nearly a quarter of prevailing attacks were zero-day assaults where an individual foe compromised dozens to hundreds of organizations simultaneously.
4. Miscreants are shifting from preliminary entry to exploitation in minutes or hours rather than days or weeks.

Hence the traditional mend and establish tactic is as effective as a firetruck arriving after a structure has been charred to ashes! Naturally, mending and establishing could avert future attacks, but considering that mend development takes from days to weeks [2] and that the usual time to implement crucial mends is 16 days [3], devices remain vulnerable for an extensive period after the zero-day has been disclosed publicly. This enables smaller entities to obtain their part of the bounty, much like the scavengers they are. In light of Rapid7’s report, a distinct approach must be taken to safeguard IoT and other susceptible devices.

The Production of Firmware

“Software Inventories for IoT and OT devices” by IoTSF is another outstanding read. I was amazed to discover that “Advanced software is rarely built from scratch but rather it merges a relatively minimal amount of new code with tens, hundreds, or even thousands of pre-existing constituents …”. In times gone by (around 2015) we fabricated our own firmware, but not anymore. Currently, as per the authors, IoT firmware is composed mostly of open source constituents that are brimming with vulnerabilities. This is not a stride ahead for device security!

According to the IoTSF authors, constituents introduce more constituents, each with more vulnerabilities. Furthermore, they mention that creating precise SBOMs is challenging, and identifying all vulnerabilities in an SBOM is even more challenging. Consequently, security teams are presented with inadequate SBOMs and the duty of deciding which vulnerabilities are exploitable, then rectifying those vulnerabilities. According to other reports, the quantity of vulnerabilities and the intricacy of IoT firmware are escalating swiftly year by year. Staying abreast of patches seems to be a futile treadmill. It’s no surprise that security teams are experiencing burnout.

Frightening Exploitations

Zero-days are especially troubling because many government actors possess inventories of them that are prepared to be utilized as arms [4]. We usually think of exploitations as data extractions or ransomware assaults. Nevertheless, these do not encompass the entire account. In 2007, at Idaho National Lab, it was resolved to test if malware could impair a full-scale electricity generator [5]. The malware managed a relay that connected or disconnected the generator from the electricity grid. By executing a sequence of connections and disconnections, the malware was capable of causing the generator to obliterate itself.

The outcome was not repairable damage, but essentially scrap metal that could merely be melted down to create a new generator. The generator was annihilated in less than a minute. Thus malware operating on a minute MCU was able to devastate a substantial machine. What if a malevolent actor could devastate 10% of the electricity generators in the U.S.? How long would it take to manufacture and install replacement generators? What would occur during that interim?

We Require a Superior Resolution

We must acknowledge that patching and establishing are inadequate to cope with emerging new threats and the militarized threats elaborated above.

Isolating vulnerable firmware is the superior resolution. This is amply demonstrated by Green Hills’s Integrity for aerospace, BlackBerry’s QNX for automotive, and several “separation kernels” by other companies. Nonetheless, the predicament with these resolutions is that they necessitate power-intensive processors, and isolation occurs at the process level using memory management units (MMUs). IoT devices usually necessitate low-power microcontrollers (MCUs), their firmware generally consists of but a sole process and they are restricted to memory protection units (MPUs). What is required is more precise isolation (i.e. at the task level) that functions for MCUs.

We Possess Such a Resolution

We have proved that isolated partitioning is practical for Cortex-M based MCUs (which constitute about 80% of all MCUs in production). Moreover, the pmode barrier provided by this architecture furnishes additional protection for mission-critical and other trusted code. Such code necessitates only minimal alteration for partitioning. The subsequent figure illustrates the essentials of Cortex-M partitioning and how it aligns with the comprehensive security landscape:

As indicated, mission-critical firmware, security firmware, and handler mode (hmode) firmware are shielded by the pmode barrier and function in privileged mode (pmode) or hmode. Vulnerable application firmware, SOUP, and middleware are situated atop the pmode barrier and run in unprivileged mode (umode). Firmware in umode can only access pmode or hmode through exceptions triggered by faults or via the SVC exception, which is utilized for system service calls. The pmode barrier is enforced by hardware and thus it is impregnable from umode.

As demonstrated in the illustration, umode firmware is segregated into isolated partitions. If a hacker breaches one umode partition, they cannot reach data or code in other partitions. Communication between partitions is carried out via portals, which preserve isolation. Consequently, a hacker may deactivate the functionality of one umode partition, but not others. Moreover, pmode and umode code are doubly safeguarded by the pmode barrier. Hence the device manages to continue executing its primary functions and most secondary functions during an assault. Throughout an assault, the breached partition can be halted, the malware removed, and the partition restarted to restore normal operation.

It should be highlighted that isolated partitioning is as effective against zero-days as it is against unpatched vulnerabilities. The method of the attacker’s entry into the partition is irrelevant; they are confined. Furthermore, partitioning allows siloing, which can alleviate insider threats (another expanding attack avenue), and furnishes hardware enforcement of specific sound programming practices, which could lead to more expedited deliveries!

For those intrigued, we have showcased demonstrations and an e-book at www.smxrtos.com/securesmx. May the righteous emerge victorious!