Pwning Smart Weighing Machines wt API & Hardware Hacking - Eugene Lim

Pwning Smart Weighing Machines wt API & Hardware Hacking - Eugene Lim

Speakers: Eugene Lim, Security Engineer, Space Raccoon Online

Conference: Nullcon

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

Overview

In this compelling talk, Eugene Lim, known online as "space raccoon," delves into the fascinating world of hacking smart weighing machines. What began as a casual observation in a hotel gym—the surprising realization that a weighing machine could connect to the internet—spiraled into an in-depth investigation that uncovered critical vulnerabilities affecting millions of smart health devices globally. Lim's presentation serves as both a case study in cross-disciplinary security research and a guide for software and web hackers looking to venture into hardware hacking.

The core of Lim's research showcases how combining web, software, and hardware hacking techniques can yield profound impact. He systematically breaks down the process of identifying, exploiting, and disclosing two distinct classes of vulnerabilities: a widespread API flaw affecting numerous white-labeled devices and a more sophisticated hardware and API vulnerability in a premium smart scale. The talk not only highlights significant security oversights in the IoT ecosystem but also demystifies the often-intimidating field of hardware reverse engineering for a broader audience.

Background

▶ Watch: Introduction: Why hack smart weighing machines? (0:00)

Eugene Lim's journey into hardware hacking was organic, evolving from his initial experience in web and client-side software security. He recognized that while IoT devices present a vast landscape of potential vulnerabilities, the entry barrier for those unfamiliar with hardware can seem high. This talk aims to bridge that gap, demonstrating a practical approach to uncovering vulnerabilities by focusing on four key areas: authentication, device association, reverse engineering, and exploitation, all while connecting these to broader impact.

Smart weighing machines, like many IoT devices, come with features such as Bluetooth and Wi-Fi connectivity, allowing them to sync health data (weight, body fat, etc.) to mobile applications and cloud services. A critical insight Lim shared is the prevalence of white-labeling in this market. Many seemingly distinct brands often originate from the same Chinese Original Equipment Manufacturers (OEMs). This means they frequently share identical underlying hardware, firmware, mobile application code, and crucially, backend API servers. Consequently, a vulnerability discovered in one brand can often affect an entire ecosystem of re-branded devices, amplifying the potential impact.

Lim detailed the common methods manufacturers use to uniquely identify devices from the factory floor:

1. Static Identifiers: The simplest, yet most insecure, approach involves programming a fixed identifier like a MAC address or serial number. This is vulnerable if the identifier is easily guessable or compromised, as it cannot be rotated.
2. Custom Secret Keys: A more secure method involves programming a unique symmetric or asymmetric (public/private) cryptographic key into each device's memory at the factory.
3. Certificates (PKI): The best practice, utilizing a Public Key Infrastructure (PKI). Each device generates a Certificate Signing Request (CSR) in the factory, which is then signed by an internal Certificate Authority, providing a cryptographically verifiable proof of identity.

Key concerns for any IoT manufacturer at this stage include preventing brute-force attacks on device identifiers, implementing revocation mechanisms for compromised keys, and ensuring clear identification by separating the device's unique ID from the cryptographic proof of its identity.

Once identified, these unique keys or identifiers need to be securely stored. Options range from simple stickers or QR codes (prone to physical compromise), to storing in flash memory (susceptible to extraction), or ideally, in a Trusted Platform Module (TPM) or Secure Element designed to protect cryptographic material even under physical attack.

Finally, the association process links a physical device to a user's account in the mobile application. This typically involves the app scanning a QR code or connecting via Bluetooth to exchange user and device IDs, then informing the cloud server to establish the link. It is at this critical juncture—the interaction between device, app, and cloud—that many vulnerabilities often emerge due to complex business logic or insufficient validation.

Key Findings

▶ Watch: Four key topics: Authentication, Association, RE, Exploitation (2:40)

Eugene Lim's research uncovered two distinct, high-impact vulnerabilities across different smart weighing machine ecosystems, demonstrating the breadth of attack surfaces in IoT devices.

Finding 1: OEM API Vulnerability (MAC Address as Authentication Secret)

Lim's initial investigation focused on the white-labeled smart scales, where he observed multiple brands using identical mobile applications and, by extension, shared backend API servers. By decompiling the Android applications, he was able to extract numerous API endpoints, including those related to device binding (/bindDevice) and firmware updates (/updates).

