Critical vulnerabilities in the Freedom Chat messaging app allowed attackers to enumerate registered users' phone numbers and harvest their device-locking PINs, fundamentally breaking the app's core privacy promises.

Continue reading
What good is a "secure" messaging app if it broadcasts your private phone number to any curious attacker and hands them the PIN to unlock your device? Freedom Chat, an app marketed as privacy-focused, failed these basic tests due to elementary API security flaws.
Security researcher Eric Daigle identified two critical vulnerabilities in the Freedom Chat mobile messaging application that collectively compromised user anonymity and device security. The flaws stem from a fundamental lack of security controls on the application's backend API and improper data handling.
The first vulnerability, CWE-203: Observable Discrepancy, was an insecure user enumeration flaw. Freedom Chat's authentication endpoint did not implement rate limiting or consistent error messages, allowing an attacker to brute-force phone numbers and determine which were registered to the service. This technique directly mirrors recent academic research used to scrape WhatsApp user data.
The second, more severe flaw was CWE-200: Exposure of Sensitive Information to an Unauthorized Actor. By intercepting the app's network traffic, Daigle discovered that when a user joined a public channel, the server's response contained the app-locking PIN codes of every other user in that channel. This data was not displayed in the UI but was transmitted in plaintext within the API response, making it accessible to anyone on the network or with the ability to inspect device traffic.
The attack chain exploits two independent but equally severe API misconfigurations.
1. User Enumeration via Phone Number Probing
The app's user registration/validation endpoint failed to implement standard hardening. An attacker could send a high volume of requests with different phone numbers. The server's response would differ subtly (e.g., HTTP status code, error message, response time) for a number that existed in the database versus one that did not. This allowed for automated, mass-scale harvesting of registered user identities.
[Attacker] -> [Send guess: 555-0100] -> [Freedom Chat API]
[Freedom Chat API] -> [Response: "User not found"] (Status 404)
[Attacker] -> [Send guess: 555-0101] -> [Freedom Chat API]
[Freedom Chat API] -> [Response: "Invalid password"] (Status 401) -> **CONFIRMED USER**2. PIN Code Leakage in Channel Subscription Response The app's logic for handling user joins to public channels was fatally flawed. Upon subscribing to a channel (including the default channel all users join), the backend would query for user data. Instead of returning only necessary, non-sensitive metadata, the SQL query or subsequent data serialization mistakenly included the `user.pin` field for all users in the channel. This data was then serialized into the API response (likely JSON) and sent to the client.
// Example of flawed API response (defanged):
{
"channel": "general",
"users": [
{ "id": 123, "pin": "2580" },
{ "id": 456, "pin": "1234" }
]
}| Type | Value | Source |
|---|---|---|
| Tactic | User Phone Number Enumeration | TechCrunch Report |
| Tactic | PIN Code Exposure in Network Traffic | TechCrunch Report |
| Behavior | High-volume POST requests to `/api/v1/validateUser` or similar | Inferred Attack Pattern |
| Behavior | TLS inspection revealing PIN codes in channel join responses | Inferred Attack Pattern |
SIEM/NDR Hunting Queries:
Endpoint/Mobile Detection:
rule FreedomChat_PIN_Leak {
meta:
description = "Detects JSON structures in traffic that may contain leaked Freedom Chat PINs"
author = "SecureBlink TI"
strings:
$json_pin_field = /"pin"\s*:\s*"\\d{4}"/
condition:
$json_pin_field
}Immediate Actions (For Freedom Chat Users):
Strategic Recommendations (For App Developers):
This incident represents a High severity risk to user privacy and security. The direct impact includes loss of anonymity (phone number exposure) and a significant reduction in device security (PIN exposure). For the vendor, the impact is critical reputational damage, especially for an app marketed on "security" and "privacy."
The lack of a public disclosure channel forced researchers to use the media, creating adversarial publicity and delaying the fix timeline. This failure in security governance is a major red flag for potential users and enterprise evaluators.
While no CVE was assigned in the initial report, the CVSS v3.1 base score for the PIN leakage flaw is estimated as 7.5 (High) - AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. The phone number enumeration flaw scores an estimated 5.3 (Medium) - AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N.

A single ClickFix infrastructure is pushing StealC, Amatera, Remus, NetSupport, CastleLoader and a new loader called ResiLoader through fake Google/Cloudflare checks.