in

El nuevo kit de herramientas de seguridad de aplicaciones expone ataques de confusión de dependencia



La confusión de dependencias es un problema molesto en el desarrollo de software, ya que los actores malintencionados utilizan una variedad de trucos para engañar a los desarrolladores e integradores para que incorporen componentes de software malintencionado en su base de código. En lugar de obtener la funcionalidad deseada en la aplicación, los desarrolladores obtienen una aplicación que se comporta de manera diferente a lo esperado o una puerta trasera que puede ser explotada por personas no autorizadas.

Apiiro ha lanzado Dependency Combobulator, un conjunto de herramientas de código abierto basado en Python que ofrece a las empresas una forma de protegerse contra este tipo de ataques a la cadena de suministro. Dependency Combobulator funciona de manera inmediata con la administración de paquetes npm (paquetes Javascript) y maven (paquetes Java), pero también se puede extender a otros sistemas de administración de paquetes, según la compañía.

A principios de este año, el investigador de seguridad Alex Birsan demostró lo fácil que es cargar componentes de código en administradores de paquetes públicos y repositorios de código y atraer a los desarrolladores para que los descarguen. Como parte de esta investigación, Birsan pudo extraer datos de empresas como Tesla, Apple y Microsoft. Un mes después, PyPI o el índice de paquetes de Python eliminaron 3.653 paquetes maliciosos, incluida una versión no autorizada de CuPy, una biblioteca para la plataforma de computación paralela de Nvidia, CUDA, utilizando el mismo método de ataque.

El proceso de explotación para un ataque de confusión de dependencia (o ataque de okupación de nombre de paquete) es bastante sencillo, ya que comienza cuando el actor malintencionado carga un paquete de código en un repositorio público con el mismo nombre que un paquete interno privado. El actor podría averiguar el nombre de estos paquetes privados buscando archivos de configuración en proyectos disponibles públicamente. De forma predeterminada, cuando un desarrollador actualiza todas las dependencias de un proyecto y las extrae de los repositorios públicos y privados, el proceso de compilación recoge el paquete malicioso del repositorio público en lugar del paquete interno privado. Cuando el desarrollador descubrió que se extrajo el paquete incorrecto, el código malicioso ya se había ejecutado en el código y el proyecto estaba comprometido. Y si la compilación se realizó como parte de un proceso automatizado, como sería el caso en un entorno de Integración Continua / Entrega Continua (CI / CD), esa sustitución en particular podría pasar desapercibida durante algún tiempo.

Reconocer la confusión de la adicción

Lo más probable es que los equipos de seguridad de aplicaciones implementen el combobulador de dependencia a nivel de CI, dice Moshe Zioni, vicepresidente de investigación de seguridad de Apiiro. Por ejemplo, si el equipo está usando Jenkins para su proceso de CI, el kit de herramientas se puede usar como parte del proceso de construcción. Otro lugar para usar el kit de herramientas serían las confirmaciones de código y las solicitudes de inserción, donde cualquier cambio en las importaciones de dependencias se envía al combobulador de dependencias para su revisión y toma de decisiones.

«Se puede conectar potencialmente a través de un complemento, pero esa es una forma más complicada que no se admite fácilmente y requiere un trabajo de desarrollo adicional», dice Zioni.

Existen muchas otras herramientas que actúan de manera similar a Dependency Combobulator. Snyk ofrece snync, una herramienta de código abierto, para identificar posibles casos de confusión de dependencia en el repositorio de código. Sonatype ofrece a los desarrolladores un script del Comprobador de confusión de dependencias / espacio de nombres en GitHub que comprueba si un proyecto tiene artefactos con el mismo nombre entre repositorios y si el desarrollador se ha visto afectado por un ataque de confusión de dependencias en el pasado. Nexus Firewall de Sonatype puede poner en cuarentena componentes de código abierto sospechosos o maliciosos antes de que entren en el repositorio de la empresa. Existen registros privados (Verdaccio establece un registro npm privado) y sistemas de administración de paquetes dedicados (como Cloudsmith) que las organizaciones pueden usar para evitar este tipo de ataque.

Minimizando los riesgos

Hay formas en que las empresas pueden minimizar este tipo de riesgo para la cadena de suministro de software. GitHub, que es propietario de npm y mantiene el registro público de npm, recomienda lo siguiente para lidiar con la confusión de dependencias: Use áreas para paquetes internos para indicar explícitamente dónde están ubicados los paquetes; Colocar un archivo .npmrc en el directorio raíz del proyecto para establecer explícitamente el registro deseado; Tenga cuidado al usar proxies; y reaccionar inmediatamente si algo sale mal durante el proceso de construcción.

Otra cosa que las organizaciones pueden hacer es ocupar de forma preventiva los nombres de sus propias dependencias privadas. Al reclamar los nombres utilizados para las dependencias privadas, incluidos los espacios de nombres y los reinos, en los repositorios públicos, la organización se asegura de que los atacantes no puedan usarlos para sus propios fines.

«Intentamos responder desarrollando un conjunto de herramientas que pudiera mitigar amenazas similares y ser lo suficientemente flexible y ampliable para hacer frente a futuras oleadas de ataques de confusión por adicción», dice Zioni. «Combatir este vector de ataque es esencial para que las empresas aseguren con éxito sus cadenas de suministro de software».

What do you think?

Written by Alan Kim

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

GIPHY App Key not set. Please check settings

Los piratas informáticos de Void Balaur venden buzones de correo y datos privados robados

10 poderosas razones por las que debería construir una PC