DDoSecrets ने TeleMessage से हैक किए गए 410GB heap dump डेटा को सार्वजनिक किया

• हैकर समूह DDoSecrets ने इज़राइली कंपनी TeleMessage से हैक किए गए 410GB heap dump डेटा को सार्वजनिक किया
• TeleMessage, Signal, WhatsApp, Telegram, WeChat के modified versions विकसित करके message archiving सेवा देता है
• इस डेटा में plain text messages, metadata, personal information शामिल हैं, इसलिए इसे केवल पत्रकारों और शोधकर्ताओं तक सीमित रूप से वितरित किया जा रहा है
• TeleMessage उत्पादों ने end-to-end encryption सपोर्ट करने का दावा किया था, लेकिन वास्तव में यह उसे bypass करने वाली संरचना निकली
• यह भी सामने आया कि अमेरिकी सरकार और अधिकारियों ने सुरक्षा की दृष्टि से कमजोर चैनलों के जरिए संवेदनशील जानकारी साझा की थी

---

अवलोकन

• मई 2025 में, हैकिंग समूह DDoSecrets ने इज़राइली कंपनी TeleMessage से प्राप्त 410GB heap dump डेटा को सार्वजनिक किया
• TeleMessage, Signal, WhatsApp, Telegram, WeChat जैसे प्रमुख messengers के लिए central storage (archive) solution उपलब्ध कराने वाली कंपनी है
• इस डेटा में संवेदनशील जानकारी और बड़ी मात्रा में personal identifiable information (PII) शामिल है, इसलिए इसे केवल पत्रकारों और शोधकर्ताओं तक सीमित कर वितरित किया जा रहा है

घटना का संक्षिप्त टाइमलाइन

• मार्च: Trump प्रशासन के दौरान राष्ट्रीय सुरक्षा सलाहकार Mike Waltz ने Signal group में war crimes से जुड़ी बातचीत के दौरान गलती से एक पत्रकार को आमंत्रित कर लिया। इसके बाद संबंधित सामग्री की रिपोर्टिंग हुई और कांग्रेस सुनवाई आयोजित की गई
• 1 मई: जिस दिन Waltz को पदावनत किया गया, उसी दिन उन्हें TeleMessage द्वारा बनाए गए TM SGNL नामक Signal के modified version का उपयोग करते हुए देखा गया। उनके बातचीत के साथी Tulsi Gabbard, JD Vance, Marco Rubio जैसे वरिष्ठ अधिकारी थे
• 3 मई: TM SGNL का source code GitHub के माध्यम से सार्वजनिक हुआ
• 4 मई: TeleMessage hack हुआ और संबंधित तथ्य मीडिया में रिपोर्ट किए गए
• 5 मई: एक अन्य हैकर ने TeleMessage को फिर से हैक किया, जिसके कारण सेवा बाधित हो गई
• 6 मई: TM SGNL source code के analysis से साबित हुआ कि TeleMessage द्वारा दावा किया गया end-to-end encryption वास्तव में लागू नहीं था। हैक किए गए कुछ डेटा में plain text chat logs की पुष्टि हुई
• 18 मई: आगे के analysis में TeleMessage के archive server की vulnerability सार्वजनिक हुई। एक specific URL (archive.telemessage.com/management/heapdump) पर कोई भी जाकर Java heap dump डाउनलोड कर सकता था

इस लीक का विस्तृत विवरण

• सार्वजनिक किया गया heap dump 4 मई 2025 को प्राप्त किया गया था और यह TeleMessage द्वारा दी जाने वाली secure messaging solution की कमजोरी से जुड़ा था
• यह पुष्टि हुई कि इस उत्पाद का उपयोग 2023 से अमेरिकी सरकार सहित कई संस्थानों में किया जा रहा था
• डेटा में plain text messages, sender/receiver information, timestamps, group names जैसी समृद्ध metadata शामिल है
• DDoSecrets शोध उद्देश्यों के लिए आवश्यक जानकारी को extract और refine करके उपलब्ध करा रहा है

प्रभाव और संकेत

• इस घटना ने messaging solutions की विश्वसनीयता की कमी और ऑपरेशनल लापरवाही को उजागर किया
• TeleMessage द्वारा विज्ञापित सुरक्षा स्तर और वास्तविक व्यवहार के बीच असंगति की पुष्टि हुई
• यह सामने आया कि अमेरिकी सरकार के वरिष्ठ अधिकारियों ने कमजोर clone messaging apps के जरिए गोपनीय जानकारी का आदान-प्रदान किया, जिससे गंभीर सुरक्षा मुद्दा उभरकर सामने आया
• SignalGate कहे जा रहे इस घटनाक्रम का असर अभी भी जारी है और सुरक्षा समुदाय द्वारा आगे का analysis और response जारी रहने की संभावना है

