El “cifrado de extremo a extremo” suena a garantía infalible. Como si por usar una app que lo promete ya pudieras dormir tranquilo. Pero la realidad es otra.
El caso TeleMessage demuestra que el verdadero peligro no siempre está en el algoritmo, sino en lo que lo rodea: la arquitectura, las configuraciones y el desarrollo.
Todo comenzó con una foto
Durante una reunión del gabinete de Trump, una imagen tomada por Reuters mostraba al asesor de seguridad nacional Mike Waltz usando lo que parecía Signal. Pero no era Signal. Era TM SGNL, una app desarrollada por TeleMessage, una empresa israelí contratada por el gobierno de EE.UU.
TM SGNL estaba diseñada como una alternativa “segura” a Signal, pensada para usos corporativos y gubernamentales. Pero esa supuesta seguridad era más una promesa de marketing que una realidad.
El descubrimiento: cifrado inexistente en los servidores
El periodista especializado en ciberseguridad Micah Lee investigó TM SGNL y lo que encontró fue alarmante: los mensajes, en lugar de mantenerse cifrados de extremo a extremo, eran subidos en texto plano a servidores gestionados por TeleMessage. Desde ahí se reenviaban al destinatario.
El marketing de la empresa aseguraba que los mensajes estaban cifrados “hasta el archivo corporativo”, pero en la práctica, esos archivos eran completamente legibles en sus servidores.
Peor aún: ese servidor estaba alojado en AWS, gestionado por una empresa dirigida por un exespía israelí, y tenía acceso a registros de otras plataformas como WhatsApp, Signal, Telegram y WeChat, archivados por sus clientes gubernamentales y corporativos.
El hackeo: fácil, rápido y silencioso
Una fuente anónima explicó cómo logró vulnerar TeleMessage. El proceso fue tan simple que, en un primer momento, los periodistas decidieron no revelar los detalles para evitar imitaciones. Semanas después, con el sistema ya desactivado, publicaron todo:
- Panel de administración accesible: Las contraseñas se “protegían” usando MD5 en el lado del cliente, lo que convertía el hash en la contraseña misma.
- Uso de JSP: Una tecnología anticuada (de principios de los 2000) que ya indica una arquitectura poco moderna.
- Exploración de rutas con feroxbuster: Herramienta que permite descubrir endpoints ocultos.
- Acceso al endpoint /heapdump: Este endpoint expuesto públicamente en producción devolvía un volcado de memoria de 150 MB, incluyendo credenciales, tokens, y chats completos.
Con esa información, el atacante accedió a cuentas de clientes como la Oficina de Aduanas y Protección Fronteriza (CBP) y afirmó haber leído conversaciones internas de Coinbase. Aunque Coinbase declaró que no hubo fuga de datos críticos, el simple acceso a su backend ya era un riesgo grave.
El verdadero problema: la arquitectura
Más allá de las decisiones técnicas cuestionables, el mayor error fue conceptual: una arquitectura débil que priorizó funcionalidades sobre seguridad. El uso de Spring Boot con su módulo Actuator mal configurado, dejando endpoints sensibles abiertos sin autenticación, evidencia la falta de buenas prácticas de seguridad.
El endpoint /heapdump, por ejemplo, está documentado como uno de los errores más comunes en entornos Spring. Nunca debería estar habilitado en producción, y mucho menos sin protección.
Lecciones que toda empresa debería aplicar
Este caso deja claro que el problema no es solo qué cifrado usas, sino cómo lo implementas y proteges tu infraestructura. Algunas preguntas clave:
- ¿Tus aplicaciones exponen endpoints sensibles sin autenticación?
- ¿Tus contraseñas se almacenan con algoritmos robustos y salting?
- ¿Tu tecnología está actualizada y sigue buenas prácticas de seguridad?
- ¿Realizas auditorías externas y pruebas de penetración periódicas?
No importa qué tan avanzada sea tu tecnología si todo el entorno en el que vive está lleno de fallos. Una buena arquitectura, controles de acceso, monitorización y auditorías constantes son lo que realmente protege tus datos.
No confíes en una app solo porque lo dice su web. Confía cuando sabes cómo está hecha
