Hidden and Lost Control: on Security Design Risks in IoT User-Facing Matter Controller

Hidden and Lost Control: on Security Design Risks in IoT User-Facing Matter Controller

Speakers: Haoqiang Wang, Yiwei Fang

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=C0M_JeCz9s8

Overview

The proliferation of Internet of Things (IoT) devices has led to a fragmented and complex ecosystem, with numerous vendors, proprietary protocols, and disparate companion applications. To address this challenge, the Connectivity Standards Alliance (CSA) introduced Matter, an open-source, universal application-layer connectivity standard designed to unify the IoT landscape. Since its deployment in late 2022, major IoT players like Google, Apple, and SmartThings have integrated Matter support into their devices, apps, and development frameworks, leading to its rapid adoption worldwide. This talk, presented by Ichin Leo (Yiwei Fang) from Indiana University, delves into the security implications of this integration, specifically focusing on how vendors implement User-Facing Matter Control Capabilities and Interfaces (UMCCI) within their mobile applications.

The research uncovers significant security design flaws in how real-world IoT vendors integrate the Matter standard, leading to vulnerabilities that allow unauthorized control and hidden access to Matter devices. These flaws can enable malicious actors to maintain covert control over devices, downgrade legitimate owners' privileges, and circumvent expected security mechanisms. The talk highlights the critical need for robust security design in UMCCI and proposes a novel, automated detection tool, UMCCI Checker, to identify such vulnerabilities. This work is crucial for both vendors and the Matter standard itself, pushing for a more secure and trustworthy IoT ecosystem as Matter continues its global expansion.

Background

▶ Watch: Introduction to Matter Protocol and its purpose (0:00)

The current IoT landscape is characterized by a high degree of fragmentation, with various vendors developing their own ecosystems, often incompatible with one another. Users typically manage devices from different brands using separate applications, leading to a cumbersome and inconsistent experience. Matter was conceived to overcome this heterogeneity, providing a unified, open-source application layer protocol that allows devices from different manufacturers to communicate seamlessly. Its core objective is to simplify device setup, enhance interoperability, and improve user experience across the smart home environment.

To understand Matter's operational framework, it's essential to grasp its fundamental data structures. A fabric in Matter represents a virtual network, encompassing multiple Matter nodes. These nodes can function as either Matter controllers (e.g., smart home hubs, mobile apps like Google Home or Apple Home) or Matter devices (e.g., smart plugs, lights). A unique characteristic of Matter is that a single Matter node can belong to multiple fabrics simultaneously, allowing a device to be controlled by different vendor ecosystems. Each node possesses a node ID and exposes clusters, which are collections of functionalities or attributes (e.g., on/off state for a light, temperature reading for a sensor). Fabrics, on the other hand, are identified by a fabric ID, vendor ID, a human-readable label, and maintain an Access Control List (ACL) that dictates which controllers have permissions over which devices.

The researchers analyzed Matter's real-world deployment model, categorizing it into three distinct layers:

1. Matter Open Source Layer: This foundational layer includes the device firmware and the Matter SDK (Software Development Kit), often referred to as the chip SDK. It provides the primitive capabilities for device communication and control.
2. Vendors Application Layer: Built upon the open-source layer, this is where vendors develop their Matter controllers, integrating the Matter SDK and utilizing its APIs to manage and control Matter devices. A Matter controller here is a logical concept, potentially referring to mobile apps or IoT hubs.
3. Cloud Layer: This layer typically handles remote access, data storage, and additional services, often interacting with the vendor's application layer.

For secure integration, the researchers propose three critical security requirements for UMCCI:

1. Visibility: Users must be able to view comprehensive access control information, including all connected Matter controllers, Matter nodes, and their associated access control lists.
2. Trustworthiness: The displayed access control information must be accurate and verifiable, ensuring users are not misled by false or incomplete data.
3. Updatability: Users must have the capability to modify access control information, such as establishing or revoking control for Matter devices.

The challenge lies in the fact that the design and development of UMCCI are left to individual vendors, creating a potential "error space" where security flaws can easily be introduced.

Key Findings

▶ Watch: Three critical security requirements for Matter integration (4:10)

