This topic is highly relevant for review by Application Security Engineers, Penetration Testers, API Developers, and IoT/Cloud Backend Architects.

Abstract

This report details the discovery and exploitation of a critical Cross-Tenant Insecure Direct Object Reference (IDOR, CWE-639) vulnerability within the Xiaomi Mi Fitness (Huami/Zepp Health) API. The analysis utilized advanced penetration testing techniques, including ARP spoofing via MITMf, packet capture via Wireshark, and runtime SSL pinning bypass using Frida on a rooted Android device. The core vulnerability stemmed from the server-side failure to validate the user identity presented in the HTTP request headers (user_id) against the authenticated identity within the JSON Web Token (apptoken). Reverse engineering of the Protocol Buffer (protobuf) payloads revealed sequential, predictable user identifiers. Exploitation allowed an attacker, using a valid token, to access, modify, and delete sensitive personal health and GPS data belonging to any other user. The calculated CVSS v3.1 score for this finding was 9.1 (Critical). Following coordinated disclosure, the vendor implemented server-side authorization checks, enforced TLS 1.3, and introduced API rate limiting.

Critical Analysis of the Xiaomi Mi Fitness API Vulnerability

• Initial Setup and Interception: The analysis commenced with setting up a Man-in-the-Middle (MITM) attack using MITMf and ARP spoofing to force network traffic through the testing machine. Deep packet inspection via Wireshark was complicated by mandatory HTTPS (TLS 1.2), necessitating the use of the Frida dynamic instrumentation toolkit to successfully bypass certificate pinning checks by hooking checkServerTrusted and verify methods.
• Unencrypted Traffic and Protocol Analysis: While much traffic was encrypted, several account-related HTTP POST requests were observed being sent unencrypted over port 80. Further binary analysis (HxD) of raw packets identified custom "magic byte" sequences—0x4D49 for account operations and 0x5853 for data synchronization—which served as proprietary protocol identifiers for the Xiaomi API.
• Protobuf Reverse Engineering: Account operations were found to utilize Google Protocol Buffers (protobuf) for data serialization. Using protobuf-inspector, the binary schema was reverse engineered, confirming that the user_id (Field 1) was transmitted as a simple varint, suggesting sequential integer allocation which facilitates enumeration.
• Vulnerability Discovery (IDOR): The API authentication relied on an apptoken (JWT) and a separate user_id parameter in the HTTP headers. The critical flaw was the server's trust relationship: the system validated the JWT signature but blindly accepted and processed the user_id value provided in the header without cross-referencing it against the actual user ID contained within the validated JWT payload.
• Exploitation Confirmation: By capturing a legitimate request and substituting the user_id header parameter with a sequential integer (12345679), the analyst successfully modified the profile data (weight, height) of an external, unauthorized account, confirming the Cross-Tenant IDOR.
• Scope of Impact: The vulnerability allowed for full CRUD (Create, Read, Update, Delete) access across all user accounts. This included accessing personal health metrics (weight, heart rate), GPS tracks, sleep patterns, and the ability to unpair devices from other accounts. The sequential nature of the user IDs allowed for mass enumeration attacks, potentially affecting over 100 million users.
• Severity Assessment: The vulnerability was classified as Critical, earning a CVSS v3.1 score of 9.1, based on Network Attack Vector (N), Low Attack Complexity (L), Low Privileges Required (PR—only a valid account token needed), and High Confidentiality and Integrity impact across the system's scope (C).
• Remediation and Disclosure: Following a 7-day initial acknowledgment, the vendor implemented the suggested fix within 30 days. The server-side remediation mandated comparing the requested user_id header value against the user_id extracted and verified from the JWT payload, returning an HTTP 403 Forbidden error upon mismatch. Additional security measures included migrating all endpoints to mandatory TLS 1.3 and implementing a restrictive rate limit (60 requests per minute per IP).