I Just Wanted to Charge the Car

I Just Wanted to Charge the Car

Speakers: Richo Butts

Conference: ShmooCon

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

Overview

In "I Just Wanted to Charge the Car," Richo Butts, a seasoned security professional and motorsport enthusiast, takes the ShmooCon audience on a compelling journey through the world of IoT security vulnerabilities discovered during a personal quest for energy independence. The talk details his experience attempting to optimize his home's solar power system to automatically charge his electric vehicle (EV), only to uncover a series of "aggressively clown shoes" security flaws in the underlying smart home infrastructure provided by Franklin, a company specializing in whole-house battery systems.

Butts' presentation is a candid exploration of the challenges inherent in modern IoT ecosystems, where convenience often trumps robust security design. He meticulously details the reverse engineering process, from dissecting Android APKs to uncovering deeply insecure communication protocols, culminating in a critical examination of vendor practices and the difficult path to responsible disclosure. This talk is not merely a technical exposé but a cautionary tale, highlighting how even seemingly innocuous smart home devices can harbor significant vulnerabilities that could be exploited for purposes far beyond a homeowner's energy optimization goals.

The talk resonates deeply with anyone concerned about the proliferation of connected devices and the often-negligent security postures of their manufacturers. Butts' personal motivation—to drive for free while minimizing his carbon footprint—provides a relatable entry point into complex technical issues, making the security implications of his findings accessible and impactful. It underscores the critical need for fundamental security engineering, proper credential management, and robust authorization mechanisms in an increasingly interconnected world, particularly in systems that manage significant power flows within a home.

Background

▶ Watch: Introduction and talk overview (0:00)

The genesis of this security deep dive stemmed from Richo Butts' personal objective to create a carbon-neutral home and minimize energy costs. After installing solar panels and acquiring an electric vehicle, he sought to maximize the efficiency of his energy system. His goal was straightforward: when his home's Franklin whole-house battery was fully charged by solar power, instead of selling surplus energy back to the grid for minimal returns, he wanted to automatically divert that power to charge his EV. This vision promised both environmental benefits and the "smug satisfaction" of driving for free.

The core problem, as Butts initially framed it, involved two primary technical hurdles. First, he needed to ascertain the real-time power state of his house – specifically, the charge level of the Franklin batteries and the energy flow to or from the grid. Second, he needed to programmatically control the Franklin system's "smart relay," a robust switch capable of handling 200 amps at 200 volts, to direct power to his car charger. Drawing inspiration from a quote attributed to Dominic Stupid, "once you can blink an LED, the rest is just a matter of typing on the keyboard," Butts assumed that once these two fundamental capabilities were achieved, the rest would be "easy peasy. Computer hacking stuff."

However, his journey quickly revealed a landscape riddled with security oversights. The Franklin system, while notionally capable of providing the necessary data and control via its mobile application, lacked any readily available public API or integration points for third-party automation. This forced Butts into a reverse engineering effort, a task he hadn't undertaken in years, highlighting the common "ugh, the general nature of vendors" that often leaves users with closed, unmodifiable systems. This initial lack of transparency and control set the stage for the cascade of vulnerabilities he would soon uncover, exposing the inherent risks when critical infrastructure is designed without security-by-design principles.

Key Findings

▶ Watch: Franklin whole-house battery system introduced (3:20)

Richo Butts' investigation into the Franklin smart home system uncovered a series of significant security flaws, painting a stark picture of neglected security engineering in critical IoT infrastructure.

1. Insecure API Discovery: Butts' initial attempt to reverse engineer the Android application led to the accidental discovery of a Swagger API endpoint. While the documentation was in Chinese and often incorrect, its mere public exposure without authentication provided a significant foothold for understanding the system's communication. This suggested a fundamental lack of awareness regarding API security best practices.