The critical flaw in this OEM ecosystem lay in its authentication mechanism. The API server used the device's MAC address not only as its unique identifier but also as its implicit "secret key" for authentication. This meant that if an attacker could obtain a device's MAC address, they could effectively authenticate as that device and associate it with their own user account. While brute-forcing MAC addresses is computationally intensive, Lim discovered a more direct path. He found an SQL injection vulnerability in the /getDeviceInfo API call. This was not a straightforward exploit, as it required bypassing a specific Chinese Web Application Firewall (WAF), which he identified as BT WAF. Once bypassed, the SQL injection allowed him to dump a database containing the MAC addresses of over 200,000 devices associated with this OEM. With this list, an attacker could theoretically bind any of these devices to their own user account, gaining unauthorized access to their data. Lim responsibly disclosed this vulnerability, and it was subsequently patched.

Finding 2: Withings Smart Weighing Machine (Hardware Debug Shell & API Logic Flaw)

For his second target, Lim chose a more sophisticated device: the Withings wbs06, a smart scale from a European company known for its custom mobile application and presumably higher security standards. His approach here involved firmware reverse engineering. He successfully pulled the firmware file from the server API by triggering a firmware update through the mobile application, bypassing the need for physical flash memory extraction.

Analyzing the firmware in Ghidra, Lim encountered the complexities of ARM bare metal firmware, which lacks a standard operating system structure like Linux. Despite this challenge, a crucial string "shell" caught his attention, indicating a potential debug interface. To investigate further, Lim turned to OSINT (Open-Source Intelligence). He leveraged the US FCC certification documents, which are publicly available for devices with wireless connectivity. These documents provided invaluable internal and external photos of the device, revealing three exposed pins (labeled TX, RX, and GND) on the PCB, strongly suggesting a serial port. The FCC documents also provided the MCU (Microcontroller Unit) part ID, allowing him to download datasheets detailing the chip's memory map, which is essential for Ghidra analysis.

With this intelligence, Lim acquired the device and necessary hardware tools, specifically a reliable FT232 USB-to-TTL serial converter (after initial struggles with cheaper, unreliable equipment). By connecting to the exposed serial pins and powering on the device with the correct baud rate, he successfully triggered a hidden debug shell during boot-up. This shell provided extensive control, allowing him to read and write to memory, control Bluetooth and Wi-Fi functions, activate debugging modes, and critically, extract the device's stored public and private keys. This granted him the ability to authenticate to the Withings backend servers as that specific device.

However, Lim's impact extended beyond just one device. He then focused on the association logic between a user account and a device. He identified two primary flows: device-initiated and user-initiated. Both flows involved the exchange of a device session token (obtained via the device's private key) and a user session token (obtained via user credentials) before sending both to the API server to bind the device to the user. Lim discovered a critical business logic flaw: the API server did not adequately validate the type of token provided for the "device session token" field. An attacker could supply a valid user session token for both the device session token and the user session token fields, along with any arbitrary numeric device ID. The server would then happily associate the attacker's user account with that target device ID. This vulnerability allowed Lim to take over over 1 million devices, including not only weighing machines but also other medical devices like heart rate and blood pressure monitors that shared the same backend infrastructure. This provided unauthorized access to sensitive health data and the ability to write false information to these devices. Lim disclosed this severe vulnerability on December 29th, and to their credit, Withings patched it within 3-4 days.

Technical Deep Dive

▶ Watch: Understanding smart weighing machine connectivity features (4:00)

The technical depth of Lim's research spans multiple domains, illustrating a comprehensive approach to IoT security.

OEM Ecosystem Vulnerability: The MAC Address as a Secret

The initial phase of Lim's work on generic smart scales highlighted a systemic issue within the Original Equipment Manufacturer (OEM) model. Many "brands" are simply white-labeled versions of a single OEM's product. This means they often share not only the physical hardware but also the firmware, the mobile application's codebase, and critically, the backend API infrastructure. Lim's analysis of decompiled Android applications for these devices confirmed the reuse of identical libraries and code, pointing directly to shared API endpoints.

The core vulnerability here was a fundamental authentication flaw: the OEM's API server used the device's MAC address as its sole authentication credential. While MAC addresses are unique hardware identifiers, they are not designed to be secrets. An attacker possessing a device's MAC address could present it to the API server and be recognized as the legitimate owner, allowing them to bind the device to their own user account.

To exploit this, Lim needed to obtain MAC addresses in bulk. He discovered an SQL injection vulnerability within the /getDeviceInfo API endpoint. This particular vulnerability was more challenging due to the presence of a BT WAF (a Chinese Web Application Firewall). Lim noted that this WAF was surprisingly robust, performing better than some commercial alternatives, and required careful crafting of SQL payloads to bypass its protections. Once bypassed, the SQL injection allowed him to extract a database containing the MAC addresses of approximately 200,000 devices. This mass extraction demonstrated the severe consequences of using weak, non-rotatable identifiers as authentication secrets, enabling widespread device takeover.

Withings Hardware Hacking: From Firmware to Debug Shell

