“सुपर सिक्योर” होने का दावा करने वाला मैसेंजर ऐप, सभी यूज़र्स के फ़ोन नंबर लीक

• Freedom Chat नाम के MAGA (अमेरिकी रूढ़िवादी खेमे) थीम वाले मैसेंजर ऐप में एक गंभीर कमजोरी मिली, जो यूज़र्स के फ़ोन नंबर और PIN कोड उजागर करती थी
• यह ऐप Converso नाम के पुराने प्रोजेक्ट का उत्तराधिकारी है, जिसमें पहले भी encryption implementation की गड़बड़ी और data exposure की समस्याएँ रही थीं
• विश्लेषण से पता चला कि channel फीचर के जरिए सभी सदस्यों के PIN कोड दूसरे यूज़र्स तक भेजे जा रहे थे, और contact sync API के जरिए फ़ोन नंबर-UID matching संभव थी
• शोधकर्ता ने पुष्टि की कि rate limiting बिल्कुल नहीं थी, इसलिए एक ही दिन में Freedom Chat के सभी यूज़र्स के फ़ोन नंबर इकट्ठा किए जा सकते थे
• इस घटना को ऐसे उदाहरण के रूप में देखा गया, जहाँ “security पर ज़ोर देने” वाला ऐप बुनियादी privacy protection तक देने में विफल रहा

---

Converso से Freedom Chat तक का बदलाव

• 2023 में लॉन्च हुए Converso ने “serverless decentralized structure” और “latest E2EE” का दावा किया था, लेकिन शोधकर्ता crnković के विश्लेषण से ये सभी दावे झूठे साबित हुए
  • वास्तव में यह central server और third-party encryption service (Seald) का इस्तेमाल करता था, और encryption keys सार्वजनिक जानकारी से निकाली जा सकती थीं
  • सभी messages public Firebase bucket में upload किए जा रहे थे, जिन्हें कोई भी देख सकता था
• इसके बाद CEO Tanner Haas ने ऐप वापस ले लिया और “रूढ़िवादी खेमे की privacy concerns” का हवाला देकर इसे Freedom Chat के रूप में rebrand किया
  • उन्होंने “आलोचना स्वीकार करो और सुधार करो” जैसी सीख का ज़िक्र किया, लेकिन security problems फिर दोहराई गईं

Freedom Chat की संरचना और फीचर

• ऐप फ़ोन नंबर आधारित signup और 2FA code verification का इस्तेमाल करता है, जबकि PIN सेट करना वैकल्पिक है
• इसके मुख्य फीचर 1:1 chat और Channels हैं, जिनकी संरचना Telegram जैसी है
• ऐप screenshot blocking feature को “security feature” के रूप में प्रचारित करता था, लेकिन इसका वास्तविक सुरक्षा से कोई संबंध नहीं था

PIN कोड लीक

• /channel API request के नतीजे में channel के 1,519 सदस्यों के user object में PIN field शामिल थी
  • हर यूज़र के UID, Seald key, creation date आदि के साथ 6-अंकों का PIN कोड plain text में उजागर था
• नया account बनाकर जांचने पर पता चला कि खुद का PIN भी response data में जस का तस शामिल था
• यानी, default channel में मौजूद सभी यूज़र्स के PIN दूसरे यूज़र्स के सामने उजागर होने वाली संरचना थी

फ़ोन नंबर matching कमजोरी

• /user/numbers API, WhatsApp की तरह contact के मौजूद होने या न होने की पुष्टि करती है
  • request में शामिल नंबरों में अगर कोई Freedom Chat यूज़र हो, तो यह UID और Seald key लौटाती है
• शोधकर्ता ने पाया कि इस API पर rate limiting बिल्कुल नहीं थी, इसलिए सभी अमेरिकी फ़ोन नंबर क्रमवार टेस्ट किए जा सकते थे
  • नतीजतन फ़ोन नंबर-UID matching संभव थी, और पहले से उजागर UID-PIN data के साथ जोड़ने पर फ़ोन नंबर-PIN mapping पूरी हो जाती थी

पूरे यूज़र डेटा लीक का प्रयोग

• शोधकर्ता ने Python script लिखकर उत्तरी अमेरिका के सभी फ़ोन नंबर (7-अंकों के संयोजन × area code) पर automated requests भेजीं
  • हर request में 40,000 नंबर भेजे गए, और औसत response time लगभग 1.5 सेकंड था
  • 27 घंटे तक सभी requests सफलतापूर्वक प्रोसेस हुईं, जिससे Freedom Chat के सभी यूज़र्स के फ़ोन नंबर इकट्ठा कर लिए गए
