Home

Awesome

Smart Home Threat Model <!-- omit in toc -->

Overview <!-- omit in toc -->

This project is a partial threat model for a fictional ACME smart home system consisting of a web and mobile UI, a cloud-deployed backend, local hub instances, and smart devices. The model consists of level 0, 1, and 2 data flow diagrams; STRIDE threat analysis; an attack tree; and risk analysis with DREAD and FAIR.

This is a project for GVSU's Information Security Principles course (CIS 615). See the assignment for more details.

Contents <!-- omit in toc -->

Threat Model

Data Flow Diagrams

Level 0

A level 0 data flow diagram provides context and shows the system at the highest possible level. The system is represented as a single process interacting with a few external entities. Here the ACME Smart Home System is a single process that communicates with the ACME Software Company, a user, and N smart devices.

DFD-0

Level 1

A level 1 data flow diagram shows the main processes, data stores, data flows, and trust boundaries of the system. It is more detailed than the level 0 diagram but still abstract enough to contain the entire system.

Here the smart home system is broken into its component parts. Primary trust boundaries are the cloud deployment and the user's LAN. The backend is divided into several processes, but the primary web backend is still complex enough to represent as a multi-process. The web and app UIs are displayed crossing the LAN boundary to indicate the different modes of operation. The devices are shown as processes as well as external entities to represent their dual cyber and physical nature. All processes are assumed to have some resources and logs; only very important ones are shown at this level.

DFD-1

Level 2

A level 2 data flow diagram goes into greater detail for a portion of the system.

Here the LAN and local hub are examined in more detail. The hub is divided into four processes:

  1. A web server to requests from the web and app UIs
  2. Internet communications to manage interactions with upstream command and control, OTA update, and analytics servers.
  3. Device communications to manage interactions with local smart devices
  4. A secure core to authenticate and isolate operations of mixed criticality

The model is populated with example smart devices to help elicit use cases, misuse cases, and threats. The wireless router is shown to remind the analyst of its presence on the LAN. Because all traffic is routed through it, it would be impractical to show all the connections, but it is important to consider its presence. As with the level 1 diagram, only resources and logs relevant to this level of abstraction are shown.

DFD-2-LAN

STRIDE Threats

STRIDE is a method that can be used to elicit threats in a system. A team can use basic STRIDE, STRIDE-per-element, or Microsoft's STRIDE-based game Escalation of Privilege. This list was created with basic STRIDE, is not exhaustive, and is not in order of risk or severity.

Spoofing

NumberOperational BaseIdentity SpoofedWith Respect To
S.1WANan ACME admin or developerbackend servers
S.2WANthe ACME command and control servera local hub
S.3WANthe ACME OTA update servera local hub
S.4WANa userthe web backend
S.5user's LANa userthe local hub
S.6user's LANthe local huba smart device
S.7user's LANa smart devicethe local hub

Tampering

NumberOperational BaseResource Tampered
T.1data centerweb resources
T.2data centeruser database
T.3local hub deviceweb resources
T.4local hub deviceconfig files

Repudiation

NumberOperational BaseActivity Repudiated
R.1ACME LANadmin operations on data center resources
R.2ACME LANdeveloper software updates and deployments
R.3data centerweb server interactions with account management
R.4data centerweb server interactions with command and control
R.5local hub deviceexternal (WAN, LAN) interactions with local hub
R.6local hub devicesystem interactions with secure core

Information Disclosure

NumberOperational BaseInformation DisclosedSource of Interception
I.1WANuser databasetransit between data center and ACME LAN
I.2data centeruser databaseon disk
I.3ACME LANACME admin credentialson disk
I.4user's LANuser credentialson disk
I.5WANdevice statusin transit between command and control and local hub
I.6user's LANdevice statusin transit between device and local hub
I.7physical proximity to smart devicedevice statusdirect observation of physical device

Denial of Service

NumberOperational BaseService DeniedOverloaded Resource
D.1WANuser access to web backendnetwork bandwidth
D.2WANuser access to web backendserver connections
D.3on-deviceloggingdisk usage
D.4physical proximity to WiFismart device access to local hubwireless bandwidth
D.5physical proximity to smart devicesmart->physical device controlelectro-mechanical interface

Escalation of Privilege

NumberOperational BasePrivilege GainedEscalation Mechanism
E.1WANshell on web servervulnerability in web server
E.2WANadmin access to data center serverscompromised ACME credentials
E.3WANuser access to web backendcompromised user credentials
E.4user privilegeroot privilegevulnerability in privileged program
E.5user privilegeroot privilegeinsecure configuration
E.6local hub deviceaccess to secure corevulnerability in application

Attack Tree: Confidentiality Compromise

An attack tree graphically represents the means an attacker could use to achieve an objective.

Here an attack on information confidentiality of device status is analyzed. This threat corresponds to threats I.5, I.6, and I.7 in the STRIDE analysis.

attack-tree

DREAD and FAIR

DREAD and FAIR are two methods of quantifying risk. DREAD averages the scores rated 0-10 for damage, reproducibility, exploitability, affected users, and discoverability. FAIR, or factor analysis of information risk, takes a more methodical approach. FAIR is a complex method that is caricatured here.

