The vulnerability that killed FreeWifi_Secure

TL;DR

While experimenting with the Evil-M5Project near my own Freebox and smartphone, I stumbled across a vulnerability in FreeWifi_Secure. It turns out that the Free Mobile subscriber devices that leak their IMSI in cleartext during EAP-SIM authentication. This means that anyone within Wi-Fi range could passively capture the IMSI of Free Mobile users. No RCE, no magic exploit but a serious privacy issue allowing tracking, IMSI-to-user correlation, and even potential exploitation through telecom protocols like SS7.

What was FreeWifi_Secure again?

Back in the day, Free introduced FreeWifi_Secure, a network designed exclusively for Free Mobile subscribers. The idea was simple and clever: instead of consuming precious mobile data or struggling with weak 3G coverage, your smartphone could automatically connect to the Internet through any nearby Freebox that broadcasted this special SSID. The authentication relied on EAP-SIM, meaning your SIM card itself acted as the key. This made the process seamless for the user: no passwords, no clicks, just automatic connectivity.

It was a lifesaver in the early 2010s, when unlimited mobile data was rare and expensive. I personnally used the service multiple times and it was really pleasure to have all this possible connexion to internet available all around the town.

But hidden in this convenience was a subtle problem. The way phones handled EAP-SIM with FreeWifi_Secure and that is where the story begins.

The accidental discovery

I wasn’t hunting for vulnerabilities in Free’s ecosystem. I was simply experimenting with a small pentesting gadget, the Evil-M5Project, to test Wi-Fi interception scenarios. My setup was capturing different types of authentication exchanges when something unexpected happened. My own smartphone, which still had FreeWifi_Secure saved from previous use, automatically reconnected to the network during my test.

While reviewing the packet captures in Wireshark, I noticed something strange. My filter wasn’t limited to the usual EAPOL frames but also caught some EAP frames. One of them contained an ASCII string that looked very familiar:

20815XXXXXXXXXX@wlan.mnc015.mcc208.3gppnetwork.org

This wasn’t a random string. It was my full IMSI, exposed in cleartext. At first, I thought this might just be some anomaly on my setup or a specific modification that cause this leak. But after repeating the capture several times, the result was always the same. My phone was happily leaking its IMSI every time it tried to connect to FreeWifi_Secure.

Isolated bug or systemic issue?

Of course, I had to be sure this wasn’t just my device or my Freebox behaving oddly. So I began a series of tests:

With my own Freebox and phone → same leakage.
Using the Evil-M5Project in replay mode to mimic another environment → same leakage.
Testing with friends’ devices on different generations of Freeboxes → same leakage. (Not on new models due to desactivation of the service)

After multiple experiments, it became clear: this wasn’t a configuration glitch. It was systemic when FreeWifi_Secure is activated.

Free Mobile subscriber phones themselves, when attempting EAP-SIM authentication to FreeWifi_Secure, revealed their IMSI in the open. The Freeboxes were just relays, passing along what the phones sent.

The newer Freebox models (Delta, Pop, Ultra) had removed FreeWifi_Secure, which indirectly solved the problem. But for the millions of older boxes still in use, every phone connecting to FreeWifi_Secure was leaking its IMSI to anyone listening.

What is an IMSI?

The IMSI (International Mobile Subscriber Identity) is a unique number stored on every SIM card. It identifies you as a subscriber to your mobile operator and links your device to your account. Think of it like a digital passport number: permanent, unique, and tied to your identity within the mobile network.

When the IMSI is exposed, anyone who captures it can recognize your device each time it appears. This makes it possible to track your movements over time. For example, observing that the same IMSI shows up at home in the evening, at work during the day, and near a gym after hours.

In the mobile core network, the IMSI plays a central role in authentication, billing, and roaming. It is used within signaling protocols like SS7 (Signaling System No.7) and Diameter. Attackers who gain access to an IMSI may:

Query SS7 networks to locate a subscriber geographically.
Intercept or reroute calls and SMS messages which can leak MFA.
Perform targeted surveillance by abusing legacy telecom trust models.

This is why 3GPP standards recommend the use of temporary identities (TMSI or pseudonyms) instead of broadcasting the IMSI in the clear. Leaking an IMSI is not just a privacy annoyance, it can open the door to surveillance at the telecom signaling layer.

Technical details

When a smartphone tries to log in with EAP-SIM, the very first step is to send an Identity message. Think of it like introducing yourself before a conversation starts. The problem is that on FreeWifi_Secure, that identity is not a pseudonym or a temporary token, it is the subscriber’s full IMSI. And worse, it is sent before any secure tunnel (like TLS) is in place. So anyone with a Wi-Fi sniffer in range can read it as plain ASCII text.

In other words, your phone says: “Hello, I am IMSI 20815XXXXXXXXXX” every time it tries to connect, loud and clear for all to hear.

Technical deep dive

EAP-SIM (Extensible Authentication Protocol – Subscriber Identity Module) is an authentication method defined in RFC 4186. It is based on the GSM authentication and key agreement mechanism, using triplets (RAND, SRES, Kc) generated by the HLR/AuC of the mobile operator. The protocol flow is:

