Análisis de Linux.Haikai: dentro del código fuente

Hace unos días conseguimos el código fuente del malware Haikai, el cual corresponde a una más de la multitud de implementaciones llevadas a cabo por el continuo reciclaje de código fuente perteneciente a diferentes botnets IoT. A pesar de que no hemos identificado ninguna novedad respecto a versiones de malware IoT anteriores, nos ha permitido la obtención de mucha información sobre las técnicas, mejoras y autores.

Comentar también que, según diferentes registros obtenidos, esta botnet ha estado actuando durante gran parte del último mes de junio.

En las siguientes líneas se analizará el código, así como las posibles atribuciones y las implementaciones no referenciadas en el hilo de ejecución, las cuales nos permiten adivinar que el código va mutando en diferentes líneas en paralelo para una misma función.

Así pues vamos a comenzar analizando la estructura de los ficheros.

Archivos en el código fuente de Haikai

Archivos en el código fuente de Mirai

Tal y como podemos observar, todos los archivos (a excepción de g.c), tienen la misma nomenclatura que el malware Mirai. A pesar de ello, la mayoría del código que es llamado en el hilo de ejecución se encuentra en g.c; y otras funciones muy interesantes incorporadas por Mirai en 2016 (como aquellas incluidas en el fichero scanner.c), son obviadas por Haikai.

En cuanto al main del código, éste se encuentra en el fichero g.c. Se puede destacar que la primera acción que lleva a cabo es el chequeo del binario de Python para utilizar una longitud, y otra en la asignación del nombre del proceso, característica no presente en el código fuente de Mirai.

Nada más llevar a cabo dicho acceso, comprueba si el listado de servidores es menor o igual a 0 a través de la variable SERVER_LIST_SIZE, definida más arriba con las siguientes instrucciones.

#define SERVER_LIST_SIZE (sizeof(commServer) / sizeof(unsigned char *))
…
…
unsigned char *commServer[] = {"185.47.62[.]197"};

Seguidamente, se ejecuta la cadena de debug, para luego llamar a las funciones table_init() y killer_init().:

