Tensorlake y GitHub Actions: secretos sondeados

Tensorlake admitió este domingo que un atacante llegó hasta sus repositorios de GitHub y disparó GitHub Actions para sondear los secretos guardados en sus flujos de trabajo. La plataforma vende entornos aislados para ejecutar código generado por agentes de inteligencia artificial. Su fundador, Diptanu Choudhury, lo contó en un mensaje publicado en X el 8 de noviembre, con una admisión poco común en este tipo de avisos.

El dato incómodo viene después. El proveedor que aloja una aplicación interna de la empresa sufrió una brecha hace un par de semanas, y esa brecha expuso las variables de entorno de Tensorlake. Las variables de entorno son los valores de configuración que una aplicación lee al arrancar, a veces tan sensibles como una clave de acceso. La empresa no las rotó. La aplicación no era crítica para producción, razonó el equipo, y ese juicio dejó la puerta abierta.

Esa aplicación interna crea entornos aislados dentro de las cuentas del equipo de ingeniería y corre automatizaciones. Esos entornos tenían acceso a los repositorios de GitHub de la compañía, el lugar donde vive su código. Con ese acceso, el atacante subió código malicioso a ramas de los repositorios y disparó GitHub Actions, el sistema de automatización de GitHub, para sondear qué secretos podían alcanzar los flujos encargados de construir y desplegar el software.

La etiqueta de «no crítica» salió cara

Choudhury lo escribió sin rodeos: fue un descuido y debieron actuar de inmediato. El registro del incidente de pwn.watch añade un matiz que conviene conocer: la primera versión del mensaje nombraba al proveedor, Railway; las ediciones posteriores del mismo texto lo dejaron en un genérico «proveedor». La empresa no ha publicado todavía una nota en su centro de confianza con la lista de repositorios tocados.

La respuesta llegó el mismo día de la divulgación. Tensorlake rotó todos sus secretos, retiró la aplicación interna del proveedor y avisó por correo a los clientes de pago. Al resto le pidió rotar sus claves API de Tensorlake por precaución abundante, la expresión del propio fundador. Y marcó un límite claro: no hay impacto en la información de los clientes, ni en sus claves API ni en sus entornos, y no existe evidencia de que el acceso pasara del sondeo de secretos a sistemas críticos.

Ese límite también define lo que falta. La divulgación no dice cuántos repositorios recibieron código del atacante, cuántos flujos se dispararon ni si algún secreto concreto salió de la empresa. iSec News, el medio que dio la noticia este domingo, lo resume igual: no hay robo de secretos confirmado y tampoco una cifra de flujos afectados. Sin ese inventario, la rotación total era la única respuesta defendible, porque un secreto sondeado se trata como un secreto perdido.

Un secreto de GitHub Actions puede ser la llave que firma una versión, la credencial de la nube donde se despliega el producto o el token que publica un paquete. Por eso el sondeo importa aunque el robo no esté confirmado: si el atacante leyó un solo de esos valores, podría volver otro día disfrazado del propio sistema de despliegue, con código firmado por la casa.

El caso deja una lección fea para cualquier equipo que programa, también en América Latina, donde miles de empresas chicas corren su infraestructura con dos o tres proveedores. La criticidad de una aplicación no se mide por lo que hace en producción, sino por lo que puede tocar. Una herramienta interna menor, con acceso a los repositorios, vale más para un atacante que muchos servidores abiertos al público: desde el repositorio se llega a las claves de despliegue, y desde esas claves, a todo lo demás.

La rotación tras la brecha de un proveedor tampoco admite calendario. Cuando un proveedor avisa que expuso variables de entorno, el reloj corre desde ese aviso, no desde el día en que alguien nota actividad rara. Cambiar la contraseña, además, no alcanza cuando el botín posible es un token vivo: los tokens robados por WardenStealer sobreviven al cambio de contraseña y a la verificación en dos pasos, y ese ladrón recoge credenciales directo de las computadoras de los programadores.

Segundo incidente en un mes, otro camino de entrada

Este no es el primer susto de Tensorlake en otoño. El 8 de octubre, una versión maliciosa de su paquete para npm, la 0.5.144, salió publicada desde el propio flujo de lanzamiento del proyecto con un gusano de la familia Shai-Hulud que robaba credenciales al instalarse. Aquel episodio, analizado por firmas como Socket y Endor Labs, entró por una cuenta de mantenedor comprometida, y el paquete suma unas 12.000 descargas semanales. El incidente de ahora entró por la puerta del proveedor y por unas variables que nadie rotó. Dos caminos distintos, el mismo premio: las llaves del código.

El informe completo que la empresa prometió a sus clientes por correo y en su centro de confianza aún no aparece. Repositorios afectados, flujos disparados y alcance real del sondeo son los tres datos que ese documento debe traer para cerrar el caso, y son justo los tres que un cliente necesita para decidir si rota solo su clave de Tensorlake o revisa también todo lo que construyó encima de la plataforma.

Fuente: iSec News

La entrada Tensorlake y GitHub Actions: secretos sondeados se publicó primero en Tecnología Geek.