volvervolver

VS Code Extension Attack

En el mundo de la seguridad informática, las extensiones de Visual Studio Code (VS Code) han emergido como un nuevo vector de ataque para los ciberdelincuentes. Visual Studio Code, publicado por Microsoft, es un editor de código fuente utilizado por muchos desarrolladores profesionales en todo el mundo. Microsoft también opera un mercado de extensiones para el IDE, llamado Visual Studio Code Marketplace, que ofrece complementos que amplían la funcionalidad de la aplicación y brindan más opciones de personalización.

Existen numerosos informes indicando brechas en la seguridad de VS Code, permitiendo la suplantación de extensiones, así como extensiones que roban tokens de autenticación de los desarrolladores. Una investigación reciente de un grupo israelí revela números alarmantes, donde se desarrolló una herramienta personalizada llamada 'ExtensionTotal' para encontrar extensiones de alto riesgo, desempaquetarlas y examinar fragmentos de código sospechosos.

A través de este proceso, encontraron lo siguiente:

 • 1,283 extensiones con código malicioso conocido (229 millones de instalaciones).

 • 8,161 extensiones que se comunican con direcciones IP codificadas.

 • 1,452 extensiones ejecutando archivos desconocidos.

 • 2,304 extensiones que utilizan el repositorio de GitHub de otro editor, lo que indica que son imitaciones.

Este artículo tiene como objetivo replicar el desarrollo de una extensión maliciosa para entender los riesgos asociados, alertar sobre su potencial impacto, y demostrar un ejemplo de las técnicas utilizadas para obtener acceso y ganar persistencia a través de estas extensiones. Exploraremos cómo configurar un entorno seguro, desarrollar la extensión maliciosa, y finalmente, asegurar la persistencia post-explotación.

Prerequisitos

Para desarrollar una extensión maliciosa en VS Code necesitamos configurar un entorno de desarrollo adecuado. El mismo, deberá tener los siguientes elementos:

 • Node.js
 • Visual Studio Code
 • Git
 • Generador de extensiones de Visual Studio Code

Una vez completados estos pasos, tendrás un entorno de desarrollo configurado y listo para comenzar a desarrollar la extensión.

Desarrollando la extensión maliciosa

Con el entorno de desarrollo configurado, el siguiente paso es desarrollar la extensión maliciosa. Todo el código de nuestra extensión estará en el archivo extension.ts, que contiene el código base generado por el asistente de creación de extensiones de VS Code. Inicialmente, este archivo incluye un ejemplo simple que muestra un mensaje "Hello World from color-picker!" cuando se invoca el comando helloWorld.


Para transformar esta extensión en una herramienta maliciosa, realizaremos algunas modificaciones clave. La idea es ejecutar una shell reversa cuando el usuario invoca un comando específico dentro de VS Code. Esto se logra modificando dos archivos principales: package.json y extension.ts.

En package.json, configuraremos un comando que se comporta como una extensión legítima, similar a una herramienta comúnmente utilizada por desarrolladores y diseñadores, como un "color-picker". Esta configuración nos permitirá ejecutar nuestro código malicioso sin despertar sospechas.


Luego, en extension.ts, añadiremos el código necesario para ejecutar una shell reversa. Este código se ejecutará cuando el comando malicioso sea invocado. Para probar que todo funciona correctamente, utilizaremos las herramientas de depuración de VS Code, que nos permiten ejecutar y probar la extensión directamente desde el entorno de desarrollo.


Antes de implementar el código malicioso, es fundamental asegurarnos de que la configuración básica de la extensión funcione correctamente. Para hacer esto, primero probaremos la extensión con el código base proporcionado por el asistente. Este paso de verificación es crucial porque nos aseguramos de que lo básico esté funcionando, si no podríamos encontrar problemas más adelante y asumir incorrectamente que el fallo se debe al código agregado, cuando en realidad podría ser un problema con la configuración inicial.

Para realizar esta verificación, debemos ejecutar la extensión con las pequeñas modificaciones aplicadas. Esto se hace desde el entorno de desarrollo de VS Code utilizando las herramientas de depuración integradas. Iremos a la opción de menú "Run" y seleccionaremos "Start Debugging". Este proceso abrirá una nueva instancia de VS Code donde podremos probar la extensión.


En esta nueva instancia, presionaremos el atajo de teclado ctrl+shift+p para abrir la paleta de comandos y seleccionaremos el comando de nuestra extensión. Si todo funciona correctamente, deberíamos ver el mensaje "Hello World!" mostrado en la interfaz de VS Code. Este paso nos confirma que la configuración básica está operativa y nos proporciona un punto de control antes de introducir el código malicioso.

Una vez que hemos verificado que la configuración básica funciona, podemos proceder a introducir el código de la shell reversa en extension.ts y modificar el comando que viene por default. Este código se encargará de establecer una conexión remota con nuestro sistema atacante cada vez que el comando malicioso sea ejecutado.


