- El grupo de hackers DDoSecrets publicó 410 GB de heap dumps obtenidos mediante un hackeo a la empresa israelí TeleMessage
- TeleMessage desarrolla versiones modificadas de Signal, WhatsApp, Telegram y WeChat para ofrecer servicios de archivado de mensajes
- Los datos incluyen mensajes en texto plano, metadatos e información personal, por lo que su distribución está restringida a periodistas e investigadores
- Aunque TeleMessage afirmaba que su producto soportaba cifrado de extremo a extremo, se reveló que en realidad estaba diseñado para eludirlo
- También salieron a la luz indicios de que funcionarios y entidades del gobierno de EE. UU. compartieron información sensible a través de canales vulnerables desde el punto de vista de seguridad
Resumen general
- En mayo de 2025, el grupo de hackeo DDoSecrets publicó 410 GB de heap dumps obtenidos de la empresa israelí TeleMessage
- TeleMessage es un proveedor de soluciones de almacenamiento centralizado (archivo) para mensajeros principales como Signal, WhatsApp, Telegram y WeChat
- Como estos datos contienen gran cantidad de información sensible e información de identificación personal (PII), su distribución está limitada a periodistas e investigadores
Línea de tiempo resumida del incidente
- Marzo: durante la administración Trump, el asesor de seguridad nacional Mike Waltz invitó por error a un periodista a un grupo de Signal donde se discutían conversaciones relacionadas con crímenes de guerra. Tras la cobertura del caso, se llevó a cabo una audiencia en el Congreso
- 1 de mayo: el día en que Waltz fue degradado de cargo, fue visto usando TM SGNL, una versión modificada de Signal creada por TeleMessage. Entre sus interlocutores estaban Tulsi Gabbard, JD Vance y Marco Rubio, entre otros altos funcionarios
- 3 de mayo: el código fuente de TM SGNL fue publicado a través de GitHub
- 4 de mayo: ocurrió el hackeo a TeleMessage, y el hecho fue reportado por la prensa
- 5 de mayo: otro hacker volvió a comprometer TeleMessage, lo que provocó la interrupción del servicio
- 6 de mayo: el análisis del código fuente de TM SGNL demostró que el supuesto cifrado de extremo a extremo que afirmaba TeleMessage en realidad no estaba aplicado. En parte de los datos hackeados se confirmaron logs de chat en texto plano
- 18 de mayo: un análisis adicional reveló una vulnerabilidad en el servidor de archivo de TeleMessage. Cualquiera podía acceder a una URL específica (
archive.telemessage.com/management/heapdump) y descargar un heap dump de Java
Detalles de esta filtración
- Los heap dumps publicados fueron obtenidos el 4 de mayo de 2025 y se originan en una vulnerabilidad de la solución de mensajería segura ofrecida por TeleMessage
- Se confirmó que el producto fue utilizado desde 2023 por varias entidades, incluido el gobierno de EE. UU.
- Los datos incluyen mensajes en texto plano, información del remitente y destinatario, marcas de tiempo y nombres de grupos, entre otros metadatos abundantes
- DDoSecrets está ofreciendo información extraída y depurada para fines de investigación
Impacto e implicaciones
- Este incidente puso sobre la mesa la falta de confiabilidad de la solución de mensajería y sus deficiencias operativas
- Se confirmó una discordancia entre el nivel de seguridad publicitado por TeleMessage y su funcionamiento real
- Quedó en evidencia que altos funcionarios del gobierno de EE. UU. intercambiaron información confidencial mediante apps clonadas de mensajería vulnerables, lo que subraya un grave problema de seguridad
- Esta crisis, conocida como SignalGate, sigue en desarrollo y se espera que continúen los análisis y la respuesta de la comunidad de seguridad
1 comentarios
Opinión en Hacker News
Mencionan que había un endpoint
/heapdumpen un servidor y que este exponía públicamente el heap dump del servidor; da la impresión de que este incidente se salió totalmente de control. Señalan que el grupo en realidad no “publicó” los datos como tal, sino que los periodistas deben enviar una solicitud para poder acceder. También apuntan que no revelan cuánto contenido real de mensajes hay y solo enfatizan la cifra de 410 GB de dumps, lo que hizo que el tema ganara aún más atención.Dice que imaginen tomar un software ya poco confiable, empeorarlo todavía más y además cobrar por ello. Le parece vergonzoso tanto desde la perspectiva de la empresa como de los usuarios.
Cree que el punto importante es justamente que mencionan la cifra de 410 GB sin aclarar cuánto de esos datos es realmente relevante. Cuenta que recientemente revisó un dump grande parecido y que, en la práctica, no contenía más que cachés de actualizaciones de paquetes del sistema operativo y logs; no había ningún dato importante. Añade que el tamaño de un heap dump puede reducirse fácilmente, así que el hecho de que hayan soltado todo así le parece sospechoso. Aun así, considera posible que del dump de 512 GB ya se haya filtrado lo importante.
Dice que suele existir la percepción de que la mayoría de las empresas de software israelíes están formadas por brillantes exintegrantes del Mossad, pero que en la práctica no están a la altura de esa expectativa. Espera que haya contenido interesante en este dump de mensajes.
Parece que alguien, al usar una aplicación Java, expuso por error todos los endpoints de JMX vía HTTP. Como no es la configuración predeterminada, piensa que fue simplemente un descuido.
Se pregunta si se trata de un heap dump del servidor o de un cliente. Si fuera del cliente, tal vez pudo haber sido algo intencional para dejar registros cuando la app se cae.
Le da la impresión de que la descripción de LinkedIn del CEO de TeleMessage fue autogenerada torpemente por inteligencia artificial, llena únicamente de frases hechas como innovación estratégica, valores éticos, SaaS, fusiones y adquisiciones, y liderazgo de la industria.
Cree que es una redacción realmente pésima, muy al estilo LinkedIn.
En resumen, le suena a: "Soy CEO. Nuestra empresa es SaaS. Soy CEO" repetido una y otra vez.
Han pasado varias semanas desde que se hizo público el caso de TeleMessage y se pregunta si la Signal Foundation ha emitido una postura oficial. Le inquieta el doble rasero de advertir con demandas de marca cuando aparece un cliente open source de terceros usando el nombre Signal, pero guardar silencio cuando un contratista de defensa usa ese mismo nombre.
Hay quien sostiene que hoy muchas organizaciones en Estados Unidos permanecen calladas y discretas porque temen ataques del gobierno. También cree que, desde que Moxie, figura central de Signal Foundation, dejó la organización y perdió presencia, ya no está claro qué busca actualmente la institución.
Piensa que Signal no tuvo ninguna culpa en todo esto; más bien el problema es de TeleMessage y de quienes decidieron usarlo. Considera que, aunque Signal dijera algo, solo recibiría críticas y no serviría de mucho.
Se pregunta si, como ocurrió con antiguos forks FOSS de Signal que recibieron advertencias legales, Molly sigue funcionando hoy o si existen servidores que en general puedan autohospedarse.
Aunque le molestó la disputa entre moxie y fdroid, considera que este incidente va más allá: involucra poder estatal y corrupción, y es un asunto importante que supera a una sola persona o empresa. Añade que si el gobierno de otro país usara como herramienta nacional de comunicación un software extranjero del que nadie ha oído hablar, seguramente lo tacharían de incompetente.
Está de acuerdo con la necesidad de proteger el nombre y la marca. Explica que, aunque el software sea open source y alguien lo forkee, no puede usar libremente la marca ni el nombre del autor original. Destaca que, por ejemplo, aunque se haga un fork de la versión open source de Firefox o VSCode, por temas de marca registrada no se le puede poner el nombre original a la copia.
Aunque el fork de Signal haya sido pésimo, al menos era legal; lo que realmente le impacta es que esta empresa también estuviera vendiendo un WhatsApp crackeado. Le cuesta creer que los clientes de un producto así fueran agencias e incluso gobiernos. También adjunta un enlace.
Se pregunta por qué eso sería ilegal. A diferencia del caso de Beeper, dice que el Departamento de Justicia de EE. UU. a veces no ve con buenos ojos prohibir clientes de terceros, así que pregunta si WhatsApp sería distinto. Sostiene que WhatsApp archiver parece funcionar instalando un parche sobre el WhatsApp del usuario, y que aunque eso podría traer problemas de seguridad, no sería necesariamente ilegal.
Comparte que, en los mercados financieros globales, Global Relay y TeleMessage son efectivamente proveedores importantes de soluciones de comunicación para fines de compliance.
Su empresa maneja tareas mucho menos importantes, pero aun así recibe pruebas de penetración externas dos veces al año. Se pregunta cómo puede ser legal un error tan irresponsable como este.
Cree que la razón es que la ingeniería de software no se toma en serio como una ingeniería real. Por ejemplo, la responsabilidad que se asume cuando ocurre un accidente es en sí bastante limitada.
Considera que en realidad quizá ni siquiera era legal. Dice haber oído indicios de que también habrían falsificado su SOC2.
"Heapdump" es un término que conoció hace 15 años mientras depuraba apps de Android. Explica que es una instantánea de memoria de un proceso Java, así que es inevitable que contenga texto plano. Lo importante, dice, es por qué esos heaps estaban expuestos a través de un endpoint HTTP abierto. Supone que probablemente estaba hardcodeado en el código cliente o que lo dedujeron viendo el patrón de solicitudes. Añade que con esa información no es fácil entender la arquitectura del backend ni cómo se almacenaban los mensajes, y se pregunta si se le está escapando algo.
Cree que exponer un endpoint
/heapdumpsin autenticación en producción es un error de principiante, y aún más grave en un servicio que maneja comunicaciones sensibles del gobierno. El uso de tecnologías antiguas como hashes MD5 y JSP también revela una pobre comprensión de seguridad. Dice que este caso es un ejemplo clásico de por qué la seguridad defensiva y las auditorías periódicas son indispensables.next.jstambién se pueden crear endpoints vulnerables sin autenticación.Cree que cuando los legisladores intentan prohibir el cifrado e2e o exigir backdoors, este incidente podría usarse como un buen ejemplo real.
Dado que los datos son sensibles y contienen mucha PII, sobre el hecho de que DDoSecrets solo los comparta con periodistas e investigadores, dice que normalmente apoya la divulgación responsable, pero que en este caso quizá haría falta una filtración más dolorosa y contundente. Sostiene que a los dictadores y oligarcas no les importa demasiado que los hackeen y seguirán usando herramientas parecidas; solo cuando la población afectada se indigne podrá producirse un cambio. Considera que, por este fracaso de seguridad, la inteligencia de la ciudadanía quedó menos protegida. Incluso si periodistas o investigadores intentan informar, en una sociedad autoritaria pueden ser silenciados fácilmente, dejando a todos sin saber qué ocurre realmente. Así, quienes tienen el poder pueden seguir justificando la represión sin resistencia ni consecuencias. Dice que si se tratara de un simple incidente de seguridad empresarial preferiría una divulgación responsable, pero que para frenar una dictadura la situación es distinta.
Hoy en día ni siquiera hace falta silenciar a los periodistas. Ya hay mucha gente que confía en cuentas anónimas de redes sociales o en influencers políticos como fuente de información, así que aunque se revele algo, basta con desecharlo como “fake news”; si suficientes votantes se dejan engañar, al final no pasa gran cosa.
Dice que le parece peligrosa la idea de que haya que aceptar daños para hacer reaccionar a la población frente a un mal gobierno. Advierte que, llevada al extremo, esa forma de pensar puede terminar justificando violencia o sufrimiento aún mayores. En general, cree que asumir que solo hiriendo más a la gente esta despertará es una lógica peligrosa.
Advierte que, si se publicara realmente todo, el daño podría no recaer en los líderes sino en fuentes internas. Por ejemplo, si en los logs hubiera información sensible sobre agentes o informantes, sus vidas podrían correr peligro.
Menciona la filtración del Cabinet de Australia y explica que una cadena de televisión ayudó a encubrir parte del tema al devolver al gobierno la mayor parte de la información. Dice que ese tipo de manejo termina ocultando hechos importantes que la ciudadanía debería conocer y que habrían tenido un fuerte impacto político; piensa que esta Signalgate es parecida. Subraya que, independientemente del partido, es importante que la población tenga acceso a más información.
Le parece irónico que políticos que hacen lobby para convertir el software de comunicación en algo con backdoors terminen siendo víctimas de hackeos exactamente del mismo tipo. Lamenta que, al parecer, no tengan la capacidad ni la empatía necesarias para entender lo que realmente significan estos hechos.