At this stage, we have drawn out the data flow of a DVR system and identified entry points. We now have to identify the risks of each entry point as it relates to the user, the network, and the application as well, as the vendors who wrote the application code. From an attacker perspective, we want to identify threats which affect the network, applications, and hosts that may be exploitable and cause the following impact:
- Affect a large number of users utilizing this specific DVR system
- Compromise the vendor's infrastructure to induce mass exploitation
- Compromise the DVR to pose a privacy risk to users
- Compromise the DVR to pose a safety risk to the DVR owner
To help with identifying threats and categorizing them, let's apply the STRIDE model to our DVR IoT system. We will be adding a couple of threat types in lieu of IoT-specific issues in the following table. This table is by no means exhaustive but should help with ideas when thinking about threats that may affect the holistic DVR environment:
|
Threat types |
Analysis |
|
Spoofing identity |
Examine the system for threats related to the spoofing DVR identity and the ability for an attacker to overcome automated trust relationships between devices. Look for entry points that allow devices or users to manipulate trust relationships within DVR provisioning processes. Analyze authentication and authorization functions with the DVR's application interfaces. Review the DVR's app communication for the ability to forge requests. |
|
Tampering with data |
Review the DVR's messaging communication between applications and devices. Identify points in the DVR that provide an opportunity to tamper with the data at points of collection, processing, transport, and storage of data. Attempt to tamper with firmware and mobile app configurations to perform unauthorized actions. |
|
Repudiation |
Identify attack entry points that allow illegal operations to take place without logging abilities. Disable web and mobile app tracing functionalities. |
|
Information disclosure |
Fuzz application parameters to influence application error disclosures Identify all clear text communications. Review DVR API communication HTTP response headers for versioning information. Identify all API endpoints and application backend technologies utilized. Review application data storage for unintended data leakage within clear text files. |
|
Denial of service |
Perform functions such as forgot password to identify whether locking out users is possible. Test for account lockout policies within each DVR application interface. Examine the throughput of the DVRs network services to understand how attacks may withstand relevant DoS attacks. Examine the messaging structures (for example, data buses), data structures, improper use of variables and APIs used within the DVR's components and determine whether there are vulnerabilities that would allow a malicious camera to drown out the transmissions of a legitimate camera or compatible DVR device. |
|
Privileged elevation |
Examine the administration capabilities the DVR provides. Create lower application users and test for administrative access. Identify instances where there are weaknesses in the ability to segregate administrative functions from user-level functions within the DVR's application and operating system. Identify weaknesses in the authentication methods employed by DVR nodes in order to design appropriate authentication controls into the system. |
|
Physical security bypass |
Examine the physical protection mechanisms offered by the DVR and its cameras to identify weaknesses that may allow administrative console access. |
|
Supply chain issues |
Understand the various technological components and their origins that make up the DVR system (for example, ODMs, hardware manufacturers, OEMs, and so on). Keep track of vulnerabilities related to any of the technology layers related to the DVR's hardware and software components. |
Alternatively, we can simply list out threats from a high-level and later in the chapter, we will drill down to threats for each component. Some of the threats may be unknown or completely theoretical since we may not have all the insights but it's important to brainstorm these ideas. To get the most out of identifying threats, pair up with a partner or make it a group exercise with others who are looking at attacking your specific IoT system of interest. The following are examples of high-level threats to our DVR system that an attacker could perform:
- Remotely take over the DVR system
- Remotely view camera feeds (spy) without authorization
- Turn off camera recording playback features
- Track individuals
- Break into surrounding areas based upon intelligence gathering
- Install malware on the DVR
- Gain physical access and sabotage recordings
- Overload the DVR with requests to prevent usage
- Eavesdrop on DVR communications