The investigation into the Withings wbs06 scale represented a deeper dive into hardware and firmware security. Lim chose to retrieve the device's firmware directly from the manufacturer's server API, by triggering a firmware update through the legitimate mobile application. This technique is often more efficient than physically extracting flash memory chips.

Analyzing the retrieved firmware presented a challenge: it was ARM bare metal firmware. Unlike firmware built on embedded Linux or other operating systems, bare metal firmware is essentially raw machine code running directly on the microcontroller unit (MCU) without an underlying OS. This means there's no standard file system to unpack (e.g., using binwalk), and memory addresses for functions and data are not easily discernible without prior knowledge. Tools like Ghidra are essential for disassembling and decompiling such code, but the process is significantly more complex than analyzing higher-level software.

A critical step in hardware hacking is OSINT (Open-Source Intelligence). Lim demonstrated its power by consulting US FCC certification documents. These documents, required for wireless devices sold in the US, often contain detailed internal and external photographs of the device, block diagrams, and lists of components. From these, Lim identified three distinct pins on the device's internal PCB labeled TX (transmit), RX (receive), and GND (ground), which are characteristic of a UART serial port. The FCC documents also provided the MCU part ID, which enabled him to download the manufacturer's datasheets. These datasheets are invaluable, providing detailed information about the MCU's architecture, memory map, and peripherals—crucial context for effective firmware reverse engineering in Ghidra.

Armed with this information, Lim acquired the physical device and a TTL-to-USB serial converter. He emphasized the importance of using reliable hardware, specifically recommending converters based on the FT232 chip, after encountering issues with cheaper alternatives that produced inaccurate readings. By connecting the FT232 converter to the identified serial pins on the Withings scale and powering it on with the correct baud rate, he successfully intercepted the boot-up sequence. This revealed a hidden debug shell built into the device's production firmware.

The debug shell was a treasure trove of capabilities. It allowed direct interaction with the device's core functions, including:

• Reading and writing to arbitrary memory locations.
• Triggering Bluetooth and Wi-Fi connections.
• Activating various debugging modes.
• Most critically, extracting stored secrets, such as the device's unique public and private keys. These keys are fundamental for the device to authenticate itself to the backend server. The presence of such a powerful debug interface in a consumer product represents a severe security oversight.

Withings API Vulnerability: Association Logic Flaw

Even with the ability to authenticate as a specific device using its extracted keys, Lim sought broader impact. He then analyzed the business logic of how a user account is associated with a device via the Withings API. He identified two primary flows:

1. Device-initiated association: The device, after connecting to Wi-Fi, uses its stored certificate (private key) to authenticate with the API server, obtaining a device session token. It then communicates with the user's mobile app (typically over Bluetooth) to fetch a user session token. Both tokens are then sent to the API server to complete the binding.
2. User-initiated association: The user's mobile app authenticates with the API server using the user's credentials, obtaining a user session token. The app then communicates with the device (over Bluetooth) to fetch its device session token. Both tokens are then sent to the API server to complete the binding.

The critical logic flaw resided in the API endpoint responsible for processing these association requests. Lim discovered that the API server did not strictly validate the type of token provided for the "device session token" field. An attacker could craft a request where they supplied a valid user session token for both the "device session token" parameter and the "user session token" parameter, along with an arbitrary numeric device ID of a target scale. The API server, lacking proper cross-validation, would accept this request and successfully bind the attacker's user account to the target device.

This vulnerability allowed for horizontal privilege escalation across the entire Withings ecosystem. Without needing physical access to the target device or its private keys, an attacker could remotely associate any device ID with their account. Lim's investigation revealed that this vulnerability extended beyond just weighing machines, affecting over 1 million other health-related devices (e.g., heart rate and blood pressure monitors) that shared the same vulnerable backend API. The impact was severe: an attacker could read sensitive health data from targeted users and even write false data to their medical devices, posing serious risks to data integrity and user well-being.

Demo / Proof of Concept

▶ Watch: Factory provisioning of unique device IDs and secrets (5:00)

Eugene Lim attempted a live demonstration of connecting to the Withings smart weighing machine via its serial port to trigger the debug shell. This involved physically connecting a TTL-to-USB serial converter to the exposed pins on the device's underside and powering on the device while a terminal program was listening.

Although the live demo encountered technical difficulties, Lim had a pre-recorded video demonstrating the process. The video clearly showed the physical connection being made and, upon powering up the device, the terminal window displaying the output of the boot sequence followed by the interactive debug shell. Lim described how, once in the shell, various commands could be executed, confirming the ability to interact with the device's memory, control its wireless modules, and extract its stored cryptographic secrets. This visual proof effectively demonstrated the hardware access achieved through the identified serial port.

Defensive Implications

▶ Watch: IoT manufacturer concerns: brute force and key revocation (5:40)

