NEGOCIOS

Nuevo tipo de ataque a la cadena de suministro golpeó a Apple, Microsoft y otras 33 empresas

Nuevo tipo de ataque a la cadena de suministro golpeó a Apple, Microsoft y otras 33 empresas

La semana pasada, un investigador demostró un nuevo ataque a la cadena de suministro que ejecutaba código falsificado en redes pertenecientes a algunas de las empresas más grandes del planeta, incluidas Apple, Microsoft y Tesla. Ahora, otros investigadores están salpicando Internet con paquetes de imitación, con más de 150 de ellos detectados hasta el momento.

La técnica fue revelada el martes pasado por el investigador de seguridad Alex Birsan. Su llamado ataque de confusión de dependencia o confusión de espacio de nombres comienza colocando un código malicioso en un repositorio público oficial como NPM, PyPI o RubyGems. Al dar a los envíos el mismo nombre de paquete que las dependencias utilizadas por empresas como Apple, Microsoft, Tesla y otras 33 empresas, Birsan pudo hacer que estas empresas descargaran e instalaran automáticamente el código falsificado.

Descarga automática

Las dependencias son bibliotecas de códigos públicos o paquetes que los desarrolladores usan para agregar tipos comunes de funcionalidad al software que escriben. Al aprovechar el trabajo de miles de sus pares de código abierto, los desarrolladores se ahorran la molestia y el gasto de crear el código ellos mismos. El código del desarrollador descarga e incorpora automáticamente la dependencia, o cualquier actualización, ya sea desde la computadora local del desarrollador o desde un repositorio público.

Birsan revisó foros de Internet, código JavaScript, paquetes internos publicados accidentalmente y otras fuentes para encontrar los nombres de las dependencias de código utilizadas en el software de 35 empresas. Luego subió su propio código a NPM, PyPI o Ruby Gems usando los mismos nombres de dependencia. En otras palabras, el investigador estaba usurpando el nombre auténtico del paquete perteneciente a las empresas. El investigador terminó recibiendo $ 130,000 en recompensas por errores.

Al dar a los paquetes números de versión más altos que los auténticos, las empresas seleccionadas descargaron y ejecutaron automáticamente los paquetes falsificados de Birsan.

“La tasa de éxito fue simplemente asombrosa”, escribió Birsan. Añadió:

Desde errores puntuales cometidos por desarrolladores en sus propias máquinas hasta servidores de compilación internos o basados ​​en la nube mal configurados y canalizaciones de desarrollo sistémicamente vulnerables, una cosa estaba clara: ocupar nombres de paquetes internos válidos era un método casi seguro para entrar en el redes de algunas de las compañías tecnológicas más grandes, obteniendo la ejecución remota de código y posiblemente permitiendo a los atacantes agregar puertas traseras durante las compilaciones.

Dos días después de que Birsan publicara sus resultados, la compañía de seguridad Sonatype dijo el viernes pasado que otros desarrolladores o investigadores habían llevado a cabo ataques de imitación y habían colocado 150 paquetes con nombres similares en NPM.

Cómo funciona

Los administradores de paquetes generalmente aceptan dependencias enumeradas como nombres e intentan analizar las intenciones de los desarrolladores. Los administradores buscan dependencias tanto en la computadora local donde se almacena el proyecto como en el directorio accesible a Internet que pertenece al administrador de paquetes.

“El problema de la confusión de dependencias es una falla de diseño inherente en las herramientas de instalación nativas y los flujos de trabajo de DevOps que introducen dependencias en su cadena de suministro de software”, escribieron los investigadores de Sonatype en un artículo anterior sobre el ataque de Birsan. “En este contexto, la confusión de dependencia se refiere a la incapacidad de su entorno de desarrollo para distinguir entre un paquete presente privado creado internamente en su compilación de software y un paquete con el mismo nombre disponible en un repositorio de software público”.

Los investigadores de Sonatype continuaron explicando la técnica de esta manera:

Por ejemplo, supongamos que su aplicación utiliza un componente PyPI interno creado de forma privada llamado foobar (versión 1) como dependencia. Posteriormente, si se publica un componente no relacionado con el mismo nombre pero con un número de versión superior foobar (versión 9999) en el repositorio público de descargas de PyPI, la configuración predeterminada de los entornos de desarrollo de PyPI dicta que foobar con la versión superior se descargue como una dependencia.

En este caso, eso significaría que el paquete foobar falsificado del atacante con un número de versión más alto entraría silenciosa y automáticamente en su compilación de software.

Los llamados ataques de typo-squatting existen desde hace años. Cargan código en repositorios públicos y usan nombres que son similares a los nombres de paquetes legítimos con la esperanza de que un desarrollador cometa un error tipográfico o haga clic en un enlace malicioso que haga que se descargue el código falso. La ventaja de la técnica de confusión de dependencias de Birsan es que no depende del error humano para funcionar.

Si bien las empresas afectadas no detectaron la falsificación, Sonatype sí lo hizo. Después de consultar con Birsan, la empresa se enteró de que las dependencias falsas eran parte de un experimento benigno.

Prueba de concepto

Birsan descubrió que las 35 empresas afectadas usaban dependencias almacenadas localmente que no estaban disponibles en el directorio público. Cuando cargó su propio código malicioso de prueba de concepto en un repositorio público con el mismo nombre que la dependencia legítima y un número de versión más alto, el software de las empresas los instaló y ejecutó automáticamente.

Para evitar entrar en conflicto con las políticas de informe de vulnerabilidades de las empresas, el código de Birsan limitó sus actividades a enviar el nombre de usuario, el nombre de host y el parche actual de cada instalación única al investigador. También tenía permiso para probar la seguridad de las 35 empresas, ya sea a través de programas públicos de recompensas por errores o acuerdos privados.

Para garantizar que las defensas de seguridad no impidieran que la información saliera de la red de la empresa objetivo, el código PoC de Birsan codificó los datos en forma hexadecimal y los envió en una consulta de DNS. El fracaso de las empresas para bloquear el tráfico se produce al menos cuatro años después de que el uso de la exfiltración de DNS por parte del malware llamara la atención de los investigadores.

La empresa canadiense de comercio electrónico Shopify instaló automáticamente una Ruby Gem llamada shopify-cloud a las pocas horas de que Birsan la pusiera a disposición en el repositorio de Ruby Gems. Mientras tanto, varias máquinas dentro de la red de Apple ejecutaron el código que Birsan cargó en NPM. Birsan dijo que los proyectos de Apple afectados parecían estar relacionados con Apple ID, el sistema de autenticación de la compañía. Tanto Shopify como Apple otorgaron a Birsan recompensas de $ 30,000 cada uno.

Sonatype tiene una lista de pasos aquí que los desarrolladores pueden tomar para prevenir ataques de confusión de dependencia. La principal de las defensas es que los repositorios hagan cumplir la verificación obligatoria del espacio de nombres y el alcance. Una técnica de verificación es el uso inverso del nombre de dominio completo, que permite a los propietarios legítimos de una marca o espacio de nombres publicar componentes en ese espacio de nombres y mantener alejados a los adversarios.

Artículo Recomendado:  Signal finalmente está llevando su mensajería segura a las masas

Publicaciones relacionadas

Deja una respuesta

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

Botón volver arriba