1. Hardcoded and Deterministic Credentials: A critical vulnerability was the discovery of hardcoded AWS credentials within the Android application. These credentials granted access to the system's MQTT message broker. Furthermore, the authentication tokens issued by the system were found to be deterministic and non-revocable, meaning logging in multiple times with the same username/password yielded the same token. This strongly suggested that tokens were simple digests of user IDs rather than securely generated, time-limited, and revocable session tokens, posing a severe risk of unauthorized, persistent access.

1. Lack of Authorization and Topic Isolation in MQTT: The most alarming finding was the complete absence of authorization and privilege separation on the MQTT broker. By subscribing to the wildcard topic #, Butts was able to observe every single message flowing through the broker for all Franklin customers. This included sensitive operational data from other users' gateways and the ability to potentially send control commands to any connected device without any permission checks. This "everything just sits on this one message broker" architecture represented a catastrophic security failure.

1. Vendor Disclosure Challenges: The process of reporting these vulnerabilities to Franklin was fraught with difficulties. Butts encountered significant hurdles in finding a security contact, resorting to "messaging random engineers on LinkedIn." This lack of a clear and accessible disclosure channel is a common industry problem that delays remediation and frustrates researchers.

1. Partial Remediation and Persistent Vulnerabilities: Franklin eventually released a patch. The patch addressed the MQTT interaction from the mobile application side by introducing an HTTP endpoint that now proxies messages to their internal broker, enforcing authorization checks on topic publishing. However, Butts posits that the gateway device itself likely still operates on an internally insecure MQTT broker without isolation. This suggests that while the client-side attack surface was reduced, a determined attacker with physical access or a code execution vulnerability on the gateway could still exploit the underlying insecure message bus.

These findings collectively illustrate a profound lack of security maturity in the development and deployment of the Franklin smart home system, highlighting basic failures in credential management, access control, and network segmentation.

Technical Deep Dive

▶ Watch: Defining core problems: power state, relay control (4:00)

Butts' technical journey began with the familiar approach of reverse engineering the Android application to understand how it communicated with the Franklin system. He initially attempted to use jd-gui, a tool he remembered from previous endeavors, but quickly found it lacking. Instead, he discovered and utilized jdx, which he praised for its automated DEX to JAR conversion and improved functionality. He expressed a retrospective wish to have invested more time in Binary Ninja (Binja), suggesting it might have been a more efficient tool for static analysis had he committed to it from the start.

His initial static analysis of the APK quickly revealed the involvement of a Chinese consulting company, which, as he noted, "set my expectations for everything else I was about to interact with," and those expectations were "about right." A casual grep for interesting strings within the decompiled code yielded numerous API endpoints and, surprisingly, the accidental discovery of a publicly exposed Swagger API endpoint. While the documentation served was in Chinese and proved largely inaccurate in practice, it provided structural hints about the API.

Frustrated by the unreliable documentation, Butts pivoted to dynamic analysis using an HTTP proxy. He employed HTTP Toolkit, noting its ease of use and improved experience compared to older tools, reflecting the advancements in the security tooling landscape. This allowed him to intercept and analyze the actual API requests made by the mobile app, leading to the development of a Rust wrapper for the Franklin API, which he subsequently open-sourced.

The real technical breakthrough occurred when Butts tried to control the "smart relay." Intercepting HTTP traffic while toggling the switch in the app yielded no direct control request. Instead, he observed an "operation log" or metrics request. This anomaly, combined with earlier static analysis hints about a data area 311 beam and references to sw1, 2, and 3 (likely referring to switches), led him to suspect an alternative communication mechanism. This suspicion was confirmed with the discovery of MQTT (Message Queuing Telemetry Transport), a lightweight message broker protocol often used in IoT contexts.

Further reverse engineering focused on the MQTT implementation within the app. He found that the app retrieved credentials for the AWS-hosted MQTT broker through an API call: GET /v3/device/mqtt/getCredentials. Critically, this API call returned hardcoded AWS credentials without any variables, meaning a single set of credentials was being distributed. Even more concerning, the authentication tokens received were deterministic, implying they were not revocable and potentially derived directly from a user identifier, compromising session security.