[GN⁺]

Hacker News की राय

• किसी सर्वर पर /heapdump endpoint मौजूद था और वह सार्वजनिक रूप से server heap dump दे रहा था; ऐसा कहा गया कि इस वजह से यह घटना काबू से बाहर बढ़ती हुई लगती है। यह भी कहा गया कि इस समूह ने वास्तव में डेटा को पूरी तरह “public” नहीं किया है, बल्कि पत्रकारों को access के लिए application जमा करनी पड़ती है। यह भी इशारा किया गया कि वास्तविक message content कितना है यह बताए बिना सिर्फ 410GB dump होने का आंकड़ा उछाला गया, जिससे मामला और बड़ा बना।

  • ज़रा कल्पना कीजिए कि पहले से अविश्वसनीय software को और भी खराब बनाया जाए, और ऊपर से उसे paid भी कर दिया जाए। यह कंपनी की नज़र से भी शर्मनाक है और users की नज़र से भी।

  • मुझे लगता है कि असली point यही है कि वास्तविक डेटा कितना है यह बताए बिना सिर्फ 410GB का number बताया जा रहा है। मैंने हाल में ऐसा ही एक बड़ा dump देखा था, और उसमें असल में सिर्फ OS package update cache और logs ही थे। उसमें कोई महत्वपूर्ण डेटा नहीं था। Heap dump का size आसानी से कम किया जा सकता है, लेकिन यहाँ सब कुछ ही दे दिया गया, जो थोड़ा संदिग्ध लगता है। हाँ, यह भी हो सकता है कि 512GB dump में से महत्वपूर्ण डेटा पहले ही छाँट लिया गया हो।

  • अक्सर यह धारणा रहती है कि ज़्यादातर Israeli software companies शानदार पूर्व Mossad लोगों से भरी होती हैं, लेकिन मुझे लगता है कि हक़ीक़त उम्मीद जितनी प्रभावशाली नहीं है। उम्मीद है कि इस message dump में कुछ दिलचस्प चीज़ें मिलेंगी।

  • लगता है किसी ने Java application इस्तेमाल करते हुए गलती से सारे JMX endpoints को HTTP पर expose कर दिया। यह default setting नहीं होती, इसलिए मुझे यह सीधी-सी लापरवाही से हुई गलती लगती है।

  • मैं जानना चाहता हूँ कि यह server heap dump है या client-side heap dump। अगर client crash होने पर logs छोड़ने के लिए इसे जानबूझकर रखा गया हो, तो वह भी संभव लगता है।

• TeleMessage CEO की LinkedIn bio ऐसी लगती है जैसे किसी AI ने बहुत ही खराब auto-generate की हो। उसमें strategic innovation, ethical values, SaaS, M&A, industry leadership जैसी घिसी-पिटी पंक्तियाँ भरी हुई हैं।

  • यह सच में बेहद खराब LinkedIn-style writing लगती है।

  • संक्षेप में, उसका सार कुछ ऐसा है: "मैं CEO हूँ। हमारी कंपनी SaaS है। मैं CEO हूँ।"

• TeleMessage घटना सामने आए कई हफ्ते हो गए, तो जिज्ञासा है कि क्या Signal Foundation ने कोई आधिकारिक बयान दिया है। Signal नाम इस्तेमाल करके open-source third-party clients आने पर trademark lawsuit की चेतावनी दी जाती है, लेकिन defense contractors वही नाम इस्तेमाल करें तो चुप्पी क्यों है—इस दोहरे मानदंड पर सवाल उठाया गया।

  • एक राय यह है कि अभी अमेरिकी समाज में कई organizations इसलिए चुपचाप पड़ी हैं क्योंकि उन्हें सरकार के हमले का डर है। दूसरी ओर, कुछ लोगों को लगता है कि Signal Foundation के केंद्र में रहे Moxie अब संगठन से दूर हो चुके हैं और उनकी मौजूदगी खत्म-सी हो गई है, इसलिए अब यह भी साफ नहीं कि संगठन किस दिशा में जा रहा है।

  • मुझे नहीं लगता कि इस मामले में Signal की कोई गलती है। असल समस्या TeleMessage और उन ज़िम्मेदार लोगों की है जिन्होंने इसे चुना और इस्तेमाल किया। Signal कुछ कह भी दे, तो शायद उसे सिर्फ आलोचना ही मिले और कोई सार्थक परिणाम न निकले।

  • जैसे पहले Signal FOSS fork को legal warning मिली थी, वैसे अब यह जानने की उत्सुकता है कि क्या Molly अभी भी चल रही है, या कोई broadly self-hostable server विकल्प मौजूद है।

  • moxie और fdroid के झगड़े को लेकर मेरी अपनी नाराज़गी रही है, लेकिन यह मामला उससे बहुत बड़ा है—यह state power और भ्रष्टाचार का मुद्दा है, जो किसी एक व्यक्ति या कंपनी की सीमा से बाहर जाता है। यह भी कहा गया कि ज़रा सोचिए, अगर किसी दूसरे देश की सरकार ने किसी अनजान विदेशी software को राष्ट्रीय communication tool बना लिया होता, तो उसे अक्षमता कहकर कितना कोसा जाता।

  • नाम और brand की सुरक्षा की ज़रूरत से मैं सहमत हूँ। Open source को fork करने का यह मतलब नहीं कि आप मूल creator का brand और नाम भी मनमाने ढंग से इस्तेमाल कर सकते हैं। जैसे Firefox या VSCode के open-source versions को fork करने पर भी, trademark की वजह से copies पर वही मूल नाम नहीं लगाया जा सकता।

