Ciberseguridad

Una extensión envenenada de VS Code robó 3.800 repositorios internos de GitHub

Susan Hill

GitHub investiga un acceso no autorizado a sus repositorios internos y confirma que un atacante logró exfiltrar datos de unos 3.800 de ellos. La intrusión llegó a través de una extensión envenenada de Visual Studio Code instalada por un empleado, dando al atacante acceso a esa máquina y, desde ahí, a código interno que debería vivir tras los muros de la propia compañía.

La frontera que GitHub señala, entre repositorios internos y la plataforma orientada al cliente, es lo único que separa un incidente contenido de una emergencia global de cadena de suministro. GitHub aloja alrededor de 100 millones de desarrolladores y una parte significativa del código abierto sobre el que se sostiene la internet actual. Cuando la compañía habla de lo «interno», se refiere al código de su propia plataforma, sus herramientas, su configuración operativa, el material con el que GitHub se construye y se ejecuta a sí mismo. Las organizaciones de clientes, las empresas y los repositorios públicos y privados que esos clientes almacenan en GitHub quedan, según la propia compañía, fuera del radio de impacto de esta intrusión.

Esa distinción está haciendo un trabajo considerable en la declaración publicada en la cuenta oficial de X de la empresa. «Aunque actualmente no tenemos evidencia de impacto en la información de los clientes almacenada fuera de los repositorios internos de GitHub», dice el comunicado, «estamos monitoreando de cerca nuestra infraestructura por si hay actividad posterior». La redacción es precisa, y la precisión en una notificación de brecha suele significar que la investigación sigue en marcha. «Sin evidencia de impacto» no es lo mismo que «sin impacto». Los incidentes en plataformas grandes tienen la costumbre de crecer a medida que el análisis forense alcanza la actividad del atacante, y la línea entre sistemas internos y de cara al cliente rara vez es un muro físico limpio. Es un conjunto de controles de acceso, credenciales y cuentas de servicio que hay que razonar uno a uno.

El mecanismo es la parte de esta historia que debería preocupar a cualquier desarrollador. Visual Studio Code es el editor de código dominante del planeta, presente en casi todas las grandes organizaciones de ingeniería. Su tienda de extensiones funciona sobre confianza comunitaria: cualquiera puede publicar, y la mayoría de los ingenieros instala complementos con la misma ligereza con la que añade marcadores al navegador. Una extensión envenenada distribuida por ese canal y ejecutada en una máquina de desarrollador le da al atacante acceso a todo lo que la sesión de ese desarrollador pueda alcanzar: repositorios, tokens, registros de paquetes, servicios internos. El nombre concreto de la extensión usada en este caso aún no se ha hecho público, pero el patrón no es nuevo. Nx Console, una popular extensión para herramientas de desarrollo, sufrió un compromiso similar.

El grupo que se hace llamar TeamPCP se atribuyó la intrusión y ofrece el conjunto de datos a la venta en foros clandestinos con un precio mínimo de cincuenta mil dólares. La fórmula del grupo, «esto no es un rescate», es ya una señal. No están tratando de extorsionar directamente a GitHub. Están tratando el código fuente interno robado como cualquier otro criminal trata los volcados de tarjetas de crédito: una mercancía con compradores. Quien termine con ese archivo de 3.800 repositorios lo peinará en busca de credenciales incrustadas, secretos en duro, detalles útiles para atacar la infraestructura propia de GitHub, y cualquier cosa que sirva para comprometer objetivos aguas abajo. Al mismo grupo se le vincula con el gusano Mini Shai-Hulud que afectó al paquete durabletask en PyPI, lo que subraya el fondo real de la historia: los ataques a la cadena de suministro del desarrollo han pasado de escenario teórico a oficio operativo.

La respuesta de contención, según la propia GitHub, fue rápida. El equipo comprometido fue aislado. La extensión maliciosa fue retirada. La compañía afirma que ha rotado credenciales críticas, dando prioridad a las de mayor impacto, y que notificará a los clientes afectados a través de sus canales de respuesta a incidentes si la investigación se amplía. La filial de Microsoft no ha identificado al empleado de GitHub cuyo equipo fue comprometido, no ha nombrado la extensión y no ha precisado durante cuánto tiempo tuvo acceso el atacante antes de la detección. Esos detalles suelen aparecer en el informe post-incidente más largo que llega semanas después de la notificación inicial.

Para el resto del sector, la conclusión práctica es más simple que el envoltorio de inteligencia de amenazas. Toda organización de ingeniería está a una instalación descuidada de extensión del mismo incidente. Cualquiera que haya instalado una extensión de VS Code recomendada en un hilo de foro ha corrido el mismo riesgo que aterrizó sobre un empleado de GitHub. Las defensas que funcionan son conocidas y se aplican de forma desigual: restringir la instalación de extensiones a una lista de permitidas, aislar las máquinas de desarrollador de las credenciales de producción, rotar secretos con cadencia rápida. Esta brecha va a empujarlas hacia arriba en la lista de prioridades de compañías que las habían postergado.

GitHub no ha dado plazo para un post-mortem público completo. Las investigaciones de este tamaño en plataformas de esta escala suelen tardar varias semanas en aflorar todo su alcance, y las actualizaciones llegarán por los canales oficiales de la compañía a medida que se produzcan. Lo siguiente a vigilar es si el archivo de 3.800 repositorios aparece efectivamente a la venta, y a qué precio se mueve el suelo una vez que el mercado clandestino haya tenido unos días para revisar el índice.

Debate

Hay 0 comentarios.