Fuente: w3m https://kibty.town/blog/todesktop/
Traducción:
Esto empezó cuando estaba mirando cursor, un editor con inteligencia artificial. Yo uso lulu por visión de objetos en mi laptop, así que cuando descargué el instalador de cursor obtuve este pop-up:
Una alerta de LuLu, mostrando que “Install Cursor” estaba intentando conectarse a “https://download.todesktop.com”
Ahora, ¿qué es todesktop? Pensé que estaba descargando cursor. Mirando en su sitio aparenta ser un servicio bundler[1] además de proveer un SDK[2] para aplicaciones de electron. Así que aparentemente el instalador que descargué está en realidad controlado por todesktop, no cursor.
Esto me despertó la curiosidad y me cree una cuenta en todesktop para investigar, y cuando apreté el botón de login de GitHub, vi mi llamada a Firebase.
Cuando me dí cuenta que la aplicación usaba firestore (es una base de datos no-sql de firebase que es frecuentemente usada en frontend), rápidamente abrí mi devtools(F12 o Control+Shift+i en cualquier navegador) y empecé a hacer basic recon[3] en el firebase.
Me dí cuenta que el sitio tenía sourcemaps, que hicieron que la búsqueda de todos las rutas de firestore usadas en aplicación sea más fácil (sigue siendo fácil sin los sourcemaps)
Luego encontré una colección insegura, temporaryApplications, que parecía darme una lista de nombres de algunas aplicaciones (edito: todesktop aclaró que esta colección no tiene información sensible y no fue actualizada desde el 2022), pero no encontré más que eso, todo parecía seguro en el firebase salvo de eso.
Me dí cuenta de que la mayoría del deployment y la lógica general pasa en la terminal con el paquete de npm llamado: @todesktop/cli
, así que lo instalé y comencé a investigarlo.
El cli (command line interface) administra deployments, subida de código de fuente, y mucho más. La página parece ser una shell para crear aplicaciones, ver deployments, etc etc.
Yo fui otra vez suertudo que el cli también tenía sourcemaps, así que usé el sourcemapper para extraerlos en un árbol source.
Observando ahí, encontré una vulnerabilidad arbitraria s3 a través de una función de firebase llamada getSignedURL
, pero no tenía una clave s3 (ruta de archivo) para subir a eso haría algo interesante, así que seguí buscando.
Quería obtener acceso a la máquina en donde la aplicación se construye y la forma más fácil de hacerlo es a través de un script postinstall en el package.json
, así que hice eso con un simple reverse shell payload
.
Esto funcionó. Navegando a través del contenedor, descubrí donde estaba vivía el código de compilación de la aplicación y encontré esto:
Encontré el código para descifrar este archivo, y esto es lo que obtuve luego de descifrarlo:
Un archivo llamado “config.json” con 2 id de apple, firma remota y credenciales hsm. Este contenedor guarda los secretos.
Investigando más en el contenedor, encontré una clave de administrador de firebase hardcodeada (que estaba completa).
Rápidamente me dí cuenta que con las credenciales que tengo, puedo deployar una actualización automática a cualquier aplicación que quiera, y que los clientes reciban la actualización inmediatamente al reiniciar la aplicación.
Luego hice un código para usar mis credenciales para deployar una actualización a mi aplicación, y funcionó. Inmediatamente recibí la actualización en mi cliente de mi aplicación y obtuve un Remote Code Execution.
Con esto podría publicar actualizaciones automáticas a todas las aplicaciones que usan todesktop, como por ejemplo:
(Por favor no acoses a esas empresas o hacerlo ver como si fuera su culpa, ellos no la tienen, si alguien acá tiene la culpa es todesktop.)
Si hago una estimación probablemente está en el rango de miles de millones de personas en el entorno de tecnología, otros hackers, programadores, ejecutivos, etc. Haciendo que este exploit sea mortal si es usado.
Usé mis contactos para comunicarme con el creador de todesktop, chateamos por signal y el arreglo llegó de inmediato, ellos fueron lo suficientemente amables para compensarme por mis esfuerzos y fueron muy amables.
El contenedor build ahora tiene un privilegiado “sidecar”(acompañante)[5] que hace el firmado, y la subida y todo lo demás en vez de que esta lógica esté en el código de usuario del contenedor principal.
Los incidentes de seguridad pasan todo el tiempo, es natural. Lo que impora es la respuesta de la empresa, y la respuesta de todesktop fue buenísima.
Mirá el reporte de todesktop acá: https://www.todesktop.com/blog/posts/security-incident-at-todesktop
Privileged Sidecar: Un Privileged Sidecar es un tipo de contenedor que se ejecuta con privilegios de root (o con permisos elevados) en el host que lo ejecuta.