The central discovery of this research is the widespread presence of User-Facing Matter Control Capabilities and Interfaces (UMCCI) flaws across popular IoT vendor applications. UMCCI refers to the graphical user interfaces (GUIs) or voice interfaces within IoT mobile apps that enable users to view, use, or control Matter devices. The study found that apps from major vendors, including Apple Home, SmartThings, Google Home, and Tuya, are all problematic, failing to meet the proposed security requirements for visibility, trustworthiness, and updatability.

Specifically, the research identified six distinct types of UMCCI flaws. These flaws collectively enable a range of malicious activities, such as:

• Authorized control over hidden Matter controllers: Malicious users can establish control over devices in a way that is invisible to the legitimate device owner.
• Covert control channels: Attackers can maintain persistent, undetected access to devices.
• Downgrading or removal of IoT owners' privileges: Malicious actors can reduce the legitimate owner's control or even completely remove their access to devices.

The researchers investigated 11 different vendors that have integrated the Matter standard and found that eight of them were problematic, demonstrating the pervasive nature of these design vulnerabilities. These findings were substantiated through proof-of-concept (PoC) attacks on real devices, confirming the practicality and severity of the UMCCI flaws. The research highlights that the root causes of these security risks stem from both inadequate vendor integration designs and, in some cases, ambiguities or insufficient guidance within the Matter standard itself regarding secure UMCCI implementation.

Technical Deep Dive

▶ Watch: Demonstration of Flaw Type 1: Hidden matter controller (6:07)

The core of the security risks identified lies in the discrepancies between the actual state of Matter device control and what is presented to the user through UMCCI. The researchers provide a detailed example of "Flaw Type 1" to illustrate how a hidden controller can be established and maintained. This flaw leverages the multi-fabric nature of Matter and the ability of a controller to manipulate fabric labels.

Consider a scenario involving a Matter plug that belongs to two fabrics: one controlled by a developer tool called chip-tool (an open-source Matter controller included in the Matter project) and another controlled by the SmartThings app. Initially, within the chip-tool command-line interface, a user can list all fabrics associated with the device, clearly seeing both the chip-tool fabric (with its specific vendor ID and label) and the SmartThings fabric. However, when viewing the device's controllers within the SmartThings UMCCI, only the chip-tool fabric (identified by its vendor ID, e.g., FFF1) might be visible.

The attack unfolds when a malicious actor, using chip-tool, executes a command to update the fabric label of their chip-tool controlled fabric. For instance, they might change its label to "SmartThings" – a string that matches the name of the legitimate vendor's application. The critical vulnerability arises because the SmartThings UMCCI, instead of displaying the chip-tool fabric with its new, deceptive label, completely hides it. This behavior suggests that the SmartThings app's UMCCI is either filtering out or misinterpreting fabric information based on label matching, leading to a critical lack of transparency.

This "Flaw Type 1" has severe implications, particularly in shared home environments such as Airbnb. If a host shares a Matter device with a guest, and that guest is malicious, they can use chip-tool to establish covert control over the device. By manipulating the fabric label, the guest can make their controller invisible within the host's SmartThings app. Even after the guest leaves, the host remains unaware of the hidden controller and, crucially, cannot remove it through their legitimate UMCCI. This allows the malicious guest to retain persistent, unauthorized control over the device.

The other five flaw types, while not detailed in the transcript, likely exploit similar discrepancies in UMCCI design, potentially involving:

• Partial lists of controllers: Some UMCCI might only show a subset of active controllers, omitting others.
• Unverified controller information: The information presented about controllers might not be verified against the device's actual state, allowing attackers to spoof or misrepresent control.
• Privilege escalation/downgrade vulnerabilities: Design flaws could allow unauthorized users to gain higher privileges or reduce the legitimate owner's control.
• Race conditions or timing attacks: Exploiting how UMCCI updates or processes control changes.
• Improper handling of Matter ACLs: UMCCI might fail to accurately reflect or enforce the device's access control lists.

The root causes of these issues are multifaceted. On the one hand, vendors are responsible for designing and implementing secure UMCCI that accurately reflect the Matter device's state and provide transparent control options. Their failure to do so, as seen in the examples, leads to these vulnerabilities. On the other hand, the Matter standard itself might not provide sufficiently prescriptive guidelines or robust mechanisms to prevent such misimplementations, leaving too much discretion to individual vendors and creating an "error space" for insecure designs. The research emphasizes that a combination of stricter vendor adherence to security principles and potentially clearer definitions within the Matter standard is necessary to mitigate these risks.

