El ataque a la cadena de suministro que engañó a Apple y Microsoft está atrayendo imitadores

El ataque a la cadena de suministro que engañó a Apple y Microsoft está atrayendo imitadores

imágenes falsas

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 ahora.

La técnica fue desvelado 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 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 conseguir que estas empresas descargaran e instalaran automáticamente el código falsificado.

Pwnage automático

Las dependencias son paquetes o bibliotecas de código público 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 las molestias y los gastos 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 buscó en 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 cargó su propio código en NPM, PyPI o Ruby Gems usando los mismos nombres de dependencia. En otras palabras, el investigador estaba ocultándose en el nombre auténtico del paquete que pertenecía a las empresas. El investigador terminó recibiendo 130.000 dólares en recompensas por errores.

Al dar a los paquetes números de versión más altos que los auténticos, las empresas objetivo 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 los desarrolladores en sus propias máquinas, hasta servidores de compilación internos o basados ​​en la nube mal configurados, hasta tuberías 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 empresas de tecnología más grandes que existen, obteniendo 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 empresa de seguridad Sonotype dijo el viernes pasado que otros desarrolladores o investigadores habían llevó a cabo ataques de imitación y poner 150 paquetes con nombres similares en NPM.

Cómo funciona

Los administradores de paquetes generalmente aceptan las 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 por Internet que pertenece al administrador de paquetes.

“El problema de la confusión de dependencias es un defecto de diseño inherente en las herramientas de instalación nativas y los flujos de trabajo de DevOps que atraen las dependencias a su cadena de suministro de software”, escribieron los investigadores de Sonotype en un artículo anterior sobre el ataque de Birsan. “En este contexto, la confusión de dependencias se refiere a la incapacidad de su entorno de desarrollo para distinguir entre un paquete actual 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 Sonotype continuaron explicando la técnica de esta manera:

Por ejemplo, supongamos que su aplicación utiliza como dependencia un componente interno de PyPI creado de forma privada llamado foobar (versión 1). Más adelante, si un componente no relacionado con el mismo nombre pero con un número de versión superior foobar (versión 9999) se publica en el repositorio público de descargas de PyPI, la configuración predeterminada de los entornos de desarrollo de PyPI dicta que el foobar con la versión superior se descargue como 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 tipo cuclillas han existido durante 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 hace 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, Sonotype 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 utilizaban 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 informes 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 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 llamó la atención de los investigadores.

La empresa canadiense de comercio electrónico Shopify instaló automáticamente una Ruby Gem llamada shopify-cloud pocas horas después 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 subió a 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 recompensas de $ 30,000 a Birsan cada uno.

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

Leave a Reply

Your email address will not be published. Required fields are marked *