La vulnerabilidad de Telegram Desktop permitía robar archivos de cualquier usuario

Artículo original ↗ Discusión en Hacker News ↗

Un fallo corregido recientemente en el cliente de escritorio de Telegram permitía que un único enlace pulsado exfiltrara cualquier archivo accesible para el usuario en la máquina y secuestrara la cuenta de Telegram de la víctima, reavivando las alarmas sobre la postura de seguridad de la app. Los comentaristas contraponen la UX pulida de Telegram y sus potentes funciones para grupos/canales con su falta de cifrado de extremo a extremo por defecto, su identidad basada en número de teléfono y su infraestructura opaca, y a menudo prefieren alternativas como Signal o WhatsApp para la privacidad. El incidente también alimenta críticas más amplias a los sistemas operativos de escritorio que permiten a las apps leer todos los archivos del usuario por defecto, y motiva llamamientos a un aislamiento más fuerte y a modelos de amenaza más cautelosos, especialmente dadas las sospechas sobre los vínculos de Telegram con intereses rusos.

Alcance y gravedad del error de Telegram Desktop

  • Los comentaristas subrayan que, más allá de la toma de control de la cuenta, el fallo permitía la exfiltración de cualquier archivo accesible para el usuario (claves SSH, almacenes del navegador, credenciales de la nube, etc.).
  • La causa raíz se describe como un esquema interno de URL oculto que podía subir archivos arbitrarios, creado para facilitar la publicación de lanzamientos de Telegram.
  • Algunos consideran esta “funcionalidad” asombrosamente temeraria; otros señalan que explotarla requería una cadena algo enrevesada.

Diseño del sistema operativo, aislamiento y culpas

  • Un punto de vista: esto refleja un problema más amplio de los sistemas operativos de escritorio, donde cualquier proceso de usuario puede leer cualquier archivo del usuario; las apps deberían estar aisladas en directorios por aplicación.
  • Contraargumento: esta es claramente una vulnerabilidad específica de Telegram; la mayoría de las apps no suben archivos arbitrarios en secreto.
  • Se mencionan múltiples mecanismos de aislamiento: unveil de OpenBSD, bubblewrap de Linux, SELinux, sandboxes de Flatpak, macOS y Windows Store, jails de FreeBSD, máquinas virtuales al estilo Qubes.
  • Varios usuarios ya aíslan navegadores/Telegram mediante firejail, máquinas virtuales, usuarios separados o Flatpak, pero señalan que los sandboxes opcionales solo ayudan cuando las apps los usan.

La postura de seguridad y las decisiones de diseño de Telegram

  • Muchos reiteran que a Telegram se le critica desde hace tiempo por ser “inseguro por diseño”: sin E2EE por defecto, identidad basada en el número de teléfono, servidor cerrado, elecciones criptográficas extrañas y bugs polémicos del pasado.
  • Críticas a que los clientes de escritorio todavía no soportan bien los chats secretos y a que supuestamente algunos ajustes se vuelven a activar sin avisar.
  • Algunos sostienen que Telegram no debería considerarse un “mensajero seguro” en absoluto; otros dicen que todos los clientes complejos tienen fallos.

Por qué la gente sigue usando Telegram

  • Mucho elogio para la UX de Telegram: herramientas potentes para grupos, bots, formato, transcripción de voz, paridad multiplataforma y almacenamiento en la nube prácticamente ilimitado.
  • Algunos aceptan los compromisos de seguridad porque ven a las agencias de inteligencia como una amenaza menor que los intermediarios de datos ad-tech, o porque todos con quienes necesitan contactar están allí.
  • Otros dicen que lo usan sobre todo para canales públicos, clubes y makerspaces, donde la falta de E2EE importa menos.

Modelos de amenaza, geopolítica y confianza

  • Desconfianza profunda de los vínculos de Telegram con Rusia y Dubái; algunos lo ven como un probable o de facto honeypot de inteligencia.
  • Otros rechazan juzgarlo solo por el país de origen, pero siguen preocupados por la retención centralizada de todo el contenido y los metadatos.
  • Contraste con Signal y, en menor medida, WhatsApp: E2EE por defecto, clientes abiertos (en el caso de Signal) y modelos de negocio distintos se consideran materialmente mejores.

E2EE, aplicaciones web y actualizaciones

  • Largo subhilo sobre si el E2EE real es posible en apps web:
    • Un lado: los clientes basados en navegador no pueden fijarse ni auditarse independientemente por usuario; el servidor puede sustituir el código en silencio, socavando toda la idea de no confiar en el servidor.
    • El otro lado: las apps nativas con actualizaciones automáticas afrontan un riesgo similar; la seguridad real también depende de los modelos de actualización/firma y del compromiso del dispositivo.
  • Algunos señalan que los envoltorios de escritorio estilo Electron al menos pueden verificarse por hash y construirse de forma reproducible, a diferencia del código web en vivo.

Lecciones más amplias sobre permisos de aplicaciones

  • Llamamientos repetidos a dejar de permitir que apps arbitrarias, por defecto, lean todo el directorio home y hagan conexiones de red sin restricciones.
  • Sugerencias: controles a nivel del sistema operativo, amigables para el usuario, sobre el acceso al sistema de archivos y a la red; modelos de denegación por defecto con exclusiones claras; y tratar las apps comerciales de código cerrado (Zoom, Steam, Dropbox, Telegram) como no confiables y siempre aisladas.