Lights, Camera, HACKED! An insight into the world of popular IP Cameras
Preface
During the Covid-19 pandemic, the battle to secure and protect businesses as well as consumers changed from the office environment to our homes, but this did not stop us from working on research projects aimed at contributing to the creation of a safer online world.
Working from home, this research was carried out to understand any recent developments in the IP camera space based on popularity of such devices available from popular online retailers and marketplaces. With new IoT laws being drafted [1], this research also shows the types of risks that consumers and businesses are facing and why there is paramount importance for such regulations to be put into place in order to protect consumer security and privacy.
Testbed Setup
To facilitate testing unknown devices from a home network, a test bed was built to mimic a normal home network while being isolated and monitored at the same time. The configuration used the pfSense firewall/router appliance, a very noisy managed switch and a couple of ethernet cables to achieve this.
A rooted Nexus 7 tablet was a favourable choice for intercepting/viewing the communication from each camera and mobile application with the help of Burp to proxy this traffic.
Approach and techniques
The process of assessing each device was broken down in terms of what each camera supported or offered by way of functionality:
- Physical packaging
- Infrastructure
- Embedded Web Application
- API
- Hardware
Any issues discovered in these discrete areas can be seen in the proceeding sections.
IP Cameras Researched
- ieGeek (CT0414BKUK)
- TP-Link Tapo (C200)
- Neos Smartcam (NS-CAM-02)
- Victure (PC530)
- Mibao (D600)
Discovered Issues
ieGeek (CT0414BKUK)
Physical packaging
On the packaging there was a silver sticker that stated the username and password was “admin:admin” indicating that the camera has default credentials in place.
One key thing to note here is the visible UID number that can be seen on the sticker, which is the ID of the camera used in the P2P connection. The camera’s UID can be manually added alongside the username and password via the mobile application. If these credentials are not changed, this can leave the device vulnerable to remote viewing.
Infrastructure
Predictable UID values for devices
The UID value is poorly constructed and can be easily generated using a PoC. The format of a UID is AAAA-000000-XXXXX
- Part 1: Same 4 letters at the start
- Part 2: 6 numbers at random in the middle
- Part 3: 5 random letters at the end
Having this basic knowledge of the UID and using the default credentials, the camera feed could be accessed using the software provided by ieGeek from their website by testing each UID value. This can leave a number of IP cameras vulnerable to unauthorised viewing with the privacy of users at risk.
Default unauthenticated access to camera feed
By default, the cameras feed can be accessed without a username and password. This can be changed via the web interface under the option "RTSP Permission Check".
- Without credentials: rtsp://<IP Address>/11
- With default credentials: rtsp://admin:admin@<IP Address>/11
Default P2P Camera feed activated and sent to a server in plaintext
The cloud function of the camera uses the P2P protocol to send and make requests back to a server based in China in plaintext. It was found that all connections back to this were made in plaintext regardless of protocol, this includes the viewing of the cameras stream and control. HTTPS was not found to be implemented anywhere on the camera.
Web Application
Access to files stored on the camera
Once the default credentials had been used to login to the camera, the tool dirb was used to fuzz the camera's web server to discover any paths of interest. The discovered paths are shown below:
- http://<IP Address>/js
- http://<IP Address>/lib
- http://<IP Address>/log
- http://<IP Address>/resources
- http://<IP Address>/sd
- http://<IP Address>/swfs
The number of links discovered showed that the SD card, log files and website front-end code were accessible from the web interface. This includes any footage that has been recorded by the device and stored on the external SD card.
Basic Authentication in use
When the camera is booted up, a website service is loaded and requires a login to gain access. Default credentials were then used to gain access and there was no setup to force change of the default password in place. Burp caught this login process; the session was found to be using HTTP Basic Authentication to handle the username and password. The Base64 translates to admin:admin.
Broken/Unknown PC Download Binary
The binary that is provided by the software on the embedded web application was found to be unusable and does not install any program when launched.
Hardware
/etc/shadow file found using hashing algorithm DES Crypt
Outputting the /etc/shadow file revealed three accounts; admin, root, and default. The hashes for these were found to be in the format of DES crypt. The hash for admin was put into our internal password cracking rig and cracked as seen in the list below. The root account password was found via another research blog [3].
- admin:2601hx
- root:hichiphx
- default:<no password required>
The hashes discovered on the device:
- root:F0pCSaZ.P1Rrc:0:0:99999:7:::
- default::10933:0:99999:7:::
- admin:RdQhwfYI/a1kQ:0:0:99999:7:::
Default Enabled UART debugging port
On the board, the debug port was discovered to be enabled after hooking up a USB serial device to the pins. The layout is from left to right: VCC, RXD, GROUND, TXD.
PuTTy was used to connect to the COM port which then presented a series of bootup messages. Using the discovered credentials root:hichiphx, the root account was logged into and root was acquired on the device.
TP-Link Tapo (C200)
Infrastructure
Vulnerable to Heartbleed
Running testSSL.sh on port 443 revealed that the device was vulnerable to the Heartbleed vulnerability (CVE-2014-0160).
Using the Metasploit Heartbleed scanner in verbose mode, the device's memory was dumped and detailed HTTP requests were acquired from the device.
As seen in the testssl results provided, there was also a wide range of other HTTPS issues that affected this device. The versions of protocols the service offers has not been set to TLS 1.2 or higher.
This has now been patched by the vendor with a technical advisory released by us - the link to this can be found here.
API
Pass-the-Hash attack
Using the Heartbleed attack to grab the MD5 Hash, a Pass-the-Hash attack could be performed to acquire something called the stok value. This acts like a session cookie which is passed to API requests to authenticate as the user.
Request:
Response:
Controlling the device using the issues discovered
Once the camera's stok hash was acquired, a number of attacks could be launched against the device. The video below demonstrates the Heartbleed attack being used to grab the MD5 value of the cloud password from the memory dump, generating a stok value to authenticate to the device and controlling the motor of the device using a PoC.
The PoC could also action the following methods below without informing the user via the mobile application:
Format the SD card
Turn off the alarm
Turn off the privacy mode
Move the camera motor
Create account to access the RTSP feed
This post request will create an account to login to the RTSP feed of the camera and wipes out the previous settings. Once this method is used, it's then possible to access the camera's feed in one's own authenticated manner.
- Username: testing
- Password: testtest
- Access via VLC player: rtsp://testing:testtest@<ip>:554/stream1
The ciphertext plays a part in blocking making on-the-fly passwords for the account without the mobile app as it acts as a signature generated for this request by the app but can still be replayed if the request is captured.
Tool output
We developed a tool which performs the Heartbleed attack on the device to extract the stok value and control the device. This PoC tool will be released once everyone has been allowed enough time to patch and its aim will be to allow for testing for the presence of this vulnerability.
Neos Smartcam (NS-CAM-02)
Hardware
Multiple Vendors Configurations on the device
From looking at the configuration files stored on the camera, there seems to be a number of vendors using the device. The camera makes a wide range of connections to these servers owned by each vendor going on the configuration files that were discovered via root access by UART.
- https://www.hualaikeji.com/en
- https://www.ismartalarm.com/
- https://shop.neos.co.uk/
- https://wyze.com/
Default Enabled UART debug
UART Pins were discovered on the device to be active and could be connected to using the configuration USB: GND, RXD, TXD -> Board: GND, TXD, RXD.
Again, this type of port should be locked down and removed from operation when the device leaves the factory.
uBoot Bypass leads to root access
When loading the device attached to the UART, the uBoot can be used to bypass the login screen. This can be done by adding the line 'init=/bin/sh' to the end of the boot argument.
To perform this, the following commands were issued:
- setenv bootargs 'console=ttyS1,115200n8 mem=104M@0x0 ispmem=8M@0x6800000 rmem=16M@0x7000000 init=/linuxrc rootfstype=squashfs root=/dev/mtdblock2 rw mtdparts=jz_sfc:256k(boot),2048k(kernel),3392k(root),640k(driver),4736k(appfs),2048k(backupk),640k(backupd),2048k(backupa),256k(config),256k(para),-(flag) init=/bin/sh'
- boot
/etc/shadow file found using hashing algorithm DES Crypt
The hashed password for the root account was found to be using the DES algorithm. This was acquired and cracked using our internal password cracking system.
- rJ0FHsG0ZbyZo:ismart12
The deprecated DES encryption algorithm should not be used due to the limited amount of key lengths derived from 56 bits and being susceptible to easier brute-force attacks [4].
Leftover Developer Information
The device had a range of information that had been left over by the many companies that developed and used the firmware image.
[root@Ingenic-uc1_1:bin]# cat mount.sh mount -o nolock,rw 10.0.0.167:/home/xuxuequan/Ingenicwork/sharenfs /mnt
/home/ptkang/work/platform/isvp_20160504_e/proj/sdk-lv3/src/imp/core/group.c /home/xuxuequan/Ingenicwork/toolchain/mips-gcc472-glibc216-32bit/bin/../mips-linux-gnu/libc/uclibc/usr/lib/crt1.o
This type of information should be removed when creating a production firmware image.
Default Enabled UART debugging port
UART Pins were discovered on the device to be active and could be connected to using the configuration USB: GND, RXD, TXD -> Board: GND, TXD, RXD.
Miio Client Token discovered
This information was discovered on the device but is believed to be linked to another vendor.
[root@Ingenic-uc1_1:miio]# cat device.conf vendor=isa model=isa.camera.isc5c1 mac=34:CE:00:E3:FD:D7 did=59477216 key=<Redacted>
[root@Ingenic-uc1_1:miio]# cat device.token <Redacted>
S3 Credentials were discovered in a Memory Dump
When performing a memory dump on the device, S3 credentials were found to be stored by the iCamera application, which Neos states is a shared code base between vendors for the application.
Victure (PC530)
Due to the device operating solely in the cloud, testing was restricted with no issues to report.
Mibao (D600)
Testing was restricted again for this device due to operation via the cloud, but we were able to perform hardware-side review.
Hardware
Plaintext password (httpd.conf)
A username and password for an Apache web server directory called /secret was found in the firmware dump. This configuration file appears to be invalid as discovered by the documentation from the Apache server website [2].
A:* /secret:tonywu:<redacted>
Conclusion
Alongside the issues we uncovered, the most worrying is the Heartbleed vulnerability still being discovered in 2020, 6 years after its initial discovery. What makes this an unusual case is that the device it was found on has been out for around 1 year, which shows that security checks for legacy vulnerabilities in components are not happening during or after production, thus resulting in products that are vulnerable 'out of the box' yet being purchased by consumers.
What we are seeing are more devices that are using default credentials, weak (or no) encryption standards and leaking a wide range of information about the developer or consumer. For example the Neos camera exposed a range of information that belongs to a few developers in the firmware. Basic development processes are not being implemented by a number of vendors when developing these products. In this case, having a development and production firmware would have helped to avoid this type of information being released out into the wild.
Overall, the research has shown us that there is no clear baseline security standard being applied to these products. The new IoT law that is being drafted will help to improve security using a form of standardisation and remove some of the issues that we have discovered in this research from being pushed onto the consumer to mitigate. But this can only happen if standards are followed correctly and only if failures in, or vulnerable divergences from, baseline security are penalised through regulation or legislation.
Consumer Recommendations
Remove any stickers that indicates a UID value, username/password from the camera. This is extremely important if the camera is going to be mounted outside. This will avoid the disclosure of sensitive information.
If your router has the ability to create a VLAN (This can also be a guest network setting in some routers), setup an isolated network for these devices. This method adds another layer of protection against an IoT device that could be compromised.
Perform a full sweep of the device settings using the embedded web application or mobile application (depending on the product) ensuring default settings are changed. This includes changing username/password, enabling authorised RTSP access only and disabling any FTP/Telnet services. This is fully dependent on what features the device offers.
If a device does not support HTTPS or can be seen sending information in plaintext, then the decision needs to be made if a workaround can be integrated to enable the secure method of viewing/controlling the camera or not to use the device at all.
Once a device has been setup, the latest firmware patches need to be installed or set to auto install to ensure that the device is protected against future exploits and vulnerabilities. This includes performing checks each month for updates via the mobile application if you don't have the option to auto update.
When a device hits end of life in terms of product support, the security of the device needs to be assessed. A quick fix could be to buy the newer model or to develop a work around as mentioned previously.
[1] https://www.gov.uk/government/news/government-to-strengthen-security-of-internet-connected-products
[2] https://httpd.apache.org/docs/2.4/howto/auth.html
[3] https://blog.sengotta.net/short-security-overview-of-the-escam-g02/
[4] https://searchsecurity.techtarget.com/definition/Data-Encryption-Standard