In order to calculate risk, one must consider specific vulnerabilities that enable threats to be realized. To build on the attack tree example, hypothetical vulnerabilities leading to a complete device status disclosure attack chain will be analyzed.

One way of capitalizing on smart home system vulnerabilities is to read and manipulate device status in order to enable theft. Though this example requires physical presence in order to be executed, many remote attacks are conceivable. A complete threat model would consider those as well.

Three Risks Analyzed with DREAD

Damage, affected users, and discoverability are fairly clear terms. Reproducibility and exploitability are a bit more nebulous and overlapping. Here to be reproducible means able to be reliably triggered via an automated attack, and to be exploitable means able to be triggered by an attacker of low skill level.

Vulnerability 1: Geographic Discovery

Vulnerability: conspicuous installation enables geographic discoverablity of hub instance.

Description: driving through a neighborhood, attackers can identify homes equipped with the ACME smart home system due to visible ACME smart devices on the home exterior and window stickers advertising the ACME security system. Because the attackers know the system is vulnerable, such evidence that the system is installed turns from a security asset to a liability.

CategoryRating (0-10)Comments
Damage0Lacking known vulnerabilities, is actually a feature
Reproducibility3Reliable but not automatable
Exploitability10No skill required
Affected Users4Slightly less than half of installations externally visible
Discoverability9Clearly visible for any installation with external devices or a sticker
Risk5.2Mitigation: maintain reputation so it's a feature, not a bug

Vulnerability 2: Router Password Crack

Vulnerability: brute forcible password on WiFi router allows access to LAN.

Description: to gain a foothold on the LAN, the simplest way is to guess the WiFi router's password. Many users choose names of their pets, parts of their address, or simple phrases. Brute force attacks based on contextual information could be quite successful.

CategoryRating (0-10)Comments
Damage9Even without an attack on the ACME system, it is bad to have attackers on your LAN
Reproducibility8Semi-reliable, fully automatable
Exploitability8No skill required
Affected Users6Many users use poor passwords
Discoverability1No way to discover the vulnerability without running the attack
Risk6.8Mitigations: train users; display strong warning if on LAN with weak password

Vulnerability 3: Device Spoofing

Vulnerability: forced fallback to unverified smart devices allows device spoofing.

Description: one can imagine developers designing device authentication into the ACME smart home system, and having marketing push for a fallback so that all past smart devices can be grandfathered in to the new platform. This vulnerability is a flaw in the device setup protocol that allows devices to force the unauthenticated device mode. It also requires the capability to device addition without user interaction.

CategoryRating (0-10)Comments
Damage2Without other known vulnerabilities, does not do much harm
Reproducibility10Fully reliable and automatable
Exploitability5Requires custom but uncomplicated software to conduct the attack
Affected Users5Only affects users with insecure LANs
Discoverability10Everywhere, because it is a feature
Risk6.4Mitigation: require authenticated user involvement during device setup

Two Risks Analyzed with FAIR

Factor analysis of information risk has here been simplified into a bottom-up tree with severity scores ranging form 0-10 in order to create a simple comparison to the DREAD scores. Regardless of wording of the element, a higher score is a worse security outcome.

Vulnerability 4: Insecure MQTT Server

Vulnerability: buffer overflow in MQTT server over-exposes data.

Description: Many IoT devices and hubs communicate using MQTT. This hypothetical vulnerability is a buffer overflow in the subscription expression parser of the hub device's MQTT server component. The overflow allows a user to subvert ACLs and access all device data. (It is possible to achieve a similar effect trivially if ACLs are not configured or are misconfigured.) For this example, assume the MQTT server is written in C.

fair-4-mqtt

CategoryRating (0-10)Comments
Risk4.5Mitigations: secure coding practices; use a memory-safe language

Vulnerability 5: Device Manipulation

Vulnerability: poorly configured hub rules allow indirect manipulation of other devices.

Description: One purpose of smart home devices is to create emergent behavior. A user could create a rule saying that the front door should unlock 30 seconds after the garage is opened, or the security alarm should be disabled when more than one person is home. At this point in the attack chain we already have device information and spoofing capabilities. This vulnerability is an insecure rule configuration that allows the state of unauthenticated (spoofable) devices to influence the behavior of real devices.

fair-5-rules

CategoryRating (0-10)Comments
Risk3Mitigation: disallow rules that take input from unauthenticated devices

Summary

This partial threat model has analyzed a fictional ACME smart home system through the use of data flow diagrams, STRIDE analysis, attack trees, and risk analysis.

The vulnerabilities analyzed take the attacker through all stages of target acquisition, perimeter exploitation, privilege escalation, and objective completion. While none of the vulnerabilities were particularly severe on their own, when taken together they allow an attacker to compromise the fundamental confidentiality and integrity of the system. In this case, the attacker would be able to discern and affect the state of smart devices in the home, enabling a crime such as theft.

License

This project is licensed under the Creative Commons Attribution 4.0 International license. The text is copyrighted by Kevin Kredit, but is reusable provided credit and license notice. See the license text for more details.