One Exploit to Rule them All? On the Security of Drop-in Replacement and Counterfeit Microcontrollers

/images/one-exploit-to-rule-them-all/devices.jpg

After Exception(al) Failure, we bought a bunch of drop-in replacement chips for the STM32F1 series and analyzed them with respect to their firmware security features. We found lots of severe vulnerabilities and even encountered counterfeited devices. The results of this research will be published in form of a scientific paper at the 14th USENIX Workshop on Offensive Technologies on 11 August 2020. The work is a joint collaboration of Johannes Obermaier, Marc Schink and Kosma Moczek.

We will not publish the paper in advance to the conference in order to adhere the deadline of the coordinated disclosure process. However, here is a short teaser to bridge the time gap until the publication:

With the increasing complexity of embedded systems, the firmware has become a valuable asset. At the same time, pressure for cost reductions in hardware is imminent. These two aspects are united at the heart of the device, i.e., the microcontroller. It runs and protects its firmware, but simultaneously has to prevail against cheaper alternatives. For the very popular STM32F1 microcontroller series, this has caused the emergence of many competitors in the last few years who offer drop-in replacements or even sell counterfeit devices at a fraction of the original price. Thus, the question emerges whether the replacements are silicon-level clones and, if not, whether they provide better, equal, or less security. In this paper, we analyze a total of six devices by four manufacturers, including the original device, in depth. Via a low-level analysis, we identify all of them as being individually developed devices. We further put the focus on debug and hardware security, discovering several novel vulnerabilities in all devices, causing the exposure of the entire firmware. All of the presented vulnerabilities, including invasive ones, are on a Do it Yourself (DiY) level without the demand for a sophisticated lab – thereby underlining the urgency for hardware fixes. To facilitate further research, reproduction, and testing of other devices, we provide a comprehensive description of all vulnerabilities in this paper and code for proofs-of-concepts online.

More information will be published here soon – stay tuned!

Update (08/11/2020): The paper and supplementary material are now available.

Exception(al) Failure - Breaking the STM32F1 Read-Out Protection

The firmware of microcontrollers usually contains valuable data such as intellectual property and, in some cases, even cryptographic material. In order to protect the confidentiality of these assets, most microcontrollers feature some kind of firmware read-out protection. This security feature shall prevent adversaries with physical access to a device from reading out the internal flash memory. Nevertheless, security researchers as well as hobbyists showed repeatedly that these security features can be circumvented. In this research article, we examine the flash read-out protection (RDP) of the STM32F1 series from STMicroelectronics. We discuss a novelly discovered vulnerability whose exploitation would be the first non-invasive way to circumvent the feature. The issue results from an insufficient access restriction: flash data reads via the debug interface are blocked but the CPU's exception handling process is still able to read from flash memory via the ICode bus. We explain in detail why and how this vulnerability exposes major parts of the internal memory, thereby affecting device security.

Read more…

Coming soon: Breaking the STM32F1 Read-Out Protection

We identified a vulnerability in the read-out protection (RDP) mechanism of the STM32F1 series from STMicroelectronics. CVE-2020-8004 has been assigned to this issue.

An attacker with access to the debug interface can exploit this vulnerability and extract large amount of data from the flash memory. If you rely on this security feature, we highly recommend you to take appropriate action. The only way to avoid exploitation and thus keep the entire flash memory content confidential is to physically prevent an attacker from gaining access to the debug interface.

This announcement is part of a coordinated vulnerability disclosure process. An extensive article with technical details about the vulnerability will be published here on the 15 March 2020.

Contact: Marc Schink, Johannes Obermaier