• Signal fork भले ही खराब था, लेकिन फिर भी कानूनी था; पर यह जानकर सचमुच झटका लगा कि यह कंपनी cracked WhatsApp भी बेच रही थी। और यह कि ऐसे products खरीदने वाले ग्राहक agencies और governments थे, यह तो और भी अविश्वसनीय है। लिंक भी जोड़ा गया।

  • यह अवैध क्यों है, यह सवाल उठाया गया। Beeper case के उलट, अमेरिकी न्याय विभाग कभी-कभी private clients पर रोक को अच्छा नहीं मानता; तो क्या WhatsApp का मामला अलग है? एक राय यह है that WhatsApp archiver दरअसल user के WhatsApp पर patch install करने के तरीके से काम करता है; इसमें security concerns तो हैं, लेकिन इसे अवैध कहना साफ नहीं है।

  • अनुभव के आधार पर यह साझा किया गया कि वैश्विक financial markets में Global Relay और TeleMessage compliance-focused communication solutions के बड़े vendors माने जाते हैं।

• मेरी कंपनी का काम इससे बहुत कम महत्वपूर्ण है, फिर भी हम साल में दो बार external penetration testing करवाते हैं। ऐसे स्तर की गैर-ज़िम्मेदाराना गलती कानूनी रूप से कैसे संभव हो सकती है, यह समझ से बाहर है।

  • शायद कारण यह है कि software engineering को अभी भी असली engineering की तरह गंभीरता से नहीं लिया जाता। उदाहरण के लिए, अगर कोई हादसा हो भी जाए तो उससे जुड़ी accountability काफ़ी सीमित रहती है।

  • दरअसल संभव है कि यह कानूनी था ही नहीं। यह भी सुना गया कि SOC2 तक को नकली तरीके से पेश किया गया था।

• Heapdump शब्द मैंने करीब 15 साल पहले Android app debugging करते समय सीखा था। यह Java process की memory snapshot होती है, इसलिए इसमें plaintext होना स्वाभाविक है। असली सवाल यह है कि ऐसे heaps खुले HTTP endpoint पर क्यों उपलब्ध थे। शायद यह client code में hardcode था, या request pattern देखकर इसका अंदाज़ा लगाया गया। Backend architecture या message storage कैसे काम करता है, यह सिर्फ इस जानकारी से समझना आसान नहीं; इसलिए मैं सोच रहा हूँ कि कहीं मैं कुछ miss तो नहीं कर रहा।

  • Spring Boot के observability endpoints के default paths तय होते हैं, इसलिए अगर API path पता हो तो heap dump endpoint का path निकालना भी आसान होता है।

• Production environment में बिना authentication वाला /heapdump endpoint expose करना एक शुरुआती स्तर की गलती है। और जो service संवेदनशील सरकारी communications संभालती हो, वहाँ तो यह और भी गंभीर है। MD5 hash और JSP जैसी पुरानी technologies का इस्तेमाल भी security की समझ की कमी दिखाता है। यह घटना एक textbook example है कि defensive security और नियमित audits क्यों ज़रूरी हैं।

  • मुझे नहीं लगता कि JSP को सिर्फ नकारात्मक नज़र से देखना चाहिए। Java Server Pages अब Jakarta Server Pages के रूप में आगे बढ़ रही है, इसका नया version भी हाल में आया है, और Spring Framework 7 जैसी चीज़ें भी इसे आधार बनाती हैं। Java ecosystem अब भी बढ़ रहा है। अगर versions ठीक रखे जाएँ और upgrades समय पर हों, तो इसे पुरानी technology कहना सही नहीं होगा। बस इसकी popularity पहले जैसी नहीं रही। और सच तो यह है कि आधुनिक tech stack जैसे next.js से भी बिना authentication वाले कमजोर endpoints बनाए जा सकते हैं।

