El ataque de la cadena de suministro de GitHub utiliza malware de Octopus Scanner


Octopus Scanner es un nuevo malware utilizado para comprometer 26 proyectos de código abierto en un ataque masivo de la cadena de suministro de GitHub.

El 9 de marzo, el Equipo de Respuesta a Incidentes de Seguridad de GitHub (SIRT) recibió un mensaje del investigador de seguridad JJ, quien había descubierto un conjunto de repositorios de GitHub que sirven activamente malware. Un análisis profundo del malware reveló que fue creado para comprometer los proyectos de NetBeans, algo que no habían visto antes en GitHub. Todos los proyectos afectados estaban sirviendo activamente código retroactivo, y los propietarios de estos repositorios lo ignoraban por completo.

Nico Waisman, jefe de GitHub Security Lab, dice que el primer paso en su investigación fue identificar si la campaña aún estaba activa. Una vez que se completó la evaluación crítica y se enteraron de que el servidor de comando y management (C2) no estaba activo, pudieron reducir el nivel de riesgo y examinar más de cerca Octopus Scanner, un malware de cadena de suministro de código abierto.

«La característica única de este malware es que se dirige a los desarrolladores como medio de propagación», explica Waisman. «Una vez que la computadora se infecta, busca archivos NetBeans para infectar». Mientras que los usuarios de GitHub, como desarrolladores, deberían estar preocupados por este malware que united states desarrolladores para propagación, Waisman señala que esta técnica en specific es «extremadamente rara».

Cuando Octopus Scanner aterriza en una máquina, busca señales que indiquen que el IDE de NetBeans está en uso en el sistema de un desarrollador, explica el investigador de seguridad de GitHub Alvaro Muñoz en una publicación de blog sobre sus hallazgos. Si no encuentra nada, el malware no realiza ninguna acción. Si lo hace, asegura que cada vez que se construye un proyecto, cualquier archivo JAR resultante se infecte con un cuentagotas. Cuando se ejecuta, la carga útil asegura la persistencia y extiende un troyano de acceso remoto (RAT), que se conecta a los servidores C2.

El malware continúa propagándose infectando proyectos de NetBeans o archivos JAR. De esta manera, cierra proyectos saludables, por lo que cuando los desarrolladores lanzan el código al público, contiene malware. El objetivo de Octopus Scanner es insertar puertas traseras en los artefactos construidos por NetBeans para que el atacante pueda usar estos recursos como parte del servidor C2, dice Waisman.

«Cuando el usuario last despliega la carga de trabajo, le ha dado acceso al atacante a través de la puerta trasera a sus recursos para usarlos como parte de un servidor de comando y regulate», agrega.

Octopus Scanner también intenta evitar que las nuevas compilaciones de proyectos reemplacen a las infectadas. Esto garantiza que los componentes de compilación maliciosos permanezcan en su lugar. Mientras investigaba los repositorios infectados, GitHub encontró cuatro versiones diferentes de los proyectos NetBeans afectados. Todos menos uno de ellos, un sistema posterior, se infectaría ya sea construyendo desde un repositorio infectado o utilizando cualquiera de los artefactos comprometidos que provienen de una construcción infectada, escribió Muñoz.

«Infectar artefactos de construcción es un medio para infectar más hosts, ya que el proyecto infectado probablemente será construido por otros sistemas y los artefactos de construcción probablemente también se cargarán y ejecutarán en otros sistemas», explica en el entrada en el site.

Es interesante que los atacantes elijan específicamente el proceso de compilación de NetBeans, especialmente porque no es el IDE de Java más común. Esto podría indicar un ataque dirigido, dice Muñoz, o es posible que ya hayan implementado el malware para sistemas de compilación como Make, MsBuild o Gradle, y podría estar propagándose desapercibido.

Amenazas en la cadena de suministro: lo que debe saber
Los desarrolladores y las empresas dependen cada vez más del código fuente abierto, dice Waisman. El código abierto es fácil para los desarrolladores, lo que significa que también es fácil para los adversarios. Los atacantes buscan compromisos en la cadena de suministro porque pueden tener un alcance generalizado: un solo ataque puede darles acceso a múltiples objetivos. Y como señala Muñoz, el malware que abusa del proceso de compilación y sus artefactos resultantes es «interesante y preocupante» por varias razones.

En un contexto de código abierto, esto le da al malware un medio efectivo de propagación. Los proyectos infectados probablemente serán clonados y utilizados en diferentes sistemas, y los artefactos de las construcciones pueden extenderse aún más, lo que hace que sea más difícil de rastrear.

Debido a que los principales usuarios de estos repositorios son desarrolladores, una intrusión exitosa podría dar a los atacantes acceso a los mismos recursos que usan los desarrolladores. Estos pueden incluir contraseñas adicionales, entornos de producción, contraseñas de bases de datos y otros activos confidenciales, agrega.

Si bien los compromisos de la cadena de suministro como este dan miedo, Waisman dice que siguen siendo raros.

«El problema principal en la seguridad de la cadena de suministro es el computer software sin parches», explica. «Es mucho más fácil para un atacante aprovechar una vulnerabilidad conocida sin parches en una dependencia que insertar una nueva vulnerabilidad en su código».

Para los desarrolladores, el desafío es conocer sus dependencias y saber cuándo deben ser parcheados. GitHub tiene como objetivo ayudar con esto a través del Gráfico de dependencia, que ayuda a los usuarios a comprender mejor las dependencias de sus proyectos y proporciona alertas de seguridad cuando una dependencia tiene una vulnerabilidad, dice. Para los mantenedores de código abierto, el desafío es prevenir problemas y responder cuando sea necesario. En GitHub, los encargados del mantenimiento pueden crear un archivo stability.md con su política de informes y divulgación, crear correcciones cuando sea necesario y publicar avisos de seguridad.

«En última instancia, se trata de emerger, coordinar y compartir información entre múltiples partes, incluidos desarrolladores, mantenedores de código abierto, investigadores de seguridad y empresas», dice Waisman.

Contenido relacionado:

Aprenda de los expertos de la industria en un entorno propicio para la interacción y la conversación sobre cómo prepararse para eso «realmente mal día «en ciberseguridad. Haga clic para más información y para registrarse.

Kelly Sheridan es la Editora de personalized de Dim Examining, donde se enfoca en noticias y análisis de seguridad cibernética. Ella es una periodista de tecnología de negocios que informó anteriormente para InformationWeek, donde cubrió Microsoft, y Insurance policy & Technology, donde cubrió asuntos financieros … Ver biografía completa

Lectura recomendada:

Más concepts





Enlace a la noticia initial