El día cero que podría haber comprometido a todos los cursores y usuarios de Windsurf

Un investigador de seguridad de KOI Security se topó con un día cero crítico enterrado en lo profundo de la infraestructura que alimenta las herramientas de codificación de IA de hoy. Si hubiera sido explotado, un atacante no sofisticado podría haber secuestrado más de 10 millones de máquinas con un solo golpe.

Los asistentes de codificación de IA como Cursor y Windsurf han explotado en popularidad, prometiendo una productividad sobrealimentada para los desarrolladores de todo el mundo. Detrás de sus elegantes interfaces se encuentran una base compartida: las horquillas de código construidas por la comunidad y un mercado abierto de extensiones que alimenta la magia. Pero, con esta nueva ola de herramientas de desarrolladores, viene un punto ciego peligroso.

Doblado vsxPloit: Una sola falla pasada por alto en OpenVSX, un componente crítico en la cadena de suministro del desarrollador, permitió un compromiso silencioso y completo del sistema en cualquier máquina que ejecute una bifurcación de código VS. Un error. Control total.

Vamos a sumergirnos.

Los editores de hoy en día dependen en gran medida de las extensiones para ofrecer su funcionalidad más básica. Las características como el resaltado de sintaxis, la pelusa y la depuración no están codificadas en el editor: son proporcionadas por extensiones.

Cada una de estas extensiones se ejecuta con privilegios completos en la máquina del desarrollador. Esto a su vez significa que una sola extensión comprometida puede conducir a la adquisición de máquina completa de cualquier persona que la instale.

Este escenario exacto de pesadilla es lo que el investigador de seguridad Oren Yomtov de Koi Security, una compañía que proporciona una plataforma para asegurar el aprovisionamiento y las extensiones de software, se topó con el aumento de la tope.

En una publicación reciente, Yomtov explica que al examinar el proceso de construcción detrás de OpenVSX, el mercado de código abierto impulsando extensiones para herramientas como Cursor, Windsurf, VScodium y otros, descubrió un defecto crítico.

La vulnerabilidad permitió a cualquier atacante, no solo obtener el control sobre una sola extensión, sino un armagedón de la cadena de suministro, ganando el control total sobre todo el mercado.

Dado este defecto, cualquier atacante podría impulsar actualizaciones maliciosas bajo la cuenta de confianza @Open-VSX. Al principio, Yomtov asumió que tenía que ser un error, este código se había estado ejecutando durante años, utilizado por decenas de millones. Pero cuando recreó el ataque en su laboratorio, la simulación funcionó sin problemas.

Lo que parecía impensable fue repentinamente muy real: un desastre de seguridad silencioso y a gran escala estaba a la vista.

La vulnerabilidad: una variación de la clásica «solicitud PWN»

Para comprender cómo funcionó la vulnerabilidad, primero debe comprender cómo las extensiones llegan a OpenVSX en primer lugar.

Si desea publicar una extensión para abrir VSX, tiene dos opciones:

1. Subirlo para abrir VSX usted mismo

2. Solicite una extensión para ser publicada automáticamente creando una solicitud de extracción que agrega la extensión a la lista en el archivo Extensions.json

«La construcción nocturna es donde se encuentra el problema», dice Yomtov.

Todas las noches, OpenVSX ejecuta un proceso automatizado que obtiene las últimas versiones de extensiones enviadas por la comunidad, las construye y las publica en el mercado. Está destinado a facilitar la vida de los desarrolladores, pero en este caso, introdujo un defecto crítico.

Para obtener una publicación automática de extensión, todo lo que un desarrollador tiene que hacer es enviar una solicitud de extracción simple que lo agregue a una lista pública. A partir de ahí, OpenVSX se hace cargo: extrae el código, instala las dependencias, construye la extensión y lo publica utilizando un poderoso token secreto que pertenece a la cuenta confiable de @Open-VSX.

Esta ficha estaba destinada a permanecer oculta, solo vista por la infraestructura de confianza. Desafortunadamente, debido a cómo el proceso de construcción ejecuta el código arbitrario de los repositorios públicos, cualquier autor de extensión podría elaborar una actualización maliciosa que Captura en silencio el token.

Lo que es aún más alarmante es que no necesitarían enviar una extensión maliciosa directamente. Podrían haber ocultado su código dentro de una dependencia, o incluso una dependencia de una dependencia, y el sistema lo habría ejecutado automáticamente durante la construcción nocturna. A partir de ahí, robar el token fue trivial.

Y con esa ficha en la mano, un atacante no solo controlaría su propia extensión. Podrían publicar actualizaciones, sobrescribir las existentes y secuestrar silenciosamente todo el mercado.