Demo / Proof of Concept

▶ Watch: Practical attack scenario: Hidden control in shared homes (7:10)

The demonstration of "Flaw Type 1" involved a practical attack scenario using the chip-tool and the SmartThings mobile application. The researchers first established a Matter plug that was simultaneously connected to two distinct fabrics: one managed by the chip-tool (acting as a developer controller) and another by the SmartThings app (representing a legitimate user controller). Using chip-tool commands, they verified the presence of both fabrics, each with its unique vendor ID and label. Crucially, the SmartThings UMCCI initially displayed one of these fabrics (e.g., FFF1, corresponding to chip-tool). The core of the demonstration then involved using chip-tool to modify the label of its own fabric to "SmartThings." Following this change, the SmartThings UMCCI, instead of updating to show a second "SmartThings" fabric or correctly identifying the chip-tool fabric with its new label, completely failed to display it. This stark visual absence in the legitimate user interface served as clear proof that the controller had become hidden, yet remained active and functional.

To address the challenge of detecting such UMCCI flaws at scale, the researchers developed an automated tool called UMCCI Checker. This tool is designed to systematically analyze IoT applications for these vulnerabilities without requiring the purchase or configuration of real IoT devices. Instead, it leverages a virtual Matter device environment that can simulate a Matter device for pairing and interaction with various IoT apps.

The workflow of the UMCCI Checker comprises five key components:

