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 confirmó 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, lo que le dio al atacante acceso a esa computadora y, desde ahí, al código interno que debería vivir detrás de los muros de la propia compañía.

La frontera que GitHub señala, entre los repositorios internos y la plataforma de cara al cliente, es lo único que separa un incidente contenido de una emergencia global de cadena de suministro. GitHub hospeda a unos 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 opera a sí mismo. Las organizaciones de clientes, las empresas y los repositorios públicos y privados que esos clientes guardan en GitHub quedan, según la propia compañía, fuera del radio de impacto de esta intrusión.

Esa distinción está haciendo bastante trabajo en el comunicado que la empresa publicó en su cuenta oficial de X. “Aunque actualmente no tenemos evidencia de impacto en la información de los clientes almacenada fuera de los repositorios internos de GitHub”, dice el mensaje, “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 por 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 plug-ins con la misma ligereza con la que agrega marcadores al navegador. Una extensión envenenada distribuida por ese canal y ejecutada en una computadora 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 utilizada en este caso aún no se hizo público, pero el patrón no es nuevo. Nx Console, una extensión popular de herramientas para desarrolladores, sufrió un ataque similar.

El grupo que se llama a sí mismo TeamPCP se atribuyó la intrusión y ofrece el conjunto de datos a la venta en foros clandestinos con un precio piso de cincuenta mil dólares. La fórmula que usa el grupo, “esto no es un rescate”, ya es en sí una señal. No están intentando extorsionar a GitHub directamente. Están tratando el código fuente interno robado como cualquier otro delincuente trata los volcados de tarjetas: como una mercancía con compradores. Quien termine con ese archivo de 3.800 repositorios lo va a peinar en busca de credenciales incrustadas, secretos quemados en el código, detalles útiles para atacar la propia infraestructura 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 pasaron de escenario teórico a oficio operativo.

La respuesta de contención, según la propia GitHub, fue rápida. El equipo comprometido se aisló. La extensión maliciosa se retiró. La compañía afirma que rotó credenciales críticas, priorizando las de mayor impacto, y que notificará a los clientes afectados por sus canales de respuesta a incidentes si la investigación se amplía. La filial de Microsoft no identificó al empleado de GitHub cuya computadora fue comprometida, no nombró la extensión y no precisó por cuánto tiempo el atacante mantuvo acceso antes de la detección. Esos detalles suelen aparecer en el informe post-mortem más extenso que llega semanas después de la notificación inicial.

Para el resto del sector, la moraleja 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. Cualquier persona que haya instalado una extensión de VS Code recomendada en un hilo de foro corrió el mismo riesgo que cayó sobre un empleado de GitHub. Las defensas que funcionan son conocidas y se aplican de manera desigual: restringir la instalación de extensiones a una lista de permitidas, aislar las computadoras de desarrolladores de las credenciales de producción, rotar secretos con cadencia rápida. Esta brecha las va a empujar hacia arriba en la lista de prioridades de empresas que las habían dejado para después.

GitHub no dio un plazo para un post-mortem público completo. Las investigaciones de este tamaño en plataformas de esta escala suelen tardar varias semanas en mostrar 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 piso una vez que el mercado clandestino tenga unos días para revisar el índice.

Debate

Hay 0 comentarios.