El impacto: una pesadilla de cadena de suministro que expuso a millones de desarrolladores

Con el acceso al token de la cuenta @Open-VSX, un atacante podría haber creado una pesadilla de cadena de suministro mundial. «Esa ficha es una credencial súper administrativa», explica Yomtov. «Puede publicar nuevas extensiones, sobrescribir las existentes y hacerse pasar por cualquier editor en el ecosistema».

A partir de ese momento, el daño se vuelve casi sin esfuerzo. Cada vez que un desarrollador instala una extensión o su editor actualiza automáticamente uno en el fondo, lo que sucede continuamente, la carga útil del atacante se entregaría en silencio a su máquina. Sin alertas. Sin indicaciones. Sin sospecha. Adquisición completa.

¿Y qué podría hacer esa carga útil? «Casi cualquier cosa», dice Yomtov. Las extensiones en el código VS y sus horquillas se ejecutan como procesos Node.js, lo que significa que pueden acceder a archivos, iniciar otros programas, realizar solicitudes de red y ejecutar código arbitrario.

Una actualización maliciosa de una extensión popular, por ejemplo, el complemento Python, podría instalar silenciosamente un keylogger, robar cookies del navegador, código fuente de deslizamiento, construcciones infectas o tuberías de desarrollo entero trasero.

Ha habido casos aislados de extensiones ROGO VS Código que roban claves SSH o billeteras criptográficas. Pero este no sería un mal actor deslizándose a través de las grietas. Esto sería adquisición a gran escala, compromiso de cadena de suministro a escala del ecosistema. Como Solarwinds, pero para herramientas de desarrollador.

Si bien el impacto sería más severo para los editores de escritorio como Cursor, Windsurf y Vscodium, incluso los entornos basados en el navegador como GitPod o Stackblitz podrían verse afectados, dependiendo de cuán profundamente integradas sean las extensiones comprometidas.

Entonces, ¿qué puedes hacer al respecto?

Le preguntamos a Yomtov qué usuarios y organizaciones deberían quitar de este incidente. Su respuesta fue contundente: «Suponga que cada extensión no está confiable hasta que se demuestre lo contrario».

Las extensiones pueden parecer complementos inofensivos, pero bajo el capó, son componentes de software potentes, a menudo escritos por individuos, que se ejecutan con permisos completos y se actualizan automáticamente sin supervisión.

«No es diferente a tirar de un paquete de NPM o PYPI, y generalmente aún peor», dice Yomtov. «Si no confíe ciegamente en un repositorio de GitHub con acceso raíz a su máquina, tampoco debe confiar en una extensión».

Para protegernos, Yomtov recomienda que las organizaciones traten las extensiones como parte de su superficie de ataque y apliquen la misma disciplina que usan para cualquier otra dependencia. Eso significa:

1. Mantener un inventario real de lo que está instalado, a través de las máquinas y por quién

2. Evaluar el riesgo basado en quién construyó la extensión, cómo se mantiene y qué hace realmente

3. Hacer cumplir políticas claras alrededor de lo que se permite, y tomar medidas cuando algo se sale de los límites

4. Monitoreo continuamentedado que las extensiones pueden actualizarse en silencio e introducir nuevos riesgos durante la noche

El equipo de investigación de KOI continúa encontrando extensiones vulnerables y activamente maliciosas, no solo en OpenVSX, o el mercado de Microsoft, incluso en otros mercados de extensión como la tienda web de Chrome.

«El ecosistema ha crecido más rápido que las barandillas», dice Yomtov. «Hasta que eso cambie, la suposición más segura es cero confianza. Cada extensión es una puerta trasera potencial a menos que lo revise y lo esté viendo».

Yomtov y el equipo de KOI Security revelaron responsablemente la vulnerabilidad a la Fundación Eclipse, que mantiene el proyecto OpenVSX. Durante las siguientes semanas, trabajaron en estrecha colaboración con los mantenedores para validar el problema, diseñar una solución sólida y asegurarse de que el parche se implementara y implementara correctamente.

Gracias a esta colaboración, la vulnerabilidad se ha cerrado y el mercado es nuevamente seguro para los millones de desarrolladores que confían a diario.

Pero el incidente sirve como una llamada de atención, incluso la infraestructura de confianza necesita un escrutinio constante, especialmente cuando contiene las llaves de todo el ecosistema de desarrollo.

Aprenda cómo KOI ayuda a las organizaciones a descubrir, evaluar y gobernar extensiones riesgosas en VSCODE, OpenVSX, Chrome y otros mercados de mercados


Chatea con nosotros.

Patrocinado y escrito por Koi Security.