\x1b[31m[Hakai] \x1b[32mConnected\x1b[0m\r\n

Ambas funciones están presentes en el código fuente de Mirai e incorporan novedades que más tarde analizaremos; sin embargo, nos vamos a parar en el análisis de la función StartTheLelz().

Tal y como podemos observar en la imágen inferior, esta función está importada del malware BashLite, una de las primeras botnets IoT conocida por hacer uso de vulnerabilidades de tipo shellshock. Sin embargo, esta nueva implementación incorpora una gran serie de novedades.

Extracto del código fuente de BashLite

Mientras que la función de BashLite tiene menos de 300 líneas de código, la implementada en Haikai ronda las 600.

En ambos casos se lleva a cabo la gestión de la respuesta telnet a través de una estructura switch-case. En el caso de Haikai, a través de código comentado y el desorden en nuevos casos, evidencian un autor diferente detrás del mismo.

Llama la atención la implementación del case 70, la cual lleva a cabo un chequeo anti-honeypots a través de la comprobación de las cadenas de la arquitectura en la lista de caracteres detectbox.

char *detectbox[] = {"powerpc","mips", "arc", "x86_64", "armv7l", "armv6l", "armv5l", "armv4l", "sh4", "mipsel", "arm4", "arm5", "arm6", "ARMv6", "ARMv7", "amd64", 0};

En los siguientes casos se analiza el método idóneo para la subida de la muestra:

Finalmente, gestiona de un modo especial las arquitecturas ARMv7, ARMv4 y ARC, aunque también encontramos comentada este tipo de gestión en la arquitecturas MIPS y MPSL.

Esta gestión consiste en ejecutar a través del comando echo, el hexadecimal de un binario ajustado a la arquitectura, según listas definidas en el inicio del código. Dichas líneas son las siguientes:

char *a4[] = {"armv4l", "arm4", "ARMv5", "armv5l", 0};
char *a7[] = {"armv7l", "arm7", "ARMv7", "ARMv6", "armv6l",  0};
char *mipsel[] = {"mipsel", 0};
char *ArCc[] = {"arc", 0};

Si reconstruimos el binario, obtenemos una muestra cuya única función es llevar a cabo la descarga a través de una petición HTTP del código fuente que estamos analizando, pero compilado para su arquitectura:

Esta técnica fue implementada por primera vez por el malware Hajime.

En cuanto al resto de arquitecturas, se lleva a cabo la descarga de un script en bash, el cual, presumiblemente, llevará a cabo la descarga de los binarios de distintas arquitecturas, técnica heredada del malware Gafgyt.

Por otra parte, hemos encontrado que el número de combinaciones utilizadas en la búsqueda de potenciales víctimas es menor al número introducido en Mirai (únicamente nueve combinaciones). Además, dichas credenciales no son implementadas a través de la función scanner_init(), sino definida como variables globales al inicio del código, aunque también han sido introducidas en dicha función.

char *usernames[] = {"root\0", "root\0", "admin\0", "root\0", "adm\0", "default\0", "default\0", "root\0", "root\0"};
char *passwords[] = {"root\0", "admin\0", "admin\0", "vizxv\0", "\0", " OxhlwSG8\0", "S2fGqNFs\0", "zlxx.\0", "LsiuY7pOmZG2s\0"};

En cuanto a la comunicación con el servidor Command&Control, se ha encontrado que se rige a través de los siguientes comandos:

• QTELNET → Activa la botnet
• OFF → Para el escaneo de la red en busca de dispositivos vulnerables
• ON → Activa el escaneo de la red en busca de dispositivos vulnerables

Curiosamente, el escaneo de la red se lleva a cabo con la función StartTheLelz(), ya analizada anteriormente, cuando el archivo scanner.c y, por ende, la función scanner_init(), está implementada en el código, pero nunca es referenciada.

En cuanto a las instrucciones para la ejecución de ataques de denegación de servicio, son los siguientes:

• H → Ejecuta ataques vía HTTP
• U → Ejecuta ataques vía UDP
• S → Ejecuta ataques vía STD
• T → Ejecuta ataques vía TCP
• KT → Mata los procesos asociados al malware

Ninguno de estos ataques es novedoso, pues los hemos visto y analizada en artículos anteriores, por lo que únicamente nos centraremos en la implementación de User-Agents en el ataque HTTP, la cual permite la adición de un gran número de ellos con gran facilidad.

En cuanto a la función table_init(), implementada en el archivo table.c, permite la códificación de strings en el malware y está directamente importada de Mirai.
Los comentarios en el código nos permiten obtener la información clave en bruto y, de ese modo, profundizar en la atribución de la muestra.

En primer lugar, obtenemos el dominio del C2 el cual es hakaiboatnet[.]pw y en el cual, en el momento en el que se encontraba en funcionamiento, se tenía la siguiente visualización:

Y si seguías los pasos indicados en la web, el resultado era el siguiente:

Para redondear la “troleada”, una vez Ankit Anubhav (@ankit_anubhav), conocido researcher de malware IoT, se hizo eco del hecho en su cuenta de Twitter, el dominio incluyó una visualización de él mismo en el portal web.

Otra información hardcodeada es la safe string, donde en Mirai encontrábamos el enlace al conocido videoclip de Rick Astley “Never Gonna Give You Up”, en esta muestra tenemos: “gosh that chinese family at the other table sure ate alot”.

Ya reportamos la existencia de esta cadena en el informe “Mirai Año Uno: Evolución y Adaptación de una botnet”, y la atribuimos al grupo Lizard Squad, autores de las campañas MASUTA, MEMES y FREEPEIN de Mirai, además de la incorporación de la inyección de código hexadecimal del downloader y empaquetado UPX.
Todas esas novedades las hemos visto en el presente código.

Otro punto a destacar es la gran cantidad de código no referenciado en el hilo principal y que nos permite la obtención de información, puede que no de esta botnet en particular, pero sí de la evolución del código compartido por la comunidad.

En primer lugar es interesante destacar la implementación de nuevas direcciones a evitar por el malware a través de get_random_ip(). Mientras que Mirai evitaba un número reducido de redes, Haikai incluye las redes pertenencientes a las siguientes subredes:

Amazon
Amazon + Microsoft
Blazingfast & Nforce
Choopa & Vultr
CIA
Cloudflare
Department of Defense
Department of the Navy, Space and Naval Warfare System Command, Washington DC - SPAWAR
Digital Ocean
FBI controlled Linux servers & IPs/IP-Ranges
General Electric Company
Hewlett-Packard Company
IANA NAT reserved
IANA Special use
Internal network
Invalid address space
Loopback
Ministry of Education Computer Science
Multicast
NASA Kennedy Space Center
Naval Air Systems Command, VA
ONLINE SAS
OVH
Some more
Total Server Solutions
U.S. Department of State
US Postal Service

Captura de la función get_random_ip() de Mirai

Capturas del archivo scanner.c de Haikai

Finalmente encontramos evidencias de que la parte más interesante del código ha sido borrada, y es aquella vinculada a la infección de dispositivos a través de exploits, caracaterística las versiones más novedosas del malware IoT, como son IoTReaper, Okiru u Omni.

Destacar que un dominio utilizado por Okiru es network[.]bigbotpein[.]com, utilizado también por la variante FREEPEIN de Mirai.

Capturas del código del archivo exploit.h de Haikai

Capturas del código del archivo feg.h de Haikai

Ninguna de las funciones referenciadas se encuentran implementadas en el hilo de ejecución del malware.

Tras analizar el código fuente, podemos llegar a la conclusión de que el código tiene un origen complejo, detectando técnicas de hasta cinco malwares IoT diferentes (BashLite, Gafgyt, Mirai, Hajime e IoTReaper). Sin embargo, strings y dominios nos permiten atribuir una gran parte del código al grupo Lizard Squad (o, al menos, a alguno de sus miembros).
Por otra parte, también destacar el gran concepto de comunidad que tienen aquellos dedicados a la explotación de botnets IoT, donde, a excepción de los exploits que permitan la anticipación en un sector tan competitivo, no tienen ningún reparo en compartir aquellas mejoras implementadas en el código.