Uncovering Vulnerabilities with 'Good Enough' Emulation

Uncovering Vulnerabilities with ‘Good Enough’ Emulation

A Cisco Talos researcher worked around the limitations of hardware-level Code Read-out Protection (RDP) on the Socomec DIRIS M-70 gateway by pivoting from physical debugging to a “good enough” emulation approach. By focusing on emulating only the single thread responsible for Modbus protocol handling rather than the entire system, the author demonstrates how a streamlined emulation strategy can effectively surface vulnerabilities in complex industrial Internet of Things (IoT) devices. 🚀

This research led to the discovery of six CVEs related to denial-of-service vulnerabilities, all of which have been patched by the manufacturer through Cisco’s Coordinated Disclosure Policy. The M-70 gateway is vital for energy management in sectors like critical infrastructure, data centers, healthcare, and the general energy sector. As an industrial Internet-of-Things (IIoT) device, vulnerabilities in the M-70 or similar gateways can lead to severe consequences, including operational disruption, financial losses, and manipulation of industrial processes.

Understanding the System

Understanding the system is critical for root cause analysis. In the case of the M-70 gateway, code read-out protection (RDP) Level 1 is enabled. This is a feature of STM32 microcontrollers providing flash memory protection. Level 1 prevents flash memory reads while debugger access is detected (e.g., JTAG), essentially preventing debugging of the running software. This meant it was not possible to step through the code processing malicious network messages to determine the cause of device disruption. Despite this, an unencrypted firmware update file was available, providing the code that would be written to flash. Additionally, the ability to access SRAM while a debugger is attached is allowed with RDP Level 1 enabled.

Emulation as a Solution

Emulation became a solution to this inability to debug the software natively, allowing visibility into the effects of a malicious message on the M-70’s state. The project focused on vulnerabilities within the Modbus protocol handling code, which ran in a single thread of the M-70 application. Rather than spending the time required for full system emulation, the decision was made to emulate only the Modbus thread. The first step involved utilizing the Unicorn Engine, a powerful CPU emulation framework, to run the Modbus thread’s code in a controlled software environment. Manual inspection was insufficient as the Modbus thread supports over 700 unique message types, making automation necessary. Unicorn’s AFL integration made it simple to fuzz using the emulator, automatically exploring these many execution paths, with AFL using coverage-guided test case generation.

Fuzzing and Debugging

With fuzzing came crashes, necessitating triage and root cause analysis. A tool compatible with the Unicorn framework’s internal CPU representation was required, as GDB did not “just work” with emulated execution. Udbserver, a plugin for the Unicorn engine, enabled debugging of Unicorn emulated code within GDB. Furthermore, observing code coverage visually is an important part of any fuzzing campaign, helping identify unexplored paths and providing insights for root cause analysis. This prompted an investigation into the Qiling framework, a full system emulator supporting debugging and code coverage output. After some modifications, it became feasible to emulate just this single thread rather than the whole system. These code changes have been integrated into the development branch of Qiling on GitHub. This code coverage feature proved highly useful, as comparing data from multiple test inputs facilitated rapid identification of the root causes of the crashes generated by AFL.

To read the complete article see: Read full article