This post is in conjunction with a project that can be found on my Github. There was a two hour workshop which covered the methodology live on stream, for the slides please see DVR Security Evolution.
Results and observations for this project will be updated January 2021 on the Github project page. The current stage is local testing and working with other researchers who have a range of DVR’s which can be tested and provide some sample results.
Introduction
A review has been undertaken on devices which are available online for purchase at consumer sites such as Ebay and Amazon. This is to see if any improvements have been made in recent years as research and exploits have been made public within this area. Where possible conduct comparisons between models and firmwares. It is hoped to provide a methodology for researchers to test against or to learn from if new to DVR hacking. Results will be published by January 2021, if you have research and would like to contribute to the results listed please contact Chrissy Morgan.
Notable Mentions
Notable resources to mention of which this research would not have been possible is the work undertaken by Istvan Toth Github POC’s Tothi, 2017 who undertook research upon many CCTV DVR’s firmwares to discover multiple vulnerabilities. Vlad who has uncovered further zero days within devices (Habr, 2020) and CyberGibbons who has done extensive work over the years on DVR hacking and has produced great Hardware walkthroughs (CyberGibbons.com, 2020)
Overview
It has been observed that there are multiple vulnerabilities in CCTV DVR’s purchased by consumers and that these vulnerabilities are indeed exploited in the wild. These can either be directly accessed by viewers via websites such as Insecam (Information Security Magazine, 2020) or have been known to be actively exploited to be part of botnets (threatpost, 2020). Consumers may find it particularly hard to purchase a “secure device” currently for home or business use, as there is little to no indication without undertaking their own research if that device is insecure or not.
Services such as Which (Which, 2019) release reports advising consumers, but there are literally thousands of different types, models and brands on the open market, sold online at places such as Amazon which can make it difficult for consumers. In addition to this, many of these will use generic boards, firmwares and chips which may be vulnerable and there is not much way of checking prior to purchasing the item. Initiatives exists to improve IoT security with projects such as the OWASP IOT, (Code of Practices for Consumer IoT ) and now more recently European standardisation which provides a baseline requirement for the Internet of things (ETSI EN 303 645)
One piece of information which can be seen when purchasing an IoT device online is its release date or “Date First Available”. It is anticipated that newer devices would be sold with additional security features or updates included, but this is an assumption. It may take some time before manufacturers adopt the standards and best practice, and where international suppliers are concerned, these may not be adopted at all.
This is currently a small sample study, however a collection of sample firmwares has been collected for future research and comparison. As research continues, further products will be listed in the results tables and updated with findings. It is hoped that this research may give some pointers to others who are interested in IoT, as DVRs give a good surface area to explore. In addition to this there are walkthroughs documenting the steps taken to improve the researchers skills and provide repeatable steps.
Materials & Methods
The below lists the devices and the vulnerabilities which have been tested.
The known exploits have been mapped to the OWASP IOT top ten as part of this research and provide a framework to test against.
| OWASP IOT Top Ten | Vulnerability | Tools | Tutorial | Method |
|---|---|---|---|---|
| I7 Insecure Data Transfer and Storage | Insecure Transmission | Wireshark | Link | Network Testing |
| I1 Weak, Guessable, or Hardcoded Passwords | Insecure Guest Access URL | Browser | Link | Web App Manual Testing |
| I1 Weak, Guessable, or Hardcoded Passwords | Insecure Guest Access Login | Browser | Link | Web App Manual Testing |
| I3 Insecure Ecosystem Interfaces | Insecure blank password Access | Browser | Link | Web App Manual Testing |
| I5 Use of Insecure or Outdated Components | Directory Traversal | Burpsuite | (Link) | Web App Manual Testing |
| I1 Weak, Guessable, or Hardcoded Passwords | Root credentials | HashCat | Link | Web App Manual Testing |
| I9 Insecure Default Settings | Root Telnet | Telnet | Link | Network Testing |
| I1 Weak, Guessable, or Hardcoded Passwords | RTSP Camera access with credentials | RTSP | Link | Network Testing |
| I2 Insecure Network Services | Remote Back Door | Custom Script | Link | Network Testing |
| I10 Lack of Physical Hardening | Firware Extraction via SPI | CH341a & SPI Clip | Link | Hardware Pentesting |
| I10 Lack of Physical Hardening | U-Boot access via UART | FTDI & Minicom | Link | Hardware Pentesting |
Methodology
The below covers a high-level overview of the methodology undertaken to exploit the listed vulnerabilities. Further details on each vulnerability can be found within the Results and Observation section.
Reconnaissance & Investigation
Manufacturer manuals were search for online, these sometimes have default credentials or engineering details which are of use in terms of exploitation. Data Sheets were gathered for the model of the System On Chip and EEPROM. Schematics were obtained for the main DVR boards. From this it is possible to understand if there are any insecure default configurations and the hardware attack surface. Where the data sheets could not be obtained for that exact version, the nearest version was collected. It was possible to gather intelligence on the specific version by comparing and contrasting details between versions. Some documents of interest can be found within Resources/Schematics.
A review of existing research and CVE’s was undertaken and from this a list of vulnerabilities was achieved. This is tabled in the next section. The links to research reviewed is within the Notes area.
Notable resources to mention of which this research would not have been possible is the work undertaken by Istvan Toth Github POC’s (Tothi, 2017) who undertook research upon many CCTV DVR’s firmwares to discover multiple vulnerabilities.
Web App Manual Testing
A survey of the web application panel was undertaken. This can normally be found at http://192.168.1.10. Login prompts were manually tested for the insecure guest, default and admin access as well as the directory traversal CVE, which are all known issues. There is a wide range of default credentials listed online that could be used to brute force against a device.
Burpsuite and various browsers were used to test for issues, as the web panel behaved differently in each. For example, Microsoft Edge was highlighted to be too modern to use and the user would need to use an older version browser. Also, Internet explorer was advised to be the browser of choice due to the Active X plugin required for the web app to work appropriately. This plugin would be downloaded from an external source in China.
Please see Web Application Testing Walkthroughs for further details on how the web app manual testing was undertaken.
Network Testing
Network Testing was achieved by a combination of very basic methods. Running NMAP to note all the TCP/UDP ports which were open on the device. From this we could ascertain any vulnerable services and possible connection routes. From there on in, manual probing was undertaken, using Netcat and direct connections to the ports.
A custom script which had been made by Vladislav Yarmak was used against the device to see if it would enable the Telnet access. This script targets a possible backdoor/ “administration” port which then enables port 23 to be open. Not all devices will have port 23 open on them as default, so this script would need to be used to enable remote access.
RTSP is used within CCTV camera systems to enable the viewing of the device remotely, a direct connection to RTSP could be made with default / hardcoded credentials, soa script using cvlc within a ubuntu virtual machine was used to test the credentials and pull up the camera feed.
Please see Network Testing Walkthrough for further details on how network testing was undertaken.
Hardware Penetration Testing
By using the CH341A programmer it may be possible to make a direct SPI connection to the device to extract firmware. This is achieved by connecting the SPI adapter to the serial flash memory and reading the firmware directly from the device. In some circumstances there can be difficulties with this, such as an unsupported version or a clean read being obstructed by the MCU.
By using a FTDI USB to UART adapter it may be possible to interface with the U-Boot process and gain shell access. Many of the boards may place the UART connections in varying places, in addition to this the pins may be soldered so no connection is easily accessible. In this case de-soldering the chip from the board may be one method, or connecting jumper wires directly.
The correct connections were identified by obtaining schematics which document the similar generic board layouts, some of which use the same naming convention for the pin outs. By process of elimination reviewing many of the different board schematics it was possible to know which were the correct connections.
Please see Hardware Testing Walkthrough for further details on how the hardware testing was undertaken.