• server ने rate limiting या blocking के बिना response दिया, यानी डेटा पूरी तरह देखे जा सकने की स्थिति में था

प्रतिक्रिया और आगे की कार्रवाई

• 2025-11-23: कमजोरी का पता चला
• 2025-12-04: TechCrunch के पत्रकार Zack Whittaker ने Freedom Chat को कमजोरी की जानकारी दी
• 2025-12-05: Freedom Chat ने कहा, “PIN messages restore करने के लिए नहीं है, और audit process पहले से चल रही है”
• 2025-12-09: समस्या ठीक होने की सूचना दी गई
• 2025-12-11: यह रिपोर्ट और TechCrunch का लेख एक साथ प्रकाशित हुए

मुख्य सबक

• Freedom Chat ने “सुपर सिक्योर” होने का दावा किया, लेकिन बुनियादी authentication, rate limiting और data protection design का अभाव था
• नतीजतन सभी यूज़र्स के फ़ोन नंबर और PIN उजागर हो गए, और security features व्यावहारिक रूप से निष्प्रभावी साबित हुए
• इसे security marketing और वास्तविक implementation के बीच खाई दिखाने वाले एक प्रमुख उदाहरण के रूप में देखा जा रहा है

[GN⁺]

Hacker News की राय

• Signal का encrypted phone number lookup system दिलचस्प है
  क्योंकि सर्वर hardware-encrypted RAM में bit-level XOR operations का इस्तेमाल करके नंबर खोजता है, इसलिए सिस्टम को सबसे निचले स्तर पर भी देखने पर यह पता नहीं चल सकता कि अनुरोध किया गया फोन नंबर मौजूद है या नहीं
  बेशक rate limiting एक अलग और महत्वपूर्ण मुद्दा है। security system बनाते समय कवर करने के लिए सच में बहुत सारे edge cases होते हैं

  • मुझे यह तरीका खास प्रभावशाली नहीं लगता। अगर यह वास्तव में secure messenger है, तो शुरुआत में ही उसे phone number जैसे personal identifier की मांग नहीं करनी चाहिए
  • यह जानने की उत्सुकता है कि अगर कोई सरकार सभी phone numbers के लिए lookup requests भेजे, तो क्या Signal इसे रोक सकता है
    Matrix जैसे non-commercial, privacy-focused platform में ऐसी mapping को ही असंभव बना देना चाहिए
    उदाहरण के लिए, यह प्रस्ताव कि users प्रत्येक user pair के phone numbers के hashed values upload करें ताकि कोई user केवल अपनी contact list में मौजूद लोगों द्वारा ही खोजा जा सके
    इसका फायदा यह है कि hash space बड़ा होता है, इसलिए reverse tracing कठिन होती है, और user खुद discoverability की सीमा तय कर सकता है
    नुकसान यह है कि attacker सभी number combinations बनाकर contact relationships निकाल सकता है, और सरकार SMS verification को intercept करके इसका दुरुपयोग भी कर सकती है
  • सर्वर द्वारा hardware-encrypted RAM में XOR का इस्तेमाल करने वाली बात दिलचस्प है। इस पर कोई additional material है क्या, यह जानना चाहूँगा
  • अब भी phone number की आवश्यकता खटकती है। हाल ही में username feature जुड़ने से number exposure से बचना संभव हुआ है, लेकिन यह अब भी SIM-based account है, यही बात असहज लगती है
  • लेकिन चूँकि हम खुद Signal server को build और operate नहीं कर सकते, इसलिए यह पक्का नहीं कहा जा सकता कि server वास्तव में ऐसा processing कर रहा है

• user object का pin field संदिग्ध लगता है
  संभव है कि यह opt-out serialization library के इस्तेमाल से हुई समस्या हो। default रूप से पूरा object serialize हो जाता है, इसलिए अगर developer किसी खास field को exclude करने वाली setting लगाना भूल जाए, तो वह वैसे ही expose हो जाता है
  या फिर server पर बस JS dictionary इस्तेमाल की गई हो और response भेजने से पहले field हटाई न गई हो
  यह vulnerability University of Vienna research team paper में उल्लेखित पुरानी समस्या है, और 2016 में Telegram में भी इसी तरीके से exploit हुआ था, जिसके कारण ईरानी सरकार ने 1.5 करोड़ users के phone numbers इकट्ठा किए थे
  संबंधित लिंक: Telegram ब्लॉग

  • पिछली नौकरी में code audit करते समय मैंने ऐसी serialization vulnerabilities कई जगह देखी थीं। developers को अब ऐसी libraries का इस्तेमाल बंद कर देना चाहिए
  • ऐसी समस्याएँ वास्तव में बहुत आम हैं। sensitive fields client को भेज दिए जाते हैं, लेकिन UI में दिखते नहीं, इसलिए किसी को पता ही नहीं चलता
  • PIN का expose होना समस्या है, लेकिन plaintext storage उससे भी अधिक गंभीर है। इसे password की तरह किसी मजबूत hash algorithm से process किया जाना चाहिए था

