No es una sorpresa el hecho de que continuamente salgan a la luz nuevas variantes de Mirai, y más, estando al alcance de cualquiera el código fuente del bot, del sevidor CnC y del servidor de descarga. Sin embargo, todos tenían unas características relativamente parecidas (a excepción de la variante para Windows, claro).
El pasado 19 de marzo llegó a nosotros una nueva versión de Mirai que nos llamó la atención por su tamaño. Mientras que lo habitual es encontrarnos con binarios Mirai de alrededor de decenas de Kbs, esta nueva muestra tiene 1,6 Mbs. La conexión TELNET que precedió la descarga del binario es exactamente igual que en anteriores capturas.
– El presente artículo se ha basado en el análisis de la versión x86:
mirai.x86: 7e17c34cddcaeb6755c457b99a8dfe32
Indagando en la IP del servidor encargado de la distribución de las muestras, encontramos que tiene habilitado el directory listing, algo nada sorprendente de por sí. Si lo era la inclusión de dos nuevas arquitecturas que no habíamos encontrado previamente: x86_64 y x86_686, además de eliminar el soporte para arm7.
A la izquierda, el directory listing habitual en la distribución de Mirai en el servicio TELNET, mientras que a la derecha tenemos el directory listing del servidor distribuidor de la nueva versión
Del mismo modo que muestras anteriores, no tiene fingerprints del compilador, por lo que se debe de haber utilizado la misma técnica de eliminación de símbolos y secciones que fue difundida a principios del pasado septiembre:
strip" release/"$2" -S --strip-unneeded --remove-section=.note.gnu.gold-version --remove-section=.comment --remove-section=.note --remove-section=.note.gnu.build-id --remove-section=.note.ABI-tag --remove-section=.jcr --remove-section=.got.plt --remove-section=.eh_frame --remove-section=.eh_frame_ptr --remove-section=.eh_frame_hdr
Mientras que las primeras versiones contienen entre 200 y 250 funciones, el sample que hoy nos ocupa tiene más de 3000, lo que ha dificultado su análisis. Este se ha basado, fundamentalmente, en la automatización mediante r2pipe de los resultados obtenidos con comandos relacionados con las referencias a las flags de Radare2.
Entre las strings, podemos encontrar referencias a rutas de archivos pertenecientes a la librería de cifrado OpenSSL, motivo del gran tamaño de la muestra que nos ocupa, pues la incluye embebida.
Tras la ejecución en un entorno controlado, se detecta la apertura de los puertos 1756 y 42205 para la comunicación con los servidores.
Analizando el main, detectamos que las primeras referencias a las funciones table_unlock_value y table_lock_value, encargadas del descifrado y asignación de los valores de la tabla, han desaparecido. Estas contienen la información fundamental para la conexión con los servidores, por lo que podía indicar que las modificaciones relacionadas con el cifrado de la conexión estarían finalmente relacionadas con estas comunicaciones.
A la izquierda, bloque de la función main de un binario anterior de Mirai ya analizado. A la derecha, mismo bloque sin las referencias a las funciones mencionadas.
Sin embargo, estas funciones sí que existen, pues están presentes en la función attack_app_http.
Código de la función attack_app_http donde se hacen constantes llamadas a table_unlock_value
Esto puede deberse a que en versiones anteriores, la descarga del binario no era ejecutada por el bot atacante, sino durante una conexión posterior por parte de un tercer servidor (dlr). Sin embargo, todo apunta a que en esta variante se ha eliminado dicho componente de la arquitectura, pues la petición de descarga del malware por parte del dispositivo IoT, viene hardcodeada en el binario, petición que no habíamos encontrado en las muestras capturadas anteriormente.
Dado que la llamada viene en primera instancia por la función attack_parse, y esta se encarga de la gestión de la información enviada por el servidor CnC, se podría deducir que esta nueva variante absorbe la funcionalidad del malware de infección de servidores de descarga (dlr.{arq}), ejecutando él mismo dichas peticiones en caso de que así se indicara.
Parte de la petición de descarga del sample hardcodeada en el código
Petición del servidor de descarga en un ataque de otra variante de Mirai
Del mismo modo que en casos anteriores, las contraseñas hardcodeadas, siguen gestionándose en la función scanner_init. Tras más de 9 meses de difusión de la botnet, cabría pensar que los dispositivos potencialmente vulnerables estarían cerca del total. Sin embargo, viendo que nuevas muestras siguen ejecutando conexiones con las mismas contraseñas (y por tanto contra los mismos dispositivos), sabemos que el grado de infección está lejos del máximo.
Parte de la función scanner_init donde se declaran las contraseñas sin descifrar
Examinando las funciones de ataque en busca de la utilización de cifrado, encontramos que en la función attack_init se reservaba memoria para 11 ataques diferentes, mientras que en todas las muestras anteriormente detectadas únicamente se reservaba para 10. Todo indicaba que Mirai tenía un nuevo ataque en su repertorio.
Llamada al nuevo ataque desde la función attack_init
Este nuevo ataque tiene, a primera vista, la misma estructura que attack_app_http. Por ejemplo, incluye el switch con 5 cases para la asignación de los User-Agent, sin embargo, esta nueva versión incorpora continuas llamas a la librería OpenSSL
Ejemplos de funciones SSL llamadas desde attack_app_http_2
Todo apunta que este nuevo sample cifra parte de la petición de ataque para provocar la denegación de servicio. Dicho ataque aprovecharía la incapacidad del objetivo de mitigarlo si no cuenta con la clave para descifrar el tráfico, lo que repercutiría en el aumento de la efectividad del mismo.
Aun así, no es la primera referencia al uso de SSL por Mirai, pues, tal y como se puede ver en el código fuente del CnC distribuido a finales de Septiembre, ya disponía de una referencia al uso de SSL, la cual se encontraba deshabilitada. Parece que ya no es así.
Bloque de código de la función attack.go relativa al codigo fuente del CnC
Tras las nuevas medidas que están adoptando los diferentes proveedores de servicios ante el más que probable próximo ataque de Mirai, esta va creciendo en sofisticación y robustez. Y no parece que vaya dejar de hacerlo en los próximos meses. Estaremos atentos a su evolución.
