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: reolink-ipc-rce – vdoo
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.
About VDOO
VDOO is a technology-driven company that strives to change the reality of unprotected connected devices. VDOO is building a line of products to support device manufacturers in embedding security into their connected devices at the development stage and enable post-development security.
In addition to developing products and services, VDOO invests significant efforts in wide scope research of connected devices. Security cameras is one focus area of this research.
VDOO research goal is to contribute knowledge and tools to mitigate risks, as well as encourage the devices’ manufacturers to implement the right security for their products. We at VDOO believe that an appropriate implementation of the security essentials will dramatically decrease the chances of exploiting vulnerabilities on the device.
If you are a security researcher that would like to work with us as part of our InfoSec community initiative, please feel free to contact us at security@vdoo.com
VDOO 