Finalmente, para asegurarnos de que la conexión remota se realiza de manera exitosa, pondremos a la escucha nuestro sistema remoto (en este caso, una máquina con Kali Linux) y ejecutaremos la extensión desde la máquina víctima (Windows 11). El IP de la máquina atacante es 192.168.1.135 y corresponde a nuestro Kali en la red local que recibirá la conexión:


Ponemos a la escucha a nuestro Kali en el puerto 4444 y ejecutaremos nuevamente la extensión desde nuestro Windows 11 víctima:


Presionamos F5 para lanzar una nueva instancia de debug en VS Code. En esta nueva instancia, utilizamos el atajo de teclado ctrl+shift+p para abrir la paleta de comandos y ejecutamos el comando malicioso de la extensión. Al hacerlo, la conexión se establece exitosamente, permitiéndonos obtener acceso al sistema Windows 11 desde nuestra máquina Kali Linux. Esto es posible gracias a la ejecución del código de la shell reversa que hemos incorporado en la extensión maliciosa, lo que demuestra la efectividad de la técnica y subraya la importancia de entender y mitigar estos riesgos en entornos corporativos.


Post-Exploitation y Persistencia

Una vez que hemos obtenido acceso al sistema objetivo mediante nuestra extensión maliciosa, el siguiente paso es asegurar la persistencia y realizar actividades de post-explotación. Esto nos permitirá mantener el acceso incluso si la máquina es reiniciada y realizar acciones adicionales para explorar y comprometer más profundamente el sistema.

Para la post-explotación, utilizaremos powershell-empire, una poderosa herramienta de post-explotación que permite a los atacantes ejecutar comandos y scripts en sistemas comprometidos de manera remota. Primero, configuramos el servidor de powershell-empire en nuestra máquina atacante, lo que nos permitirá gestionar y controlar los agentes que se ejecutan en los sistemas comprometidos. En otra terminal, ejecutamos el cliente, que utilizaremos para interactuar con el servidor y configurar nuestros listeners y stagers.


El siguiente paso es crear un nuevo listener en el cliente de powershell-empire. Este listener es un componente que espera conexiones entrantes de los agentes. Configuramos el listener con los parámetros necesarios, como el host y el puerto, para que esté listo para recibir conexiones. Con el listener configurado, procedemos a crear un payload de PowerShell. Este payload, una vez ejecutado en el sistema Windows 11 comprometido, establecerá una conexión de vuelta al listener, registrándose como un nuevo agente y permitiendo el control remoto del sistema.



Ahora, procederemos a crear el payload de PowerShell que ejecutaremos en el sistema Windows 11 ya comprometido mediante la extensión maliciosa. Generamos este payload siguiendo una serie de comandos específicos que nos permitirán configurar el stager que se comunicará con el listener que hemos establecido anteriormente.

Primero, en la interfaz del cliente de powershell-empire, ingresamos al menú principal y seleccionamos el stager multi/launcher. Este stager es una opción versátil que nos permite configurar varios parámetros para establecer la conexión de vuelta al listener. Configuramos el listener especificando el tipo que hemos creado previamente, en este caso, http, y establecemos las propiedades necesarias, como el host y el puerto donde nuestro listener está esperando conexiones.

Una vez configurado, ejecutamos el comando para generar el payload. Este será un script de PowerShell que, cuando se ejecute en el sistema Windows comprometido, establecerá una conexión de vuelta al listener y registrará un nuevo agente en powershell-empire. Este agente nos proporcionará control remoto sobre el sistema comprometido, permitiéndonos realizar una amplia gama de acciones de post-explotación.


Después de generar el payload, lo ejecutamos en el sistema Windows 11 comprometido, aprovechando la sesión de shell reversa que hemos establecido con nuestra extensión maliciosa. Al ejecutar el payload, verificamos que el agente se registre correctamente en el listener y aparezca en la interfaz del cliente de powershell-empire Este paso es crucial para asegurar que nuestra configuración es correcta y que el sistema comprometido está ahora bajo nuestro control remoto.


Nótese el mensaje: New agent 4ADCSV6Z checked in

Con el agente registrado y activo, podemos proceder a utilizar los módulos de post-explotación disponibles para realizar actividades adicionales, asegurando que nuestro acceso al sistema comprometido sea duradero y estable.


Como se puede ver a continuación, en el sistema Windows 11, VS Code no está en ejecución. Esto es posible porque, una vez que el agente ha sido registrado exitosamente mediante el framework de post-explotación, ya no necesitamos mantener el editor abierto. El acceso y control sobre el sistema comprometido se mantiene independientemente del estado de la aplicación.