With the MQTT credentials, Butts was able to connect to the broker. He identified various MQTT topic names, structured as s2c (sensor-to-cloud) for data flowing from the gateway to the infrastructure, and c2s (cloud-to-sensor) for commands sent to the gateway. A key feature of MQTT is the ability to subscribe to a wildcard topic, #, which receives all messages on the bus. Upon doing so, Butts made his "second exciting discovery": the entire system operated on a single message broker with no authorization or separation of privilege. He observed messages from other users' devices, confirming a global exposure of sensitive operational data and control capabilities.

The message format for controlling the relay was then deciphered. It involved publishing to a c2s topic with a JSON payload containing specific fields: command type 311 (corresponding to the 311 beam he found earlier), the equipment number (serial number of his gateway), a length crc, and a data area which was a JSON-serialized data structure. This structure, when correctly formatted and published to the appropriate topic, could trigger the physical relay.

The vendor's patch, implemented after disclosure, modified the client-side interaction. Instead of the mobile app directly connecting to the MQTT broker with insecure credentials, it now interacts with an HTTP endpoint on their backend. This backend then publishes messages to the MQTT broker on behalf of the client, presumably with proper authorization checks to ensure a user can only publish to topics related to their own devices. Butts noted the irony that Cognito, an AWS service specifically designed for user authentication and authorization, could have provided this functionality from the outset, highlighting a missed opportunity for robust security. Despite the client-side fix, Butts suspects the gateway device itself still uses an insecure internal MQTT broker, leaving a potential attack vector for those with deeper access to the hardware.

Demo / Proof of Concept

▶ Watch: Vendor code quality and hardcoded demo credentials (5:30)

While Richo Butts mentioned that the video of the physical relay "clacking" when he successfully controlled it was "fucking gone," he confirmed that the proof of concept was fully functional and integrated. He described doing the "Kermit thing" — typing on the computer "a whole bunch" — and writing Python wrappers to interact with the system using the discovered MQTT protocol.

Crucially, he integrated his working code into Home Assistant, an open-source home automation platform. This integration allowed him to achieve his original goal: automatically diverting solar power from his Franklin battery system to charge his electric car when the house batteries were full. This demonstrated not only the feasibility of exploiting the vulnerabilities but also the practical application of the research for home automation purposes.

Furthermore, Butts made his initial Rust wrapper for the API open source, providing a starting point for others who might own these devices and wish to experiment or conduct further research. He clarified that while the authentication part of the Rust wrapper might be broken due to the vendor's patch, it would be "really easy to fix," indicating the core API interaction logic remains valuable. The absence of a live, in-talk demonstration was offset by the clear explanation of the working code and its integration into a functional home automation system.

Defensive Implications

▶ Watch: Discovery of the Swagger API specification (6:30)

The findings from "I Just Wanted to Charge the Car" offer critical lessons for both IoT manufacturers and consumers regarding the fundamental principles of secure system design and operation.

1. Prioritize Security Engineering from Inception: The most glaring implication is the absolute necessity for security by design. Butts explicitly stated that "the most cursory glance at this would have turned up all of these problems." This was not a sophisticated, hidden bug but "aggressively clown shoes" security. Manufacturers must integrate security experts into the entire development lifecycle, rather than treating security as an afterthought or a feature to be bolted on.

1. Robust Credential Management: Hardcoding sensitive credentials, especially for cloud services like AWS, is an egregious security failure. Credentials must be dynamically provisioned, unique per device/user, stored securely, and rotated regularly. Authentication tokens should be generated securely, be time-limited, and revocable. The use of services like AWS Cognito (which Butts noted was a missed opportunity for Franklin) is specifically designed to handle secure user authentication and authorization, abstracting away many of these complexities.

1. Strict Authorization and Isolation on Message Brokers: The complete lack of authorization and topic isolation on the MQTT broker was a catastrophic flaw. Message brokers in IoT environments must enforce strict access control policies, ensuring that users and devices can only publish to and subscribe from topics relevant to their specific operations. Wildcard subscriptions to sensitive topics should be heavily restricted or outright forbidden. Proper network segmentation and logical isolation between different customers' data are paramount.

