Smart home devices like network surveillance cameras are becoming increasingly popular due to their low prices. This raises an important question: How secure are these affordable cameras? This blog post details a security evaluation of a budget surveillance camera from ieGeek, which promises increased physical security at a minimal cost. But what about its digital security?

Overview of Attack Vectors

To understand the security risks associated with the camera, we first look at its possible attack vectors:

Physical Security

Physical security is an important aspect of assessing the overall security of an IoT device. It involves evaluating how well the device is protected against physical tampering and unauthorized access. This includes analyzing the robustness of the device’s enclosure, the accessibility of its internal components, and the presence of any physical interfaces that could be exploited. A thorough examination of these factors helps determine if the device can withstand physical attacks and maintain its integrity when exposed to potential threats. Effective physical security measures are essential to prevent attackers from gaining direct access to the hardware and manipulating the device to bypass its digital defenses.

Packaging and Housing

An initial indicator of a device’s security can be its packaging and housing. If the case is easy to open and the components are easily accessible, it could either indicate good repairability or that the manufacturer has put little effort into securing the device. The packaging should also be checked for parameters like MAC addresses, which could be used later during the investigation of network traffic and potentially exploited by an attacker. It is possible that attackers could note MAC addresses of unsold devices in retail stores and later track and attack these devices using specialized IoT search engines. The following screenshot demonstrates a search for a MAC address of a surveillance camera using the IoT search engine shodan.io, which provides additional information such as the IP address and hostname of the camera.

The MAC address of the ieGeek camera is clearly visible on the casing, making it easily accessible to attackers who could potentially track it using search engines like Shodan.

Circuit Board

In addition to a visual inspection, the hardware of IoT devices can be examined at a technical level to reveal information. A common method is to establish a connection with debugging interfaces like UART. This allows the information output by the device during boot to be read in a console window. The following figure shows such a connection. The mainboard of the camera is visible, connected to a UART-to-USB converter, enabling the boot process information to be displayed in a console window. Various information about the hardware and the version of the Linux operating system used are visible.

However, UART interfaces are not always easily identifiable on the circuit boards of the devices being examined. The connection points are not always visually identifiable and, if they are, often not clearly labeled. In this case, it is necessary to investigate the individual contacts on the board using a multimeter. Ideally, a suitable candidate for the UART interface can be determined by eye as four adjacent contacts. The four contacts for UART consist of Transmit (TX), which transmits data from the device, Receive (RX), which receives data from another device, Ground (GND), and Voltage at the common collector (VCC). If these contacts are not already labeled, they can be identified using a multimeter. To find the ground reference contact (GND), set the multimeter to continuity testing mode, place the black probe on a ground point, and test all contacts with the red probe until an audible signal is heard. To identify the voltage supply contact (VCC), set the multimeter to voltage measurement mode and test all contacts until one shows a constant voltage of 3.3V or 5V. Typically, two contacts will show such a voltage. After restarting the device, one of the contacts should show voltage fluctuations, indicating it is responsible for transmitting data (TX). The remaining contact is for receiving data and should have the lowest voltage of all contacts. To connect the UART contacts of the board to a computer, a USB-to-UART adapter is required, with the RX, TX, and GND contacts connected accordingly. Note that the TX contact of the board should be connected to the RX contact of the adapter and vice versa. Finally, the baud rate of the device needs to be determined, which can be done by trial and error with common baud rates, such as 115200, or using programs that can automatically identify the baud rate. Once identified, a command line connection with the device can be established using the Linux program Screen or the Windows program Putty.

Network Security

For penetration tests of traditional Ethernet and WLAN networks, programs like nmap and Wireshark are often used. Nmap sends IP packets to all possible network addresses to identify all active devices in the network based on the responses. It also allows further analysis of the discovered devices by searching for open network ports and identifying the services and their versions running on those ports. Based on this information, further attacks can be prepared by identifying known vulnerabilities of the found services using vulnerability databases. The following screenshot shows such an nmap scan targeting the network camera:

