In the Nozomi Networks security research lab, we work daily with a broad variety of embedded devices. Our objectives differ on a case by case basis, but the most common situations are those in which we study a product to understand its protocols in depth or where we want to assess the security posture of a solution.
To achieve these goals, we often need to analyze firmware images and extract specific binaries which represent the final targets of our analysis. This process begins by obtaining an actual image and it might involve dumping the binary directly from the device hardware.
In this blog, we’re focusing on the next step, where given an input binary, an analyst has to figure out the firmware structure and eventually obtain unencrypted executable code, in addition to the configuration files.
The Problem of Firmware Inspection
Many vendors distribute firmware images as they’re produced by the standard build process in place. They typically don’t document details such as the chosen filesystem, or compression algorithms used. However, a researcher with some experience and with the right set of tools can determine these technical details quickly and proceed with the assessment.
In the last few years, we’ve seen a trend of vendors actively obfuscating or encrypting firmware, with the goal of blocking any type of analysis other than a pure black box interaction. In some cases, vendors are even describing these efforts as security driven.
While we understand this line of thought, our experience tells us that for organizations deploying networked devices, the opposite is true. Being able to inspect device firmware allows us to understand its attack surface in depth, through the layers of the software stack.
Since some emerging high-risk vulnerabilities affect components at different layers of the stack, analyzing the software supply chain of an embedded device is critical. This doesn’t mean that the risk wasn’t there to begin with, but rather that the security community is only now fully understanding the magnitude of the problem.
Our intention with this blog is not to single out specific vendors, but rather promote a healthy debate about this problem. To illustrate how we tackle this issue, we selected a popular facial/thermal recognition camera and describe at high level how we eventually managed to analyze the firmware.
Dahua Face Recognition Access Controller Firmware Decryption
DHI-ASI7213X-T1 is a face recognition access controller which, among other details, can detect the temperature of the person looking into the device. A web management interface is available to configure the access controller. SSH access can be enabled, but to our surprise, the credentials set for the web interface don’t apply to the remote shell. Our understanding is that SSH access is available only to Dahua support, should the need arise.
Firmware can be downloaded from the vendor website, but as you unpack the binary, you’ll notice that the process does not proceed as expected. A series of uImage files can be extracted, but the content of most of these binaries was encrypted with a proprietary scheme. In particular, the partition images containing the final executables were not accessible.
From the artifacts previously unpacked, we started an extensive analysis of all partitions that resulted not encrypted. We then reverse engineered a considerable part of these binaries and eventually identified the functions responsible for the decryption process.
Since the decryption functions contained some customizations on top of the block cipher and we didn’t want to waste more time reimplementing the whole scheme, we opted for an emulation-based approach and let the original code perform the decryption for us.
This implied writing a loader script that would map the unencrypted partitions at the correct memory addresses, then invoke the decryption functions on the encrypted partitions passed as arguments, and finally dump the resulting output from the memory to the disk.
Eventually, we could unpack the decrypted images and access them statically. With full access to the executable binaries, we could then perform the usual analysis.
All considered, this process required a non-negligible effort by our team, and we can easily imagine that asset owners or other researchers may have desisted doing it, given the time and the set of expertise required to conduct this kind of analysis.
Security by Obscurity is Not a Good Strategy
In this post, we presented the problem of extracting and decrypting firmware code, and discussed why, in today’s threat landscape, asset owners need to understand the software stacks that power the devices deployed in their network. We then provided an example of a firmware decryption process that we had to perform, to assess the security posture of a facial recognition access controller.
While the overall encryption scheme used in this product was eventually understood, in general firmware encryption is counterproductive to the security posture of a network and the vendor. We need to assume that an advanced malicious actor will manage to access the firmware of a target device, while asset owners without similar resources and skills are effectively left in the dark.
Network transparency is required for these situations, as it provides the baseline tools to understand what’s happening at a fundamental level. The analysis of firmware images is a complementary approach to network observability, as it allows researchers to further refine their knowledge of a device software stack.
