Searching for vulnerabilities in IoT devices: Case of CVE-2022-46527 (Part 2)

This article is the second part of case study CVE-2022-46527 and will discuss the discovery of the vulnerability and a proof of concept leading to a crash. You can find out more about the equipment in Part One.

Now the embargo on the details of the vulnerability has been lifted, we can now say that the device concerned in this article is an ELSYS ERS Sound with firmware version 2.3.8.

Identification of the code processing the NFC data

In the first part of the article, we learned that the device is configured via messages stored on the NFC chip. With the help of captures of the data exchanged, we have examples of words used in the configuration that will be useful for locating the part of the firmware that is in charge of processing.
 

Figure 1: Extract from an Ndef message

Identification of functions at risk

Using keywords, the function that analyses the data stored on the NFC chip was found with the help of Ghidra.

Figure 2: Overview of the NFC chip’s data analysis function

In this analysis function, it is observed that the keyword “lock” is used in the arguments sent to a function with three parameters:

• The keyword
• The chip data
• The size of the value to be extracted

This function extracts the value associated with a keyword.
 

Figure 3: Overview of the function for extracting the value associated with a keyword

Analysing the origin of the problem

In the current case, the “strncpy” copy function is not supposed to cause any buffer memory overflow problems. This function takes the maximum size to be copied as a parameter so as not to overrun the buffer memory.
Except that, in our case, the maximum size is the size of the value associated with the keyword, which is under user control. This can be larger than the size of the buffer.

Triggering the crash

As the buffer is on the stack, the vulnerability is a stack-based buffer overflow.
The buffer size is 36 characters. In order to rewrite the return address, a payload of at least 36 characters is needed, to which the size of the variables stored with the buffer is added until the function’s return address is rewritten. In our case, 52 characters allow the equipment to crash. By rewriting the return address, it is possible to take control over the instruction execution flow on the MCU.

Figure 4: Example of stack-based buffer overflow effect

By loading the following configuration into the NFC chip, the device crashes and restarts
indefinitely. « lock: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA » The LED flashing white is not a normal behaviour for the device. The LED lights up red to indicate that the equipment has started up.

Figure 5: Device crash after payload loading

A PoC is available on our GitHub.

Suggested correction

The vulnerability is a memory overflow, which can be corrected by improving string size management.

One solution may be to modify the part of the code responsible for calculating the size. As the function takes the maximum size as a parameter, this parameter can be reused with the “strncpy” function. In this way, the maximum size is controlled by the developer rather than the user.

Conclusion

The seller has been notified of this problem with their equipment and has acknowledged receipt of the notification. However, at the time of writing, the vendor had not sent us any information about a new version to correct this problem. In the meantime, a new version of the firmware has been released.
 

The PoC only triggers a crash. In the time available for the assignment carried out for our customer, it was not possible to exploit it properly. There is still some work to be done before it can be exploited, bearing in mind that the MCU’s debug mode is not available. Assuming that the exploitation conditions are met, a real use of this vulnerability might be the extraction of secrets allowing connection to the LoraWAN network by pretending to be the device.