The screenshot shows open ports revealing that, in addition to Real-Time Streaming Protocol (RTSP) and Real-Time Messaging Protocol (RTMP), used for video transmission in surveillance cameras, a Domain Name System (DNS) server, a web server, and a proxy server are running on the camera. It is clear that a web interface for administration is available on the camera. Since only the HTTP port 80 is accessible and not the HTTPS port 443, it is expected that the web interface is only accessible via the insecure HTTP protocol. Nmap’s service fingerprinting, activated by the -sV parameter, identifies the web server as Mongoose httpd and RTSP as Hipcam RealServer rtspd version 1.0. The operating system is identified as DD-WRT version 3.0 with Linux Kernel version 4.4.2, and the network card manufacturer as Shenzengtong BO Weitechnology.

Software

Web Interface

The camera’s web interface uses the HTTP protocol instead of HTTPS. For user authentication, Basic-Auth is used, where the username and password are encoded with Base64, making them easy to decode. The following is a GET request showing authentication on the web interface, intercepted using the Burp Suite interception proxy.

GET /cgi-bin/hi3510/param.cgi?cmd=getlanguage HTTP/1.1
Host: 192.168.178.15
Authorization: Basic YWRtaW46YWRtaW4=
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.6099.71 Safari/537.36
Accept: */*
Referer: http://192.168.178.15/
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
Connection: close

The Base64 encoded string YWRtaW46YWRtaW4= decodes to admin , the default login credentials set at the factory. These default credentials are also printed on a sticker on the camera’s casing, posing a security risk as they are easily guessed and should be changed immediately. However, intercepting traffic with Burp Suite shows that even new credentials are transmitted in plain text. The following intercepted POST request shows the camera being provided with new credentials.

POST /web/cgi-bin/hi3510/param.cgi HTTP/1.1
Host: 192.168.178.15
Content-Length: 266
Cache-Control: max-age=0
Authorization: Basic YWRtaW46YWRtaW4=
Upgrade-Insecure-Requests: 1
Origin: http://192.168.178.15
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.6099.71 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Referer: http://192.168.178.15/web/user.html
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
Connection: close

cmd=setuserattr&cururl=http%3A%2F%2F192.168.178.15%2Fweb%2Fuser.html&-at_username=admin&-at_newname=lars&-at_password=password&cmd=setuserattr&-at_username=user&-at_newname=user&-at_password=user&cmd=setuserattr&-at_username=guest&-at_newname=guest&-at_password=guest

The use of Base64 encoding for credential obfuscation and the lack of HTTPS support clearly demonstrate cryptographic weaknesses in the network camera.

Android App

Since the source code of smartphone apps cannot always be fully reconstructed and the analysis can be complex, it may be worthwhile to use an application like the Mobile Security Framework (MobSF) for quick but not very in-depth static and dynamic analyses of Android and iOS apps. To create an analysis, simply upload the APK file of an Android app or the IPA file of an iOS app to the web interface and click the Analyze button. The analysis of the ieGeek cameras app is shown in the screenshot below.

The screenshot shows a static analysis of the app used to control ieGeek surveillance cameras. Potential vulnerabilities in the app’s source code, such as weak cryptographic algorithms or enabled debugging that should only be used during development, are identified. These vulnerabilities are categorized according to common standards like Common Weakness Enumeration (CWE), OWASP Mobile Application Security Verification Standard (MASVS), and the OWASP Top 10. MobSF also analyzes the permissions requested by the app, examines the Android Manifest file, and lists the Internet domains and URLs the app can connect to. Additionally, it highlights all variables and their values stored in the app, automatically identifying potential hard-coded secrets like API keys. The screenshot shows several passwords stored in plain text, including not only the device’s passwords but also the WLAN network passwords where the camera is set up.

Conclusion

Based on this brief analysis, it can already be concluded that the security of this and possibly other budget network cameras is insufficient. A more intensive analysis would likely reveal even more and more severe vulnerabilities. Given the current findings, it can be stated with sufficient certainty that this camera should not be used.