Esto demuestra que una vez que el agente se ha registrado correctamente, no es necesario mantener VS Code abierto para mantener la conexión. Sin embargo, es importante notar que si el equipo es reiniciado, perderemos la conexión, ya que el agente no persistirá a menos que configuremos una técnica de persistencia adecuada.

A continuación, procedemos a establecer la persistencia en el sistema comprometido. Utilizamos el módulo powershell_persistence_userland_registryque nos permite establecer persistencia en el registro de Windows. Este módulo crea una entrada en el registro que ejecutará nuestro payload cada vez que el usuario inicie sesión. Configuramos y ejecutamos el módulo de persistencia, asegurándonos de que el payload se ejecute automáticamente en cada reinicio del sistema.


Podemos confirmar que la persistencia se ha establecido con éxito cuando vemos el mensaje: "Registry persistence established using listener http stored in HKCU\Microsoft\Windows\CurrentVersion\Debug". Este mensaje indica que el módulo de persistencia se ha creado correctamente en una entrada del registro de Windows.

Esta técnica de persistencia implica almacenar el payload en una clave del registro ubicada en HKCU:Software\Microsoft\Windows\CurrentVersion\Debug, lo que garantiza que el script de PowerShell se ejecute automáticamente cada vez que el usuario inicie sesión en el sistema. Al establecer esta clave de registro, aseguramos que el agente se vuelva a registrar con el listener incluso después de que el equipo sea reiniciado, manteniendo así el acceso remoto al sistema comprometido de manera persistente.


Probaremos reiniciar el Windows vulnerado para confirmar la persistencia. Una vez que el sistema se haya reiniciado, verificaremos si un nuevo agente se registra automáticamente en powershell-empire. Este paso es crucial para asegurar que la técnica de persistencia implementada está funcionando correctamente y que nuestro acceso remoto al sistema comprometido es duradero.

Cada vez que reiniciemos, un nuevo agente se va a registrar, indicando que el payload de PowerShell almacenado en el registro de Windows se ejecuta automáticamente al inicio de sesión del usuario, reconectando el sistema comprometido con nuestro listener.


Con la persistencia confirmada, podemos empezar a jugar con algunos comandos de powershell-empire para explorar y obtener más información del sistema comprometido. Por ejemplo, podemos utilizar el módulo powershell/situational_awareness/host/computerdetails para recopilar detalles del sistema. Este módulo nos proporcionará información valiosa sobre el hardware y el software del sistema comprometido, incluyendo el nombre del equipo, la versión del sistema operativo y más.


Podemos realizar un escaneo de puertos en la red utilizando el módulo powershell/situational_awareness/network/portscan. Este módulo nos permite escanear los puertos abiertos en dispositivos específicos dentro de la red del sistema comprometido. Configuramos el módulo para que escanee un host en particular, por ejemplo, raspberrypi.local, y ejecutamos el comando de escaneo. Este tipo de análisis nos ayuda a identificar otros dispositivos y servicios accesibles en la red, que pueden ser potenciales objetivos para futuros ataques o puntos de entrada para movimientos laterales dentro de la infraestructura.


Estos pasos de post-explotación, junto con la verificación de la persistencia, no solo nos permiten mantener acceso continuo al sistema comprometido, sino también ampliar nuestro conocimiento y control sobre el entorno, facilitando una explotación más amplia y efectiva.

Conclusión

La exploración y demostración de cómo desarrollar una extensión maliciosa para VS Code nos permite comprender mejor los riesgos asociados con la instalación de extensiones y subraya la importancia de la seguridad en entornos de desarrollo. A través de la configuración del entorno, el desarrollo de la extensión, y las técnicas de post-explotación y persistencia, hemos evidenciado las posibles vulnerabilidades que pueden ser explotadas por actores maliciosos.

El uso de herramientas como powershell-empire para la post-explotación destaca la facilidad con la que un atacante puede mantener acceso continuo y duradero a un sistema comprometido, incluso después de un reinicio. La técnica de persistencia basada en el registro de Windows asegura que el atacante puede reconectar automáticamente con el sistema comprometido, haciendo que la mitigación de tales amenazas sea más desafiante.

Es esencial que los desarrolladores y profesionales de seguridad sean conscientes de estos vectores de ataque y adopten medidas proactivas para proteger sus entornos. Esto incluye la verificación cuidadosa de las extensiones instaladas, la implementación de políticas de seguridad estrictas, y la utilización de herramientas de monitoreo y análisis para detectar comportamientos sospechosos.

En resumen, este ejercicio no solo demuestra una técnica de explotación, sino que también resalta la necesidad de una vigilancia constante y un enfoque riguroso hacia la seguridad en el desarrollo de software. Al comprender y anticipar estas amenazas, podemos fortalecer nuestras defensas y asegurar un entorno de desarrollo más seguro y resiliente.