New Axis OS Security Research Aided by Transparent Design

In this blog, we publish three new vulnerabilities (CVE-2021-31986, CVE-2021-31987, CVE-2021-31988) affecting all Axis devices based on the embedded Axis OS. This follows our earlier work on vulnerability research on IoT video camera platforms published here. This information is being published as part of a coordinated disclosure with the vendor, Axis, which has released firmware that fixes the issue. Details on the nature of the vulnerabilities can be found below, and specific remediation steps are in the conclusion of this post.

While documenting our research for these vulnerabilities, we describe how the transparent approach applied by Axis into security review allowed researchers to perform an immediate static analysis of the vulnerabilities and to precisely execute dynamic tests to validate them, dramatically optimizing the effort required for a review by any asset owner.

Some History

In 1883, the Dutch linguist and cryptographer Auguste Kerckhoffs, in his essay La Cryptographie Militaire, described six fundamentals for the practical design of a ciphersuite. One of these passed into history as the cardinal principle of any modern cryptosystem:

“The design of a system should not require secrecy, and compromise of the system should not inconvenience the correspondents.”

The idea behind what is known as the Kerckhoffs’s principle is simple: the security of a cryptosystem shall not rely on the secrecy of its operation or components. Instead, it shall rely on limited, key information that, if kept secret, guarantees that all security requirements of the scheme are satisfied, regardless of whether an enemy knows the details of its inner workings or not.

Despite being formulated more than a century ago and being specifically relevant to cryptography, Kerckhoffs’s principle still applies today for the security design and review of modern IT, OT and IoT devices. Notably, devices shall be conceived to be as transparent and open as possible, in order to allow independent reviewers to have all necessary access and instruments to analyze their security.

This stands in contrast with the “security by obscurity” approach, which instead bases the security of a system on the concealment of its operation and with the publication of the least possible amount of information on it. This latter solution historically proved to be unsuccessful in the long run, to the point that standard bodies such as NIST have started advocating against it.¹

Security Through Obscurity

In a recent blog post, we unveiled a new Remote Code Execution vulnerability affecting the N48PBB, a popular Network Video Recorder (NVR) manufactured by Annke.² During that analysis, we obtained the first hint of the presence of a vulnerability when, while fuzzing HTTP endpoints, we managed to make the device reboot on its own after sending a very large payload.

Nevertheless, in order to precisely triage and validate the vulnerability, a significant effort had to be applied:

1. The device allowed on-demand access via SSH, but only to a restricted shell which proved to be useless for debugging purposes;
2. No firmware was readily available for our analysis;
3. When we managed to obtain access to the firmware, it proved to be encrypted.

Indeed, all these countermeasures caused the analysis to take longer than expected. This might create a sense of security, because attackers, in order to create and finely tune attack payloads, need to invest a substantial effort to reverse engineer the obfuscation steps and obtain complete access to the device.

However, it must be highlighted that this does not have any effect on the presence or absence of vulnerabilities in the product, whether someone discovers them or not.

Moreover, a side effect is that security researchers and asset owners both need to invest the same effort in order to find and responsibly disclose bugs to the vendor, to the point that some might decide to abandon the review and keep a product inside their network whose security state is unknown.

The Axis Companion Recorder

Continuing our research on IP video surveillance systems, we decided to investigate the security of a long-time manufacturer of IP video surveillance equipment, i.e., Axis Communications.³ To do so, we purchased an Axis Companion Recorder, a compact NVR capable of supporting up to 8 PoE IP cameras directly connected to it. For more information about NVRs, please refer to our previous blog,² containing a detailed description of their operation as well as their security.

Immediately after setting up the device, the transparent approach adopted by Axis is evident.

First, the device allows out-of-the-box, unrestricted remote access via the SSH service, which can be enabled through the web interface.

Secondly, firmware images can be freely downloaded from the Axis website and analyzed. The popular “binwalk” tool can be used to unpack the images. In the screenshot below, firmware version 9.80.2.2 is extracted and the contents of “/usr/bin” is listed.

This provides a superb analysis platform in case a security researcher or asset owner wants to perform a review or investigate any unusual behaviors, giving them all necessary access and tools.

Vulnerabilities Description

Our research on the Axis Companion Recorder discovered the following vulnerabilities:

• Heap-based buffer overflow (CVE-2021-31986, CVSSv3 6.7)
• Improper recipient validation in network test functionalities (CVE-2021-31987, CVSSv3 4.1)
• SMTP header injection in email test functionality (CVE-2021-31988, CVSSv3 5.5)

CVE-2021-31986: Heap-based Buffer Overflow

