Una nueva campaña de ataque «coordinada» a la cadena de suministro ha afectado a ocho paquetes en empaquetador incluido código malicioso diseñado para ejecutar un binario de Linux recuperado de una URL de versiones de GitHub.

«Aunque los paquetes afectados eran todos paquetes de Composer, el código malicioso no se agregó a compositor.json», Socket dicho. «En cambio, se insertó en package.json, dirigido a proyectos que incluyen herramientas de compilación de JavaScript junto con código PHP».

Esta «ubicación entre ecosistemas» hace que la actividad se destaque porque los desarrolladores y equipos de seguridad que escanean las dependencias de PHP solo pueden centrarse en los metadatos relacionados con Composer, mientras omiten los ganchos del ciclo de vida de package.json que están incluidos en el paquete. Desde entonces, las versiones maliciosas se han eliminado de Packagist.

Un análisis de los paquetes ha descubierto que sus repositorios ascendentes han sido modificados para incluir un script posterior a la instalación que intenta descargar un binario de Linux desde una URL de versiones de GitHub («github[.]com/parikhpreyash4/systemd-network-helper-aa5c751f»), guárdelo en la carpeta «/tmp/.sshd», cambie sus permisos usando «chmod» para otorgar permisos de ejecución a todos los usuarios y ejecútelo en segundo plano.

Los nombres de los paquetes y la versión afectada asociada se enumeran a continuación:

• moritz-sauer-13/silverstripe-cms-theme (dev-master)
• crosiersource/crosierlib-base (dev-master)
• devdojo/wave (dev-principal)
• devdojo/génesis (dev-main)
• katanaui/katana (dev-principal)
• elitedevsquad/sidecar-laravel (3.x-dev)
• r2luna/cerebro (dev-principal)
• baskarcm/tzi-chat-ui (dev-principal)

La investigación de Socket encontró referencias a la misma carga útil en 777 archivos en GitHub, lo que sugiere que podría ser parte de una campaña más amplia. en al menos dos instanciasse agregó a un flujo de trabajo de GitHub. Sin embargo, actualmente no se sabe cuántos de estos coinciden con distintos compromisos, bifurcaciones, artefactos de paquetes duplicados o referencias almacenadas en caché.

«Esto sugiere que el atacante no confiaba en un único mecanismo de ejecución. En los artefactos del paquete, la carga útil se activaba a través de scripts postinstalación package.json», dijo la firma de seguridad de aplicaciones. «En los archivos de flujo de trabajo, estaba posicionado para ejecutarse durante los trabajos de GitHub Actions».

Es más, la naturaleza exacta de la carga útil descargada de GitHub no está clara, ya que cuenta GitHub asociado con el alojamiento del repositorio ya no está disponible. La elección del nombre «gvfsd-network» para el malware es interesante, ya que se refiere a un demonio del sistema de archivos virtual GNOME (GVfs). responsable para administrar y explorar recursos compartidos de red.

«Incluso sin el binario de segunda etapa, el instalador malicioso es suficiente para justificar el bloqueo», dijo Socket. «Proporciona ejecución remota de código durante la instalación o creación de flujos de trabajo e intenta ocultar su actividad desactivando la verificación TLS, suprimiendo errores y ejecutando un binario descargado en segundo plano».

Los investigadores de ciberseguridad han marcado Paquetes PHP maliciosos de Packagist disfrazados de utilidades de Laravel que actúan como conducto para un troyano de acceso remoto (RAT) multiplataforma que funciona en sistemas Windows, macOS y Linux.

Los nombres de los paquetes se enumeran a continuación –

• nhattuanbl/lara-helper (37 Descargas)
• nhattuanbl/simple-queue (29 Descargas)
• nhattuanbl/lara-swagger (49 Descargas)

Según Socket, el paquete «nhattuanbl/lara-swagger» no incorpora directamente código malicioso, sino que enumera «nhattuanbl/lara-helper» como un Dependencia del compositorprovocando que instale el RAT. Los paquetes todavía están disponibles para descargar desde el registro de paquetes PHP.

Se ha descubierto que tanto lara-helper como simple-queue contienen un archivo PHP llamado «src/helper.php», que emplea una serie de trucos para complicar el análisis estático mediante el uso de técnicas como la ofuscación del flujo de control, la codificación de nombres de dominio, nombres de comandos y rutas de archivos, e identificadores aleatorios para nombres de variables y funciones.

«Una vez cargada, la carga útil se conecta a un servidor C2 en helper.leuleu[.]net:2096, envía datos de reconocimiento del sistema y espera comandos, dándole al operador acceso remoto completo al host», dijo el investigador de seguridad Kush Pandya.

Esto incluye el envío de información del sistema y el análisis de comandos recibidos del servidor C2 para su posterior ejecución en el host comprometido. La comunicación se produce a través de TCP utilizando PHP. flujo_socket_client(). La lista de comandos admitidos se encuentra a continuación:

• silbidopara enviar un latido automáticamente cada 60 segundos
• informaciónpara enviar datos de reconocimiento del sistema al servidor C2
• cmdpara ejecutar un comando de shell
• powershellpara ejecutar un comando de PowerShell
• correrpara ejecutar un comando de shell en segundo plano
• captura de pantallapara capturar la pantalla usando imagegrabscreen()
• descargarpara leer un archivo del disco
• subira un archivo en el disco y otorgarle permisos de lectura, escritura y ejecución a todos los usuarios
• deteneral enchufe y salir

«Para la ejecución del shell, RAT prueba las funciones deshabilitadas y elige el primer método disponible entre: popen, proc_open, exec, shell_exec, system, passthru», dijo Pandya. «Esto lo hace resistente a las configuraciones comunes de refuerzo de PHP».

Si bien el servidor C2 actualmente no responde, el RAT está configurado de manera que reintenta la conexión cada 15 segundos en un bucle persistente, lo que lo convierte en un riesgo para la seguridad. Se recomienda a los usuarios que hayan instalado los paquetes que asuman un compromiso, los eliminen, roten todos los secretos accesibles desde el entorno de la aplicación y auditen el tráfico saliente al servidor C2.

Además de los tres paquetes antes mencionados, el actor de amenazas detrás de la operación ha publicado otras tres bibliotecas («nhattuanbl/lara-media», «nhattuanbl/snooze» y «nhattuanbl/syslog») que están limpias, probablemente en un esfuerzo por generar credibilidad y engañar a los usuarios para que instalen los maliciosos.

«Cualquier aplicación Laravel que instale lara-helper o simple-queue ejecuta una RAT persistente. El actor de la amenaza tiene acceso completo al shell remoto, puede leer y escribir archivos arbitrarios y recibe un perfil de sistema continuo para cada host conectado», dijo Socket.

«Debido a que la activación ocurre en el inicio de la aplicación (a través del proveedor de servicios) o en las cargas automáticas de clases (a través de una cola simple), el RAT se ejecuta en el mismo proceso que la aplicación web con los mismos permisos del sistema de archivos y variables de entorno, incluidas las credenciales de la base de datos, las claves API y los contenidos .env».