• जब विधायक या सांसद e2e encryption पर ban लगाने या backdoor की मांग करते हैं, तो मुझे लगता है कि यह घटना एक अच्छे real-world example की तरह सामने रखी जा सकती है।

• डेटा बहुत sensitive है और उसमें बहुत-सा PII है, इसलिए DDoSecrets इसे सिर्फ journalists और researchers के साथ साझा कर रहा है। आम तौर पर मैं responsible disclosure के पक्ष में रहता हूँ, लेकिन इस बार मुझे लगता है कि शायद इससे भी ज़्यादा दर्दनाक और घातक leak की ज़रूरत पड़ सकती है। Dictators और oligarchs hack हो जाने की परवाह कम करते हैं, वे ऐसे ही tools इस्तेमाल करते रहेंगे; बदलाव तभी आएगा जब प्रभावित नागरिक गुस्सा होंगे। Security failure की वजह से लोगों की agency कमज़ोर हुई है। अगर media या researchers रिपोर्ट करने की कोशिश भी करें, तो authoritarian समाजों में उन्हें आसानी से चुप कराया जा सकता है, और फिर किसी को असल हालात का पता ही नहीं चलता। तब सत्ताधारी बिना किसी प्रतिरोध या नतीजे के दमन को सही ठहराते रहते हैं। अगर यह सिर्फ एक corporate security incident होता, तो मैं responsible disclosure को ही पसंद करता, लेकिन dictatorship को रोकने के लिए मामला अलग हो सकता है।

  • आजकल पत्रकारों को चुप कराना भी ज़रूरी नहीं रह गया है। बहुत से लोग पहले ही anonymous social media accounts या political influencers को ही source मान लेते हैं, इसलिए कुछ बड़ा खुलासा भी हो जाए तो उसे “fake news” कहकर टाल दिया जाता है। अगर पर्याप्त voters बहक जाएँ, तो फिर उसका असर भी कम रह जाता है।

  • यह विचार कि अनुचित शासन के प्रति लोगों को जगाने के लिए उन्हें और नुकसान सहना पड़े, मुझे खतरनाक लगता है। अगर यह सोच चरम पर जाए, तो यह और बड़े violence या suffering को भी सही ठहराने लगती है। आम तौर पर यह कहना कि लोगों को जगाने के लिए उन्हें और गहरी चोट लगनी चाहिए, बहुत जोखिमभरा तर्क है।

  • अगर यह डेटा सचमुच public हो गया, तो नुकसान नेताओं तक नहीं बल्कि अंदरूनी sources तक पहुँच सकता है। उदाहरण के लिए, अगर logs में informants जैसी संवेदनशील जानकारी हो, तो लोगों की जान तक ख़तरे में पड़ सकती है।

  • ऑस्ट्रेलिया के पुराने Cabinet leak का ज़िक्र करते हुए कहा गया कि एक broadcaster ने ज़्यादातर जानकारी सरकार को लौटा दी थी, और इस तरह वह ढकने-छिपाने में मददगार बन गया। यह तर्क दिया गया कि ऐसे तरीकों से वे अहम तथ्य छिप गए जिन्हें जनता को जानना चाहिए था, और उनका बड़ा राजनीतिक असर हो सकता था। कुछ लोगों को लगता है कि इस बार का Signalgate भी वैसा ही है। पार्टी राजनीति से परे, लोगों का अधिक जानकारी जानने का अधिकार महत्वपूर्ण है।

• यह विडंबनापूर्ण लगता है कि राजनेता communication software में backdoor की पैरवी करते हैं और फिर खुद वैसी ही hacking का शिकार हो जाते हैं। अफ़सोस की बात यह है कि शायद उनमें इन घटनाओं के अर्थ को समझने की क्षमता या सहानुभूति, दोनों की कमी है।

  • दरअसल कुछ लोगों का मानना है कि वे अच्छी तरह जानते हैं कि वे क्या कर रहे हैं। उनका असली सिद्धांत है: “मुझे security मिले, तुम्हें नहीं।” और शायद उनकी रणनीति यही है कि users यह मानते रहें कि “राजनेता इतने मूर्ख या असंवेदनशील हैं,” क्योंकि वही भ्रम उनके काम आता है।