CVE-2024-43201: Planet Fitness App (iOS+Android) improper TLS certificate validation - write-up
Reporters: Dennis Giese, Braelynn Luedtke, Vinnie L., Opal
Date: 2024/08/10
Summary:
The iOS and Android versions of the Planet Fitness app did not verify SSL certificates correctly (or at all). The app will accept self-signed certificates, as the verification seems to be disabled completely.
When in use, the app leaks the user's bearer auth token, PII, health data, and partial financial information. The token allows full access to the users account via the API. The token is valid for 24 hours and can be used to get a new token.
The vulnerability impacted both the iOS and the Android apps versions prior to 25/July/2024. The vulnerability likely existed for a long time. We found the vulnerability in November 2023 and attempted to contact Planet Fitness through various email addresses. We used CISA's Vulnerability Information and Coordination Environment (VINCE) and asked them to help us with the coordination after failing to receive a response from Planet Fitness after repeated attempts at communication. Finally, we got a response at the end of May 2024, and the apps were fixed in July 2024.
Exploit:
The attacker uses a MITM attack to intercept traffic to "*.planetfitness.com" and "planetfitness.auth0.com". For example, this can be done by creating a malicious WiFi-SSID and tricking the users to connect to them or employing attacks like ARP spoofing in an existing WiFi.
The situation is especially severe for Planet Fitness, as the company has a free and open WiFi network at their gym locations. Members typically connect to that WiFi and use it to retrieve their profile in the app to access the QR code to enter the gym. By positioning themselves in the front of a gym, an attacker can collect data from many gym members in a short period of time.
Impact:
An attacker has full access to the member's account, user credentials (if user logs in) and can change any information presented in the app. In addition to the leaked OAuth/JWT tokens, the apps leak personal data. This data includes PII, health, visit history and partial financial information. By modifying the network traffic, an attacker can inject text, pictures and links into the app.
Below are examples for different categories of sensitive data:
PII: Name, Gender, Address, DOB, Phone, Email, Membership number, home gym, invited guest names
Partial financial information: Bank name, account owner, full routing code, last 4 digits of account number, account type, billing date, billing amounts
Health related information (if provided by the user): height, weight, fitness goals, experience level
The token allows access to the visit history of the past year (potentially longer). This includes gym location and check-in timestamps.
Having the information above, social engineering attacks targeting Planet Fitness members would likely be trivial.
Test setup:
We created a WiFi access point and connected our stock Android phone and iPhones to it. All traffic through that access point gets routed through a Linux machine. For every connection, we try to present an invalid certificate. For connections where this fails, we forward the traffic. Over time, we accumulated a list of connections that we could exploit, as well as another list of connections that needed to be forwarded untampered (to prevent app crashes). To fully automate this process, we utilized the tool CertMITM (by Aapo Oksman).
Potential rootcause:
While we did not get an official reply from Planet Fitness in regard to the root causes, we assume that the developers of the app simply forget to enable the SSL checks (or disabled them on purpose). This is something which is expected in development environments, e.g. when the API is not public yet or correctly signed certificates do not exist. When the app went into the production environment, the insecure setting was not caught. Most pentesting companies and automated test-cases only test if the traffic is encrypted and TLS is used (which is the case). A test for correct certificate verification requires more effort and might have been overlooked, as most developers rely on the used SSL library.
<-- Back to my homepage