Beacon / Probe: The AP (Freebox) continuously transmits beacons advertising the presence of FreeWifi_secure. The client (phone) may also actively send probe requests or scan near network to discover the SSID.
Association: If the client has this SSID stored (auto-connect enabled), it will send a Probe Request / Association Request automatically. The Freebox replies with an Association Response, completing the 802.11 association.
EAP-Request/Identity: The authenticator (in this case, the Freebox) asks the client for its identity.
EAP-Response/Identity: It’s here that the problem appear. The client (the phone) replies with its permanent identity (IMSI) or a pseudonym/temporary identity if implemented.
AAA exchange: The authenticator forwards this to the operator’s AAA server (typically over RADIUS or Diameter). If IMSI is sent in clear, the AAA knows the subscriber.
Challenge phase: The AAA sends EAP-Request/SIM/Start with a set of challenges (RANDs). The phone queries the SIM card, which computes the expected responses (SRES) and ciphering keys (Kc).
EAP-Response/SIM: The client returns the SRES values derived from the SIM.
Verification: The AAA compares responses. If correct, mutual authentication is achieved and session keys (MSK, EMSK) are derived for encryption of subsequent traffic.

SSID: FreeWifi_secure
Authentication method: EAP-SIM
Protocol: IEEE 802.1X
Critical packet: EAP-Response/Identity
Content: Full IMSI encoded in ASCII, suffixed with the NAI domain 20815XXXXXXXXXX@wlan.mnc015.mcc208.3gppnetwork.org
Missing security: No protected identity (3GPP TS 33.402 §4.2.4), no TLS tunnel before identity exchange.

Minimal reproducible PoC:

1) Put Wi-Fi interface in monitor mode
2) airmon-ng start wlan0
3) Run sniffer (Kismet, Wireshark)
4) Wait for a Free Mobile device to auto-connect to FreeWifi_Secure
5) Inspect the first EAP-Response/Identity frame

Result: the phone’s IMSI appears in cleartext.

Impact

This issue isn’t about remote code execution or taking over Freeboxes.

It’s about privacy and confidentiality.

By leaking the IMSI:

Any passive attacker within ~100 meters can capture a subscriber’s IMSI.
The IMSI is a permanent identifier, tied to a SIM card and indirectly to the subscriber.
This enables physical tracking of users, since the same IMSI will appear each time the device connects.
It also allows correlation between a person and their Free Mobile subscription.
Combined with SS7 or Diameter abuse, a captured IMSI can be used for location tracking, call interception, or targeted telecom-level attacks.

In short: FreeWifi_Secure turned every phone into a beacon, shouting its permanent identity whenever it tried to connect despite himself.

Responsible disclosure

After confirming the issue, I reached out to Free by email trough the security.txt (yes some people use this thing), explaining the vulnerability and my intent to request a CVE for proper tracking and document the vulnerability.

Shortly after, the company’s RSSI (CISO in French terminology) kindly called me back. Instead of denying or ignoring the issue, he acknowledged the problem which was already known internally but explained that the end of support had been postponed since no incident had been reported so far.

He asked me to delay public disclosure so that Free could first roll out a global program to disable FreeWifi_Secure on the affected devices.

I agreed immediately, my goal is to get things patched, not exploited, making a publication before it is patched does not fall within the scope of responsive disclosure, the delay between publication and patching too often leaves time for malicious attackers to exploit these flaws, even briefly.

Weeks later as it was planned, he reached out again to confirm that the rollout had started: Freeboxes across the network would receive a firmware update that disabled FreeWifi_Secure by default the 1st October 2025.

This responsible handling shows that collaboration between researchers and vendors can actually lead to quick, effective mitigation for millions of users.

Mitigations

For Free (vendor side):
- Disable FreeWifi_Secure by default on legacy hardware. (Planned for the 1st October 2025)
For users:
- Manually delete the FreeWifi_Secure SSID from your phone’s known networks.
For Me
- Apply for a CVE to reference and track the vulnerability (Apply for reservation, should be public soon).

Conclusion

The end of FreeWifi_Secure.

In practice, Free had already started burying this service, newer Freeboxes don’t broadcast FreeWifi_Secure at all. My discovery only confirmed that it was a good choice : it was a privacy liability waiting to be exposed.

For years, countless IMSIs may have been silently captured in public spaces, without users ever knowing, I dont find any documentation or information online on this specific subject it therefore seemed important to me to document it. This was not a flashy exploit, but a clear demonstration of how fragile privacy can be when core identifiers like the IMSI are left unprotected.

If you care about privacy, assume this pattern still exists outside Free: any ISP or roaming Wi-Fi deployment that uses SIM-based auth without protected identities can be trivially profiled.

The practical takeaway is brutal and simple stop sending IMSIs in the clear. Implement protected identities, update firmware, and treat carrier Wi-Fi authentification as part of the threat model. Until that happens everywhere, packet captures will continue to tell stories operators thought were private.

The takeaway? Sometimes, a casual test on packet capture is all it takes to reveal a massive privacy flaw. And thanks to responsible disclosure and Free action, this time the story ends with a fix, not an exploit.

Special thanks to Free/Iliad’s CISO (RSSI) for his professionalism, clear communication, efficient handling of the responsible disclosure process, and the rapid fix after becoming aware of the vulnerability.