We recently deployed the first component of our “zero-day identification” module, which aimed at identifying vulnerability patterns in scripting languages. It’s been a long time coming and we want to share a few technical details about it with you.
Our objective is to support identification of vulnerability patterns in both scripting languages and compiled binaries. We started off with scripting languages as it seemed to be the easiest path to get results fast. Our first order of business was to identify the distribution of scripting languages within our corpus based off our file categorization. These statistics guided us in choosing which languages to support first.
To identify vulnerabilities, we perform taint analysis by reconstructing the abstract syntax tree and we then traverse this tree. With this approach, we can dramatically increase accuracy of the results and assure that user-controlled input is actually being processed in an insecure way, reducing the overall number of false-positives reported. At the moment, we look for the following vulnerability classes:
Before deploying the PHP static code analysis checker, we tested it with hundreds of selected sample firmware images and reviewed the results. This led to the discovery of around 15 critical bugs spanning 6 different vendors. All these bugs were reported to affected vendors and are in the process of being fixed.
Except this one.
This one is special because it affects a NAS device from Asus, which according to them “has been EOL for years“, with the latest firmware version dating back 10 years. Since there’s no fix in sight, we don’t have to wait for the 90 days and can publish the interesting details.
With this analysis module only being the first step and active research being conducted in the area of automated detection of potential 0-day vulnerabilities, you may expect a constant stream of technical advisories about bugs we already identified and ones we still have to uncover.
Now onto the advisory !
A command injection bug was identified during our scan campaign, so we downloaded the sample and validated the automated results manually.
|Affected vendor & product||Asus M25 NAS|
|Vulnerable version||All versions|
|Impact||9.8 (Critical) CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H|
|Credit||Q. Kaiser, ONEKEY Research Lab
Research supported by Certainity
This bug is probably the easiest one we had to deal with. As we can see in the screenshot below, a cookie value is used unsanitized in a call to
exec(). By adding a semi-colon followed by any kind of arbitrary command, we can inject commands. The code is reachable unauthenticated.
The interesting part here is that Asus copied this file from AjaXplorer, an open-source project, but inserted the command injection bug by trying to add some authentication layer (code between “
You may argue this vulnerability is very obvious and easy to find – and you are absolutely right. It is easy to find and it should have never ended up in production in the first place. Not 10 years ago and especially not today. But bugs like this are a steady companion when researching the security of embedded devices and underline the importance of shedding light into the supply-chain of your devices. This makes the security level of SBOM, device configuration, and also proprietary applications transparent – the only way to reliably determine your own security posture and cyber resilience.
2022-09-12 – Sent coordinated disclosure request to firstname.lastname@example.org
2022-09-13 – Asus answered “[…] since this model, NAS-M25 is end of life for years, we will not maintain its firmware and its security.”.
2022-12-01 – ONEKEY release its advisory