- Die Hackergruppe DDoSecrets hat 410 GB an Heap-Dumps veröffentlicht, die sie vom israelischen Unternehmen TeleMessage erbeutet hat
- TeleMessage entwickelt modifizierte Versionen von Signal, WhatsApp, Telegram und WeChat und bietet Dienste zur Nachrichtenarchivierung an
- Die Daten enthalten Klartextnachrichten, Metadaten und personenbezogene Informationen und werden wegen ihrer Sensibilität nur eingeschränkt an Medien und Forschende verteilt
- TeleMessage behauptete, seine Produkte würden Ende-zu-Ende-Verschlüsselung unterstützen, doch es stellte sich heraus, dass die Architektur diese in der Praxis umgeht
- Zudem kamen Hinweise ans Licht, dass die US-Regierung und Regierungsvertreter sensible Informationen über sicherheitstechnisch anfällige Kanäle geteilt haben
Überblick
- Im Mai 2025 veröffentlichte die Hackergruppe DDoSecrets 410 GB an Heap-Dump-Daten, die sie vom israelischen Unternehmen TeleMessage erlangt hatte
- TeleMessage ist ein Anbieter zentraler Speicher- bzw. Archivierungslösungen für große Messenger wie Signal, WhatsApp, Telegram und WeChat
- Da diese Daten zahlreiche sensible Informationen und personenbezogene Identifikationsdaten (PII) enthalten, werden sie nur an Journalist:innen und Forschende verteilt
Kurzchronologie des Vorfalls
- März: Während der Trump-Regierung lud Nationaler Sicherheitsberater Mike Waltz in einer Signal-Gruppe, in der über Kriegsverbrechen gesprochen wurde, versehentlich einen Journalisten ein. Nach der Berichterstattung darüber fand eine Anhörung im Kongress statt
-
- Mai: Am Tag von Waltz’ Degradierung wurde er dabei beobachtet, wie er TM SGNL, eine von TeleMessage entwickelte modifizierte Signal-Version, nutzte. Zu seinen Gesprächspartnern gehörten hochrangige Personen wie Tulsi Gabbard, JD Vance und Marco Rubio
-
- Mai: Der Quellcode von TM SGNL wurde über GitHub veröffentlicht
-
- Mai: Der Hack von TeleMessage ereignete sich und wurde anschließend von den Medien aufgegriffen
-
- Mai: Ein weiterer Hacker kompromittierte TeleMessage erneut, woraufhin der Dienst eingestellt wurde
-
- Mai: Die Analyse des TM-SGNL-Quellcodes belegte, dass die von TeleMessage behauptete Ende-zu-Ende-Verschlüsselung tatsächlich nicht umgesetzt war. In einem Teil der Hack-Daten wurden Klartext-Chatprotokolle gefunden
-
- Mai: Eine weitere Analyse legte eine Schwachstelle im Archivserver von TeleMessage offen. Über eine bestimmte URL (
archive.telemessage.com/management/heapdump) konnte jede Person einen Java-Heap-Dump herunterladen
Details zum aktuellen Leak
- Die veröffentlichten Heap-Dumps wurden am 4. Mai 2025 gesichert und stammen aus einer Schwachstelle in der von TeleMessage angebotenen Secure-Messaging-Lösung
- Es wurde bestätigt, dass das Produkt seit 2023 von mehreren Einrichtungen einschließlich der US-Regierung genutzt wurde
- Die Daten enthalten umfangreiche Metadaten wie Klartextnachrichten, Absender-/Empfängerinformationen, Zeitstempel und Gruppennamen
- DDoSecrets stellt die für Forschungszwecke nötigen Informationen nach Extraktion und Bereinigung bereit
Auswirkungen und Einordnung
- Der Vorfall hat den Mangel an Vertrauenswürdigkeit von Messaging-Lösungen und operative Nachlässigkeit deutlich gemacht
- Es wurde eine Diskrepanz zwischen dem von TeleMessage beworbenen Sicherheitsniveau und der tatsächlichen Funktionsweise festgestellt
- Dass hochrangige US-Regierungsvertreter vertrauliche Informationen über verwundbare geklonte Messaging-Apps austauschten, unterstreicht die Schwere des Sicherheitsproblems
- Die als SignalGate bezeichnete Affäre dauert derzeit an; weitere Analysen und Reaktionen aus der Security-Community sind zu erwarten
1 Kommentare
Hacker-News-Kommentare
Es wird erwähnt, dass es auf einem Server einen
/heapdump-Endpoint gab und dieser öffentlich Heap-Dumps des Servers auslieferte; dadurch wirke der Vorfall mittlerweile völlig außer Kontrolle geraten. Diese Gruppe habe die Daten nicht wirklich „veröffentlicht“, denn Journalist:innen müssten einen Antrag stellen, um Zugriff zu erhalten. Außerdem werde nicht offengelegt, wie viel tatsächlicher Nachrichteninhalt enthalten sei; stattdessen werde nur die Zahl von 410 GB Dump hervorgehoben, was den Fall noch größer wirken lasse.Man solle sich vorstellen, unzuverlässige Software noch schlechter zu machen und dann auch noch kostenpflichtig anzubieten. Sowohl aus Sicht des Unternehmens als auch der Nutzer sei das beschämend.
Der wichtige Punkt sei, dass nur die Zahl 410 GB genannt werde, ohne offenzulegen, wie viel davon tatsächlich relevante Daten seien. Der Kommentierende habe kürzlich einen ähnlich großen Dump geprüft, der in Wirklichkeit fast nur aus OS-Paket-Update-Caches und Logs bestanden habe. Wichtige Daten habe es überhaupt nicht gegeben. Die Größe eines Heap-Dumps lasse sich leicht reduzieren; dass man einfach alles herausgegeben habe, wirke verdächtig. Natürlich sei auch denkbar, dass aus einem 512-GB-Dump bereits wichtige Daten herausgefiltert worden seien.
Es sei weit verbreitet zu glauben, die meisten israelischen Softwarefirmen bestünden aus brillanten Ex-Mossad-Leuten, aber in der Realität sei es wohl nicht so beeindruckend. Man hoffe, dass in diesem Nachrichten-Dump interessante Inhalte stecken.
Es sehe so aus, als habe jemand bei einer Java-Anwendung versehentlich sämtliche JMX-Endpoints per HTTP exponiert. Das sei keine Standardeinstellung, daher wirke es wie ein einfacher Flüchtigkeitsfehler.
Es sei unklar, ob es sich um einen Server-Heap-Dump oder um einen Heap-Dump für Clients handle. Vielleicht sei das absichtlich für den Fall eingebaut worden, dass der Client abstürzt und Logs hinterlässt.
Die LinkedIn-Selbstbeschreibung des TeleMessage-CEO wirke, als sei sie schlecht von einer KI automatisch generiert worden. Sie bestehe nur aus abgedroschenen Formulierungen wie strategische Innovation, ethische Werte, SaaS, M&A und Branchenführerschaft.
Das wirke wirklich wie furchtbar schlechtes Schreiben im typischen LinkedIn-Stil.
Zusammengefasst klinge es wie: „Ich bin CEO. Unsere Firma ist SaaS. Ich bin CEO.“
Seit der TeleMessage-Vorfall öffentlich geworden sei, seien einige Wochen vergangen; man frage sich, ob die Signal Foundation inzwischen eine offizielle Stellungnahme abgegeben habe. Es wirke wie ein doppelter Maßstab, wenn bei Open-Source-Third-Party-Clients unter Verwendung des Namens Signal mit Markenklagen gedroht werde, aber geschwiegen werde, wenn ein Rüstungsunternehmen denselben Namen verwende.
Ein Standpunkt sei, dass viele Organisationen in den USA derzeit absichtlich stillhalten, weil sie Angriffe der Regierung fürchten. Außerdem habe Moxie, der früher den Kern der Signal Foundation ausgemacht habe, die Organisation inzwischen verlassen und sei als prägende Figur verschwunden; dadurch sei unklar geworden, wofür die Organisation heute eigentlich stehe.
Signal treffe in diesem Fall keinerlei Schuld. Das Problem liege vielmehr bei TeleMessage und bei den Verantwortlichen, die sich für deren Nutzung entschieden hätten. Selbst wenn Signal etwas dazu sagen würde, würde es dafür nur Kritik ernten und nichts gewinnen.
So wie ein früherer Signal-FOSS-Fork rechtlich abgemahnt worden sei, frage man sich, ob Molly noch betrieben werde oder ob es inzwischen allgemein selbst hostbare Server gebe.
Man sei zwar unzufrieden mit dem Streit zwischen moxie und fdroid, aber dieser Vorfall gehe weit darüber hinaus: Es gehe um Staatsmacht und Missstände und damit um mehr als die Probleme einer Einzelperson oder eines Unternehmens. Wenn die Regierung eines anderen Landes irgendeine unbekannte ausländische Software als nationales Kommunikationsmittel eingesetzt hätte, hätte man ihr wohl Inkompetenz vorgeworfen.
Man verstehe die Notwendigkeit, Namen und Marken zu schützen. Auch wenn man Open Source forke, könne man nicht einfach Marke und Namen des Originals frei verwenden. Selbst wenn man die Open-Source-Version von Firefox oder VSCode forked, dürfe man dem Klon wegen des Markenrechts nicht einfach den ursprünglichen Namen geben.
Auch wenn der Signal-Fork miserabel gewesen sei, sei er immerhin legal gewesen. Umso schockierender sei, dass dieses Unternehmen sogar geknacktes WhatsApp verkauft habe. Kaum zu glauben, dass Behörden und Regierungen tatsächlich Kunden für so ein Produkt gewesen seien. Ein Link werde ebenfalls beigefügt.
Es werde gefragt, warum das illegal sein solle. Anders als im Fall Beeper sehe das US-Justizministerium Verbote privater Clients teils sogar kritisch; daher werde gefragt, ob WhatsApp hier anders liege. Das WhatsApp-Archivierungsprodukt scheine tatsächlich Patches auf dem WhatsApp des Nutzers zu installieren; das könne sicherheitstechnisch problematisch sein, sei aber nicht zwingend illegal.
Aus Erfahrung auf den globalen Finanzmärkten wird berichtet, dass Global Relay und TeleMessage dort wichtige Anbieter von Kommunikationslösungen für Compliance-Zwecke seien.
Im eigenen Unternehmen seien die Aufgaben deutlich weniger kritisch, trotzdem gebe es zweimal im Jahr externe Penetrationstests. Man frage sich, wie ein derart unverantwortlicher Fehler überhaupt legal möglich sein könne.
Der Grund sei vermutlich, dass Software Engineering nicht mit dem Ernst echter Ingenieurdisziplinen behandelt werde. Wenn ein Vorfall passiere, seien zum Beispiel auch die daraus folgenden Verantwortlichkeiten begrenzt.
Vermutlich sei es tatsächlich nicht legal gewesen. Man habe gehört, dass es Hinweise auf eine gefälschte SOC2-Zertifizierung gebe.
„Heapdump“ sei ein Begriff, den man vor 15 Jahren beim Debuggen von Android-Apps kennengelernt habe. Es handle sich um einen Speicher-Schnappschuss eines Java-Prozesses, daher sei es unvermeidlich, dass Klartext darin auftauche. Die eigentliche Frage sei, warum solche Heaps über einen offenen HTTP-Endpoint erreichbar gewesen seien. Vielleicht sei der Pfad im Client-Code hartkodiert gewesen oder anhand des Request-Musters erkennbar geworden. Über Backend-Architektur oder Nachrichtenspeicherung lasse sich daraus nicht viel ableiten; man frage sich, ob man selbst irgendetwas übersehe.
Einen
/heapdump-Endpoint ohne Authentifizierung in einer Produktionsumgebung bereitzustellen, sei ein Anfängerfehler. Bei einem Dienst, der sensible Regierungskommunikation verarbeitet, sei das noch gravierender. Auch der Einsatz veralteter Technologien wie MD5-Hashes und JSP zeige mangelndes Verständnis für Sicherheit. Dieser Vorfall sei ein typisches Beispiel dafür, warum Defensive Security und regelmäßige Audits unverzichtbar seien.next.jsunsichere, nicht authentifizierte Endpoints bauen.Wenn Abgeordnete wieder einmal ein Verbot von E2E-Verschlüsselung oder Backdoors fordern, könne man diesen Vorfall als gutes reales Beispiel anführen.
Da die Daten sensibel seien und viele PII enthielten, teile DDoSecrets sie nur mit Journalist:innen und Forschenden. Der Kommentierende befürworte normalerweise Responsible Disclosure, glaube hier aber, dass vielleicht ein schmerzhafterer und folgenreicherer Leak nötig sein könnte. Diktatoren oder Oligarchen kümmerten sich selbst dann wenig, wenn sie gehackt würden, und würden weiter ähnliche Werkzeuge einsetzen; erst wenn die betroffene Bevölkerung wütend werde, könne sich etwas ändern. Aufgrund des Sicherheitsversagens sei die Öffentlichkeit schlechter geschützt. Selbst wenn Medien oder Forschende versuchten zu berichten, könnten sie in autoritären Gesellschaften leicht zum Schweigen gebracht werden, sodass niemand das wahre Ausmaß erfahre. Mächtige Akteure könnten Repression dann weiter rechtfertigen, ohne Widerstand oder Konsequenzen zu fürchten. Wäre es nur ein gewöhnlicher Unternehmensvorfall, würde man Responsible Disclosure bevorzugen; zur Verhinderung von Diktatur müsse man die Sache aber anders betrachten.
Inzwischen müsse man Journalist:innen oft gar nicht mehr aktiv zum Schweigen bringen. Viele Menschen glaubten ohnehin anonymen Social-Media-Konten oder politischen Influencern als Quellen; selbst wenn etwas aufgedeckt werde, werde es leicht als „Fake News“ abgetan. Wenn genügend Wähler:innen darauf hereinfielen, verliere die Enthüllung weitgehend ihre Wirkung.
Es wirke gefährlich zu denken, man müsse Schäden in Kauf nehmen, um die Bevölkerung für schlechte Regierungsführung wachzurütteln. Wenn diese Vorstellung ins Extreme kippe, könne sie am Ende noch größere Gewalt oder mehr Leid rechtfertigen. Es sei riskant, in ein Denkmuster zu geraten, nach dem Menschen erst durch größeren Schmerz aufwachen.
Bei einer tatsächlichen Veröffentlichung könnten die Folgen zudem nicht die führenden Personen treffen, sondern interne Informanten gefährden. Wenn etwa Logs sensible Informationen über Quellen oder Agent:innen enthielten, könne das Leben kosten.
Unter Verweis auf den früheren australischen Cabinet-Leak wird erklärt, ein Rundfunksender habe den Großteil der Informationen an die Regierung zurückgegeben und damit faktisch zur Vertuschung beigetragen. Dadurch seien wichtige Tatsachen, die die Öffentlichkeit hätte kennen müssen, verborgen geblieben, was erhebliche politische Auswirkungen gehabt habe; Signalgate wirke in dieser Hinsicht ähnlich. Unabhängig von Parteien sei entscheidend, dass die Bevölkerung ein Recht auf mehr Informationen habe.
Es wirke ironisch, dass Politiker dafür lobbyieren, Kommunikationssoftware mit Backdoors zu versehen, und dann selbst Opfer derselben Art von Angriff werden. Leider scheine es ihnen an Fähigkeit oder Empathie zu fehlen, die Bedeutung dieser Kette von Vorfällen wirklich zu verstehen.