The first vulnerability was found entirely by static analysis, and would hardly have been discovered by other means. The issue was noticed in the read callback function (the function set via the libcurl “CURLOPT_READFUNCTION” option) of the “libhttp_smtp_notify.so” library. Notably, the read callback function was noticed failing to verify that no more than “size” multiplied by “nitems” number of bytes are copied in the libcurl destination buffer (on our device, 64 kB).

Among the copied bytes, the read callback function copies in the libcurl destination buffer the “to”, “from”, “subject” and “body” HTTP parameters of the request to the endpoint “/axis-cgi/smtptest.cgi”, which is sent from the browser when a test of the SMTP configuration parameters is attempted. This request is normally a GET request; as such, the parameters are passed through the query string in the URL, which is limited to less than 10,000 characters, too few to trigger the issue. However, firmware-assisted manual analyses proved that POST requests are accepted as well by the endpoint, which are not restricted by the aforementioned limit. Finally, the possibility to connect via SSH to the device and attach a debugger to the CGI process dynamically confirmed the vulnerability.

Thus, a blackbox-only test would not have found the problem for the following reasons:

1. The tester would need to change the request to use a different HTTP method (e.g., POST), to avoid the restriction posed by the query string, and know that the remote endpoint supports it;
2. The tester would need to send the exact amount of bytes in the correct parameters;
3. The tester would need to recognize that a memory corruption has happened, considering that no reboots are triggered on the device and that the only visible response is a generic “500 Internal Server Error”.

The SMTP test functionality resulted in being accessible only after authenticating to the device. However, note that the aforementioned HTTP request was devoid of any protections against Cross-Site Request Forgery (CSRF) attacks. Additionally, as the application uses a Digest Authentication mechanism, modern browser-side mitigations such as “SameSite=Lax by default” cookies are not applicable.

As a result, by convincing a victim user into visiting a specifically crafted webpage while logged-in to the Companion Recorder web application, an external remote attacker is able to trigger a memory corruption on the device in the context of the “smtptest.cgi” process and, possibly, execute arbitrary code.

CVE-2021-31987: Improper Recipient Validation in Network Test Functionalities

The second vulnerability is another confirmation of the importance of a transparent approach to security. In this case, the vulnerability stems from the fact that the test functionalities of HTTP, email and TCP recipients have blocklist-based security checks to impede interactions with localhost-exposed network services, which could be circumvented with known bypasses or were incomplete.

By statically analyzing the firmware, the blocklist approach can be immediately spotted, as shown in the following evidence extracted from an analysis session of “httptest.cgi”.

Additionally, the possibility of uploading the famous “tcpdump” tool on the device dynamically confirmed the feasibility of sending requests to localhost-exposed services.

CVE-2021-31988: SMTP Header Injection in Email Test Functionality

The third vulnerability is due to an SMTP header injection, located in the aforementioned SMTP test functionality.

Again, the possibility of statically looking into the firmware allowed precise identification of the vulnerable parameter and verifying the absence of input validation functions, as shown in the following evidence extracted from an analysis session of “smtptest.cgi”:

Remediation

Axis is in the process of releasing patches for all affected devices, on the Axis OS LTS & Active tracks⁴:

CVE-2021-31986 and CVE-2021-31988

• AXIS OS Active track 10.7
• AXIS OS 2016 LTS track 6.50.5.5
• AXIS OS 2018 LTS track 8.40.4.3
• AXIS OS 2020 LTS track 9.80.3.5

CVE-2021-31987

• AXIS OS Active track 10.8
• AXIS OS 2016 LTS track 6.50.5.5
• AXIS OS 2018 LTS track 8.40.4.3
• AXIS OS 2020 LTS track 9.80.3.5

Axis devices not included in these tracks and still under support will receive a patch according to their planned maintenance & release schedule.

We urge users to download and install the latest firmware version from the official Axis website to protect the devices from cyberattacks.

Nozomi Networks has released specific updates to its Threat Intelligence service to detect exploitation attempts of the vulnerabilities. Thankfully, the open, transparent design of the Axis portfolio allowed Nozomi Networks Labs to accelerate our research and identify these vulnerabilities expediently.

We thank Nozomi Networks for their research and good collaboration throughout the disclosure process. AXIS Communications welcomes researchers to inspect our devices and firmware as it is our belief that long-term sustainable cyber security is created through collaboration and transparency.

Sebastian Hultqvist, Global Product Manager for AXIS OS

References:

1. “Guide to General Server Security,” National Institute of Standards and Technology
2. “New Annke Vulnerability Shows Risks of IoT Security Camera Systems,” Nozomi Networks Labs
3. Axis.com
4. “Axis OS LTS & Active tracks,” Axis.

^‍