• आजकल अधिकतर security vulnerabilities सिर्फ अप्रत्याशित तरीके से HTTP endpoints को call करने से पैदा होती हैं
  2025 में hacking सुनते ही लोग जटिल तकनीक की कल्पना करते हैं, लेकिन हकीकत यह है कि rate limiting तक के बिना API deploy कर दिए जाते हैं। यह तो Nginx setting की एक लाइन से हल होने वाली समस्या है

  • “Nginx setting की एक लाइन से हो जाएगा” सुनकर ऐसा जवाब याद आता है जैसे, “वह Docker tutorial में नहीं था, इसलिए मुझे नहीं पता वह क्या है”
  • software development आगे बढ़ा है, लेकिन security development principles लगभग आगे नहीं बढ़ पाए हैं
    अधिकांश लक्ष्य user friction कम करना और commercial efficiency बढ़ाना है। बहुत से developers XSS या SSRF जैसी बुनियादी vulnerabilities जाने बिना केवल features implement कर देते हैं
  • कोई सरल setting भी तभी लागू की जा सकती है जब उसके अस्तित्व के बारे में पता हो
  • पहले मुझे automated internal security scans बेकार लगते थे, लेकिन basic settings छूट जाने के इतने मामले देखने के बाद अब वे अनिवार्य लगते हैं
    Docker port mapping की गलती या CSP की कमी जैसी बुनियादी security mistakes बहुत आम हैं
  • लेकिन सिर्फ rate limiting पर्याप्त नहीं है। attacker IP को distribute करके parallel requests भेज सकता है

• “मैं readers को सिर्फ सबसे बेहतरीन blog posts देना चाहता हूँ” यह वाक्य पढ़कर लगा कि मुझे लेखक जैसा मिलती-जुलती प्रवृत्ति वाला व्यक्ति मिल गया

• सोच रहा हूँ कि क्या Freedom Chat® में ऐसा feature है जो journalists को group chat में शामिल होने से रोक सके। आधा मज़ाक, आधा गंभीर होकर अपने DoD दोस्त के लिए पूछ रहा हूँ

• सिर्फ इस साल ही कई बार ऐसा हुआ है कि “security apps” ने user data संभालते हुए leak कर दिया
  याद आने वाली ही लगभग 20 cents worth (=4 cases) हैं, लेकिन शायद इससे भी ज़्यादा होंगे
  संबंधित मामले: 1, 2, 3

  • मुझे लगता है कि इस घटना के बाद Facebook Messenger से बाहर निकलने की कोशिश महत्वपूर्ण है
  • और हमें जो पता है, वह उनमें से सिर्फ एक हिस्सा है

• पिछले साल मैंने संयोग से GOP job board देखा था, और applications उसी search index में store थीं जिसमें job postings थीं
  “bob” खोजते ही applicants के resumes और answers वैसे ही सामने आ गए, यह देखकर झटका लगा

  • यह जानने की जिज्ञासा है कि वह कौन-सी site थी

• Anom घटना के बाद “honeypot” से बेहतर किसी शब्द की ज़रूरत महसूस होती है
  सचमुच सुरक्षित messenger इस तरह से नहीं आएगा। लेकिन marketing चलती रहेगी, और हर बार नए users खिंचे चले आएँगे

  • आजकल तो failure ही feature बन जाता है
    data leaks इतनी बार होते हैं कि अब लोग भी सुन्न हो चुके हैं। class action settlement का मुआवज़ा भी आखिरकार और अधिक personal information देने की प्रक्रिया बन जाता है
    prediction markets, cryptocurrency आदि भी आखिरकार participants को नुकसान पहुँचाने वाली structural failures को ‘success’ की तरह पैक करके बेचने जैसा लगता है
  • “Petepot” नाम का एक नया शब्द भी सुझाया गया

• Freedom Chat ने घोषणा की है कि “समस्या ठीक कर दी गई है”, लेकिन क्या यह सच में ठीक हुई है, इस पर संदेह है

• अगर “मुझे mobile app development का अनुभव नहीं था, लेकिन मैं स्मार्ट हूँ इसलिए यह मुश्किल नहीं होगा” सचमुच का उद्धरण है, तो यह लगभग stand-up comedy की line जैसा लगता है