Eugene Lim's findings offer crucial lessons for both IoT manufacturers and consumers regarding the security of smart devices.

For Manufacturers and OEMs:

1. Robust Authentication: Abandon static identifiers (like MAC addresses or simple serial numbers) as authentication secrets. Implement strong, cryptographically secure authentication mechanisms, ideally leveraging Public Key Infrastructure (PKI) with device certificates and secure elements. Keys should be unique per device and non-extractable.
2. Secure Software Development Lifecycle (SSDLC): Integrate security throughout the development process. For OEMs, white-labeling should not extend to vulnerabilities. Shared codebases and API servers demand rigorous and centralized security audits. Patches for one brand must immediately propagate to all re-branded products.
3. API Security and Business Logic Validation: Implement strict validation at all API endpoints. The association logic flaw highlighted the danger of insufficient validation of token types and parameters. APIs must rigorously verify that submitted tokens are of the expected type (e.g., a device session token is indeed from a device) and that the requesting entity is authorized for the requested action. Prevent Insecure Direct Object References (IDOR).
4. Effective WAF Deployment: While the BT WAF was noted for its strength, it was ultimately bypassed. WAFs are a layer of defense, but should not be the sole protection. They must be regularly updated, tuned, and tested against common and emerging attack techniques like SQL injection.
5. Secure Firmware Practices:

• Remove Debug Functionality: Production firmware must not contain debug shells, unauthenticated serial ports, or sensitive diagnostic commands. If debug features are essential, they must be securely protected (e.g., requiring cryptographic authentication, physical tamper detection, or specific hardware configurations not present in consumer units).
• Secure Boot and Integrity: Implement secure boot mechanisms to ensure only cryptographically signed and verified firmware can run. This prevents unauthorized firmware modifications.
• Secure Storage: Critical secrets (private keys, unique identifiers) must be stored in hardware-protected modules like a Trusted Platform Module (TPM) or Secure Element, making them extremely difficult to extract even with physical access to the device.

1. Incident Response and Disclosure: Establish clear channels for security researchers to report vulnerabilities and implement a rapid incident response plan. Withings' quick patching of a severe vulnerability demonstrates good practice in this regard.

For Consumers:

1. Be Aware of Risks: Understand that smart devices, especially those handling sensitive data like health metrics, can have significant security vulnerabilities.
2. Research Before Purchase: Investigate the security and privacy track record of IoT device manufacturers. Prioritize brands with transparent security practices, bug bounty programs, and a history of responsive patching.
3. Consider Data Sensitivity: Evaluate whether the convenience of a smart device outweighs the potential risks associated with sharing sensitive personal or health data with cloud services.
4. Regular Updates: Ensure devices and their companion applications are kept up-to-date with the latest firmware and software, as these often contain critical security patches.

Key Takeaways

• Cross-Disciplinary Hacking is Key: Achieving significant impact in IoT security often requires combining skills from web, software, and hardware hacking to identify and exploit vulnerabilities across the entire ecosystem.
• OEM White-labeling Risks: The widespread practice of white-labeling can lead to systemic vulnerabilities where a flaw in one OEM's product or backend can affect millions of devices across numerous brands.
• Weak Authentication is a Critical Flaw: Using static identifiers like MAC addresses as authentication secrets is fundamentally insecure and enables mass device compromise if these identifiers are exposed.
• Debug Interfaces in Production are Dangerous: Hidden debug shells, unauthenticated serial ports, or sensitive diagnostic commands in production firmware pose severe risks, allowing attackers to extract secrets and gain deep control over devices.
• Business Logic Flaws are High Impact: Subtle errors in API business logic, especially during device association, can lead to horizontal privilege escalation, allowing attackers to control many devices without needing physical access or device-specific credentials.
• OSINT is a Powerful Reconnaissance Tool: Publicly available resources like FCC certification documents are invaluable for initial hardware reconnaissance, providing internal photos, pinouts, and component details, saving time and cost in hardware hacking efforts.
• Invest in Quality Tools: Reliable hardware hacking tools, such as FT232-based USB-to-TTL serial converters, are essential for accurate and successful physical interactions with devices.

About the Speaker(s)

Eugene Lim, who also goes by the hacking handle "space raccoon online," is a security engineer by day, specializing in standard security engineering work. By night, he is a passionate hacker whose interests have evolved from web and software hacking to the challenging domain of hardware hacking. His journey into hacking smart weighing machines exemplifies his curiosity and dedication to uncovering vulnerabilities in the devices around us. Lim is also the author of an upcoming book, "from day zero to zero day," slated for release in June 2025, which aims to guide aspiring researchers through the process of vulnerability discovery. His talk at Nullcon reflects his commitment to sharing knowledge and empowering others to explore the vast and impactful field of security research.