Working With the Community – Significant Vulnerabilities in Reolink Cameras

As part of our ongoing efforts to improve the state of IoT and embedded devices security and in addition to our in-house research efforts, VDOO has been working closely with the information security community to assist in coordinating vulnerability disclosure to vendors. As such, VDOO acts as an intermediary 3rd party to help researchers communicate with the vendors as well as to help the vendors deal with the disclosed vulnerabilities in the most professional and secure way as possible in order to minimize risks to deployed devices and end users.

Today we disclose 3 vulnerabilities as part of our collaboration with renowned security researcher, bashis. In recent years, bashis has discovered and published multiple 0-day vulnerabilities in different connected devices, mainly from the video surveillance domain. Researching the Reolink RLC-410 video surveillance camera, bashis has discovered and disclosed 3 vulnerabilities – a command injection remote-code execution vulnerability requiring authentication and two stack-overflow vulnerabilities. The vulnerabilities, which appear to be relevant to multiple Reolink camera models, were responsibly disclosed to the vendor. We would like to thank bashis for his work and conduct in the process.

PoC

VD-1120 – Command Injection in the API cgi handler through the TestEmail functionality

Please see the attached Python file containing the full proof-of-concept for this vulnerability:<a :href="$withBase('/assets/images/blog/uploads/files/Reolink-IPC-RCE-VDOO.zip')" download> reolink-ipc-rce – vdoo</a>

VD-1121 – Stack overflow in the API cgi handler through the upgrade functionality

The vulnerability can be reproduced by issuing the following HTTP request –

VD-1122 – Stack overflow in the API cgi handler through the ImportCfg through the functionality

The vulnerability can be reproduced by issuing the following HTTP request –

Recommendations for Device Makers

We would like to relate to some bad architectural practices that were found in the cameras analyzed in this research, that make it easier for an attacker to discover and exploit vulnerabilities. We encourage device makers to take the below recommendations into consideration.

User-mode ASLR. ASLR is implemented and turned on already in the Linux OS running on the device, and the only change needed to be done is to make the main binary compatible with it by adding the “-pie -fPIE” flag to GCC. With this feature, an attacker cannot guess the address of the functionality he wants to jump to.

Stack canaries. This is a very simple and important security feature that can be turned on by adding the “-fstack-protector-all” flag to GCC. With this feature, the executable will crash when it recognizes that the stack was compromised. That would lead to a short denial of service, but at least it won’t allow an attacker to run code of his choice. It is important to note that this feature can lead to performance degradation since a stack canary is checked for every function. If this performance degradation makes it impossible to use, it is possible to control the creation of stack canaries and set them to be put only on functions that have high potential to be vulnerable to stack-based buffer overflows. If using the GCC compiler, that can be done by using the “-fstack-protector” flag together with "--param ssp-buffer-size".

Lack of Binary Firmware Encryption. Firmware encryption will raise the bar and make it harder for adversaries to analyze the firmware for bugs, and specifically use binary diffing methods between the latest and previous firmware in order to find and analyze the patches and in this way – uncover the vulnerabilities that still exist in the previous version. Moreover, the device contained unstripped binaries with symbols like function names. This aided us in understanding how the code works. On the other hand, it is worth noting that the security by obscurity approach for firmware content may contribute to a situation in which issues exists but are not being discovered and remediated since the firmware is encrypted properly. Also, by distributing a non-encrypted firmware available to the community, security researchers can review the security and enhance it with their findings with a responsible disclosure process. Vendors should consider this tradeoff carefully.

The firmware file is not digitally signed. This allows an attacker to repack a malicious firmware. Vendors should consider signing their firmware, to protect from this threat.

Share this post

Written By

Or Peles

Or leads the Vulnerability Research Team at VDOO. He has vast experience in finding and exploiting vulnerabilities in operating systems and applications - with a focus on embedded devices. Or had previously conducted 0-day vulnerability research as a senior member of the IBM X-Force team.