How a Benchmark Test Uncovered Vulnerabilities in Over 80,000 QNAP Devices

Part of our work involves deploying Sternum runtime security solutions on various devices and platforms, for ongoing compatibility and performance testing, as well as security research.

And so it happened that a few months ago we deployed our runtime protection on a QNAP TS-230 NAS device, to run a series of run-of-the-mill benchmark tests. Almost as soon as we activated Sternum, however, our attention shifted to a string of security alerts coming from our system, informing us about multiple memory access violations that were detected on the device.

To understand how and why these alerts were generated – especially if new to Sternum – you need to know a few things about the patented EIV™ (embedded integrity verification) technology that powers our runtime protection.

In a nutshell, you can think of an EIV™ as a “RASP meet XDR”, an endpoint security solution tailored for embedded devices, that integrates into the firmware and profiles code and memory in runtime, deterministically alerting on everything that would compromise their system integrity, be it a live attack attempt or a potentially exploitable vulnerability.

In this case, the reason for the alert was the latter, multiple out-of-bounds read and write requests, performed by several memcpy functions.

Once integrated with the device, Sternum was able to immediately detect these requests and auto-identify them as memory access violations. Something that could cause stability issues and unpredictable code behavior, or even lead to arbitrary code execution – if exploited by a malicious threat actor.

Vulnerability Details

As shown above, the alert that followed provided us with the exact address of the vulnerable functions and, since the product’s firmware was built with debug information, within minutes, we were able to determine exactly what happened, mapping the issues to the following two vulnerabilities:

1. In the source file api.cpp, the int iface_status2interface_status function contained a memcpy call with a constant size of 46. The source string content for the call, however, was an IPv6 address, which meant that it could be 39 bytes at the most, resulting in a potential ‘out of bounds’ issue, with all of the abovementioned implications.
2. In the source file NetworkInterface.cpp, in the function int get_interface_slaac_info there were four memcpy calls with the copy size 46, which copies JSON values from buffers returned by Json::Value::asCString. In practice, however, those string buffers were often shorter than 46, which causes potential ‘out of bounds’ issues in all four memcpy calls.

We have notified the vendor about these vulnerabilities, sharing the alert data and our findings. After a quick investigation, QNAP acknowledged the problem and issued the following CVEs:

• CVE-2022-27597
• CVE-2022-27598

From the details of the CVE, we learned that the issue was broader than we expected, impacting multiple operating systems:

• QTS
• QuTS hero
• QuTScloud
• QVP (QVR Pro appliances)

By our conservative estimate, and with the help of Shodan, this means that the CVEs impacted over 80K connected devices worldwide.

In the CVE details, QNAP also shared the information about the patch, notifying that they have already fixed the vulnerabilities in the following operating system versions:

• QTS 5.0.1.2346 build 20230322 (and later)
• QuTS hero h5.0.1.2348 build 20230324 (and later)

Deterministic Protection for Deterministic Systems

The story of connecting a device to Sternum and instantly discovering two zero-day vulnerabilities might sound extraordinary to some, but (and here we probably should add “sadly”) it is not surprising to us at all.

The fact is that every new integration or POCs we have done so far ended with the same result: us uncovering new vulnerabilities in runtime pretty much as soon as the device was connected.

This speaks to gaps left behind by the security tests performed on these devices in development and also – more alarmingly – to the number of vulnerable devices in the wild.

With tens of billions of devices in circulation, and many used for critical functions in healthcare, infrastructure, communication, transportation, etc., the threat posed by undetected vulnerabilities should not be taken lightly.

The good news is that the majority of the devices, especially those lacking (or not being able to support) robust means of protection, are rudimentary and deterministic by nature. Their “for purpose” design makes them predictable and – in turn – easy to secure with equally deterministic solutions.

Using EIV’s runtime protection, we do exactly that – leveraging the predictability factor to our advantage to ensure integrity with a complete degree of confidence in a way that goes far beyond anything that runtime protection can promise today for dynamic and much-more-complex web applications.

So what does it mean exactly? Well, this means that we can help spot zero days in development and address them before they are discovered, block attack attempts from known and unknown attack vectors, harden devices in the field, and more.

With a deterministic security model for deterministic systems, we can achieve a degree of security that delivers the benefit of EDR and RASP in embedded systems – self-correcting, futureproof, and completely autonomous protection that has the power to close the technology gap and flip the script on IoT security