1. Vendor Selection and Outsourcing Scrutiny: Butts' observation about the Chinese consulting company and his strong opinion against outsourcing without proper oversight is a key takeaway. Companies must exercise extreme diligence when outsourcing development, especially for security-critical components. Clear security requirements, regular audits, and strong contractual obligations regarding security standards are essential to prevent the introduction of fundamental flaws.

1. Establish Clear Security Disclosure Channels: The difficulty Butts faced in finding a security contact at Franklin highlights a systemic industry problem. Companies must provide easily discoverable and responsive channels for security researchers to report vulnerabilities (e.g., a security.txt file, dedicated email, bug bounty program). A streamlined disclosure process benefits both the vendor (by enabling faster remediation) and the public (by reducing exposure time to vulnerabilities).

1. Assume Internal Network Compromise: Butts' hypothesis that the gateway device itself likely still operates on an insecure internal MQTT broker, despite the client-side patch, is a crucial defensive consideration. Defenders must assume that internal networks or edge devices might be compromised or exploitable and implement defense-in-depth strategies. This includes segmenting devices, implementing host-based firewalls, and monitoring for unusual network traffic originating from IoT devices.

1. Regular Security Audits and Penetration Testing: The nature of these vulnerabilities suggests a severe lack of basic security testing. Regular, independent security audits and penetration testing, particularly for new product lines or significant feature updates, are indispensable to identify and remediate such fundamental flaws before products reach the market.

In essence, the talk serves as a powerful reminder that "security engineering is good, actually" and that neglecting basic security principles in IoT development leads to easily discoverable and highly impactful vulnerabilities, jeopardizing not just data but potentially physical systems within a home.

Key Takeaways

• Fundamental Security Flaws Persist in IoT: The Franklin system exhibited "aggressively clown shoes" security, including hardcoded credentials, deterministic auth tokens, and a complete lack of authorization on its central MQTT broker, demonstrating that basic security engineering is often neglected in smart home devices.
• MQTT Misconfiguration is a Critical Risk: The use of a single, unauthenticated, and un-isolated MQTT broker where subscribing to # revealed all customer data is a severe vulnerability, highlighting the need for strict topic-based authorization and unique credentials for each device/user in MQTT deployments.
• Vendor Disclosure Processes Are Often Inadequate: Richo Butts faced significant challenges in finding a security contact and initiating disclosure with Franklin, underscoring the industry's need for clearer, more accessible, and more responsive vulnerability reporting channels.
• Outsourcing Requires Stringent Security Oversight: The involvement of a third-party development firm and the subsequent poor security posture suggest that companies must maintain rigorous security requirements and oversight when outsourcing critical software development, especially for IoT devices.
• Partial Patches Leave Remaining Risks: While Franklin issued a patch that improved client-side authentication and authorization, the underlying gateway device likely still operates on an insecure internal MQTT broker, indicating that a full, comprehensive security redesign might still be necessary.
• Personal Motivation Drives Valuable Research: Butts' personal goal of optimizing his home energy system led directly to the discovery and disclosure of significant vulnerabilities, illustrating how real-world problems can motivate impactful security research.

About the Speaker(s)

Richo Butts is introduced as a "well-known member of the community" with a distinguished background in security. He is noted for his early work at Stripe, where his contributions were instrumental in protecting internet transactions. Beyond his corporate roles, including blue team work for various startups and his current position at Anyscale, Richo Butts is also an avid motorsport and outdoor enthusiast. His diverse interests include skydiver, base jumper, and aerobatic pilot, in addition to being a national champion rally car driver. The introduction highlights how he "makes all those communities better," emphasizing his commitment and positive influence across his varied pursuits. His talk at ShmooCon showcases his ability to apply his deep security expertise to real-world problems, even those stemming from personal interests like home energy optimization.