1. Virtual Matter Device Environment: This component initializes a virtual Matter device capable of generating pairing codes and interacting with real mobile applications.
2. Automatic Device Pairing: The checker automates the process of pairing the virtual device with the target IoT app. This involves extracting the pairing code from the virtual device, initializing chip-tool to pair with it, and then installing and launching the target mobile app (e.g., SmartThings).
3. Efficient Automatic UI Exploration: After launching the app and completing registration, the checker extracts all UI elements from the app's interface. It employs an LM-assisted UI analysis approach, where an LM agent (likely a Large Language Model agent) helps interpret the semantics of UI pages. This allows the checker to identify relevant UMCCI pages – those similar to "connected services" or "Matter controllers" – which are critical for displaying access control information.
4. Flow Analysis and Reporting: Once a comprehensive set of UMCCI pages is collected, the checker runs multiple test iterations. In these iterations, the chip-tool connected to the virtual device is instructed to change its fabric label to arbitrary strings, including those matching common vendor names. The checker then observes the UMCCI pages. If a fabric that should be displayed (based on the chip-tool's actual control) is not shown when its label is changed to match a vendor name, it indicates the presence of a "Flaw Type 1" vulnerability.
5. LM-based Matter Agent: This agent plays a crucial role in interpreting UI elements and guiding the UI exploration and pairing processes. It understands the context of Matter-related UI components, enabling the checker to intelligently navigate applications and identify relevant screens for analysis.

By simulating the device and automating UI interaction and analysis, the UMCCI Checker provides an efficient and scalable method for identifying hidden controller flaws and other UMCCI vulnerabilities, significantly reducing the manual effort required for security auditing.

Defensive Implications

▶ Watch: UMCI Checker workflow with virtual device and LM agent (9:00)

The findings of this research carry significant implications for various stakeholders within the IoT ecosystem, from device manufacturers and app developers to standard bodies and end-users. Addressing the identified UMCCI flaws requires a multi-pronged defensive strategy.

For IoT Vendors and App Developers:

• Re-evaluate UMCCI Design: Vendors must critically review and redesign their User-Facing Matter Control Capabilities and Interfaces to ensure they accurately reflect the true state of Matter device control. This includes displaying all active fabrics and controllers, regardless of their labels or vendor affiliations.
• Adhere to Security Requirements: Strict adherence to the proposed security requirements for UMCCI is paramount:
• Full Visibility: All Matter controllers, nodes, and their associated Access Control Lists (ACLs) must be transparently displayed to the user. No controller should be able to hide its presence.
• Trustworthy Information: The information presented in the UMCCI must be verified against the device's actual state, preventing spoofing or misrepresentation.
• Robust Updatability: Users must have unambiguous and effective mechanisms to revoke control from any controller, including those that might attempt to hide.
• Implement Strong Input Validation and Sanitization: To prevent attacks like the "Flaw Type 1" where manipulating a fabric label can hide a controller, UMCCI should not rely solely on string matching for display logic. Instead, they should use unique identifiers (like fabric IDs or vendor IDs) for critical display and control decisions.
• Regular Security Audits: Vendors should conduct frequent and thorough security audits of their Matter integrations, ideally using automated tools like the UMCCI Checker, to proactively identify and rectify design flaws. The positive response from vendors to the researchers' disclosures indicates a willingness to patch these issues.

For the Matter Standard and Connectivity Standards Alliance (CSA):

• Enhanced Security Guidelines: The Matter standard should provide more prescriptive and robust guidelines for the secure design and implementation of UMCCI. This could include mandatory display requirements for all fabrics, explicit rules on how to handle conflicting or ambiguous fabric metadata, and best practices for revoking control.
• Standardized API for UMCCI Information: The standard could define more explicit APIs or data structures for controllers to query and display all relevant security-sensitive information (e.g., all active fabrics, their true identities, and associated permissions) in a way that is difficult for malicious actors to circumvent.
• Tooling Support: The CSA could support the development of standardized security testing tools, similar to the UMCCI Checker, to help vendors validate their Matter integrations against common vulnerabilities.
• Clarification on Shared Control: Given the multi-fabric nature of Matter, the standard should provide clearer guidance on managing shared device control, particularly in scenarios where multiple users or applications might have overlapping permissions.

For End-Users:

• Be Cautious in Shared Environments: Users should exercise extreme caution when sharing Matter devices in environments like Airbnb or with guests. The potential for hidden controllers means that simply revoking access through a single app might not be sufficient.
• Monitor Device Behavior: Users should remain vigilant for unusual device behavior that might indicate unauthorized control.
• Demand Transparency: Users should advocate for greater transparency and control within their IoT applications, pushing vendors to provide comprehensive and trustworthy information about who and what is controlling their smart devices.
• Keep Apps Updated: Regularly update IoT companion apps to ensure they include the latest security patches from vendors.

By collectively addressing these defensive implications, the IoT ecosystem can move towards a more secure and transparent future for Matter-enabled devices, protecting user privacy and device integrity.

Key Takeaways

• Matter's promise of interoperability is undermined by insecure UMCCI implementations: While Matter aims to unify IoT, critical security flaws in User-Facing Matter Control Capabilities and Interfaces (UMCCI) developed by vendors introduce significant risks.
• Widespread UMCCI flaws enable hidden control and privilege manipulation: The research identified six types of flaws across eight out of eleven popular vendors, allowing malicious actors to establish covert control, hide controllers from legitimate owners, and downgrade user privileges.
• The "Flaw Type 1" demonstrates how fabric label manipulation creates hidden controllers: A key vulnerability, exemplified by chip-tool attacks, shows how changing a fabric's label can cause it to disappear from the legitimate owner's UMCCI, enabling persistent, undetected control.
• Automated detection with UMCCI Checker is crucial for scalable security auditing: The novel UMCCI Checker tool, leveraging a virtual Matter device environment and LM-assisted UI analysis, provides an efficient way to detect these flaws without needing physical devices.
• Vendors must prioritize transparent and trustworthy UMCCI design: IoT vendors need to re-evaluate their UMCCI to ensure full visibility of all controllers, trustworthy access control information, and robust mechanisms for users to revoke access.
• The Matter standard needs stronger security guidelines for UMCCI implementation: The Connectivity Standards Alliance should consider providing more prescriptive guidance and potentially standardized APIs to prevent insecure UMCCI designs and enforce transparent control over Matter devices.

About the Speaker(s)

The talk was presented by Ichin Leo, a PhD student at Indiana University. The research was conducted by Haoqiang Wang and Yiwei Fang. While specific titles and companies beyond "PhD student at Indiana University" for Ichin Leo (likely Yiwei Fang) are not detailed in the transcript or metadata provided for the speakers, their work demonstrates a deep technical understanding of IoT security, the Matter protocol, and practical vulnerability research. Their contributions highlight the critical role of academic research in uncovering and addressing real-world security challenges in emerging technologies.