Vulnerabilidad en Visual Studio Code Marketplace

La cadena de suministro de software vuelve a ser el centro de atención tras el hallazgo de una vulnerabilidad crítica en Visual Studio Code Marketplace. Investigadores de ReversingLabs descubrieron que actores de amenazas pueden reutilizar nombres de extensiones previamente eliminadas para publicar versiones maliciosas, una laguna que abre la puerta a ataques sofisticados contra millones de desarrolladores que utilizan Visual Studio Code.

Descubrimiento de extensiones maliciosas

El hallazgo se produjo después de identificar una extensión denominada "ahbanC.shiba", la cual compartía similitudes con otras dos extensiones maliciosas previamente detectadas: ahban.shiba y ahban.cychelloworld. Todas estas extensiones actuaban como descargadores de malware, recuperando cargas útiles de PowerShell desde un servidor externo.

El código malicioso estaba diseñado para cifrar archivos en una carpeta denominada "testShiba" ubicada en el escritorio de la víctima. Una vez completado el cifrado, los atacantes exigían un rescate en tokens Shiba Inu, solicitando el depósito en una billetera no especificada.

Este patrón sugiere que los atacantes están en etapa de desarrollo activa, probando diferentes variantes de su ataque y aprovechando la laguna en la política de publicación de extensiones.

¿Cómo fue posible la reutilización de nombres?

En teoría, cada extensión de Visual Studio Code debe contar con un ID único, compuesto por el nombre del editor y el nombre de la extensión, por ejemplo: <publisher>.<name>. Según la documentación oficial, el campo <name> debe ser único, estar en minúsculas y sin espacios.

Sin embargo, la investigadora Lucija Valentić de ReversingLabs descubrió que cuando una extensión es eliminada del Marketplace, su nombre queda nuevamente disponible para otros usuarios. Esto permite que actores maliciosos registren el mismo nombre con un editor distinto, creando la ilusión de continuidad y engañando a los desarrolladores que buscan extensiones legítimas.

La práctica no se aplica a extensiones que son simplemente despublicadas, pero sí a aquellas eliminadas por completo del repositorio.

Comparación con otros repositorios: PyPI como precedente

Esta vulnerabilidad no es exclusiva de Visual Studio Code. De hecho, algo similar ocurre en el Python Package Index (PyPI). En 2023, ReversingLabs demostró que al eliminar un paquete en PyPI, su nombre quedaba disponible para que cualquier usuario lo reclamara, siempre que se modificaran los metadatos de distribución.

No obstante, PyPI introdujo una excepción de seguridad: los nombres de proyectos que estuvieron vinculados a paquetes maliciosos dejan de estar disponibles permanentemente, reduciendo el riesgo de reutilización. Visual Studio Code, en cambio, no aplica este tipo de restricciones, lo que incrementa las posibilidades de ataques de envenenamiento de repositorios.

Amenaza creciente en la cadena de suministro de software

El problema va más allá de Visual Studio Code. Según registros filtrados del grupo Black Basta, los atacantes buscan cada vez más infiltrar ransomware y malware en ecosistemas de código abierto, confiando en que los desarrolladores descarguen estas librerías maliciosas sin sospechar.

Valentić advirtió que este escenario plantea un riesgo crítico:

Citar"El descubrimiento de esta laguna expone una nueva amenaza: que el nombre de cualquier extensión eliminada puede ser reutilizado, y por cualquiera. Eso significa que si se elimina alguna extensión legítima y muy popular, su nombre queda en juego".

Casos adicionales: ocho paquetes npm maliciosos

El descubrimiento de ReversingLabs coincide con la detección de ocho paquetes maliciosos en npm, identificados por los investigadores de JFrog. Estos paquetes, distribuidos por usuarios llamados ruer y npjun, contenían un ladrón de información diseñado para exfiltrar contraseñas, datos de tarjetas de crédito, cookies de sesión y credenciales de billeteras de criptomonedas.

Los paquetes detectados fueron:

• toolkdvv (v1.1.0, v1.0.0)
• react-sxt (v2.4.1)
• react-typex (v0.1.0)
• react-typexs (v0.1.0)
• react-sdk-solana (v2.4.1)
• react-native-control (v2.4.1)
• revshare-sdk-api (v2.4.1)
• revshare-sdk-apii (v2.4.1)

Lo más preocupante es que empleaban 70 capas de código ofuscado para desplegar una carga útil en Python que facilitaba el robo de información, dificultando la detección por herramientas de seguridad convencionales.

Opiniones de expertos en ciberseguridad

Para Guy Korolevski, investigador de JFrog, estos hallazgos son una señal clara del rumbo de los ciberataques:

Citar"Los repositorios de software de código abierto se han convertido en uno de los principales puntos de entrada para los atacantes como parte de los ataques a la cadena de suministro, con oleadas crecientes que utilizan typosquatting y enmascaramiento, pretendiendo ser legítimos".

Korolevski subraya que las campañas multicapa diseñadas para evadir sistemas de defensa tradicionales requieren que las organizaciones cuenten con visibilidad completa de su cadena de suministro, implementando escaneo automatizado riguroso y controles centralizados de seguridad en todos los componentes de software.

Un riesgo latente para desarrolladores y organizaciones

El caso de Visual Studio Code Marketplace confirma que los ecosistemas de código abierto son un objetivo prioritario para los atacantes. La posibilidad de reutilizar nombres de extensiones eliminadas representa una amenaza real para millones de desarrolladores, ya que abre la puerta a ataques de suplantación y distribución de ransomware.

Si a esto sumamos los recientes hallazgos en npm y PyPI, el panorama es claro: los repositorios de software se han convertido en un vector crítico para los ataques a la cadena de suministro, lo que exige mayor vigilancia, políticas de seguridad más estrictas y educación constante para los desarrolladores.

En un contexto en el que los actores maliciosos perfeccionan técnicas de envenenamiento de repositorios, typosquatting y ofuscación avanzada, la única defensa efectiva es adoptar prácticas seguras de desarrollo, monitoreo proactivo y herramientas de análisis de dependencias que aseguren la integridad del software desde su origen.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login