DoubleDoor: IoT Botnet evita el firewall y la seguridad de los módems utilizando dos exploits
Introducción
En dos años, los ataques de IoT han experimentado una rápida evolución. Ahora vemos que las amenazas de IoT, que ya han evolucionado desde ataques admin: admin, hasta el uso de exploits están evolucionando no solo para eludir la autenticación IoT, sino que también están listas para luchar contra una capa adicional de seguridad, es decir, un firewall que protege el dispositivo. En consecuencia, si un usuario experto en seguridad tiene un conjunto de autenticación para el IoT especificado y lo protege mediante un firewall, esta campaña afectará ambas capas de seguridad y el control del dispositivo estará en manos de los botmasters de DoubleDoor.
Las puertas traseras
Como se observó en nuestros registros de honeypot, vimos que los ataques incorporan dos exploits de puerta trasera conocidos para encargarse de dos niveles de autenticaciones. En un principio, CVE-2015-7755 se implementó para hacer uso del infame exploit del sistema operativo SmartScreen de Juniper Networks, que esencialmente permite a uno pasar la autenticación del cortafuegos. Una vez que haya tenido éxito, el exploit de puerta trasera del módem Zyxel CVE-2016-10401 se implementará para tomar el control total del dispositivo. Todo el ciclo de ataque se puede simplificar en el siguiente diagrama.
Las puertas traseras
Como se observó en nuestros registros de honeypot, vimos que los ataques incorporan dos exploits de puerta trasera conocidos para encargarse de dos niveles de autenticaciones. En un principio, CVE-2015-7755 se implementó para hacer uso del infame exploit del sistema operativo SmartScreen de Juniper Networks, que esencialmente permite a uno pasar la autenticación del cortafuegos. Una vez que haya tenido éxito, el exploit de puerta trasera del módem Zyxel CVE-2016-10401 se implementará para tomar el control total del dispositivo. Todo el ciclo de ataque se puede simplificar en el siguiente diagrama.
CVE-2015-7755 es una puerta trasera en el software ScreenOS de Juniper Networks que impulsa sus firewalls Netscreen. La implementación de esta puerta trasera es sencilla. Esencialmente, se puede acceder a los daemons telnet y SSH de los firewalls Netscreen utilizando la contraseña codificada <<<% s (un = '% s') =% u con cualquier nombre de usuario, independientemente de si es válido o no. Vimos su implementación en el ciclo de ataque inicial de DoubleDoor, ya que atacó a nuestros honeypots con el nombre de usuario "netscreen" y la contraseña de puerta trasera.
Sin embargo, la saga de la puerta trasera no terminó aquí. Después de eludir la protección del firewall, DoubleDoor usó otra puerta trasera en nuestros honeypots. Esta vez fue CVE-2016-10401, una puerta trasera para dispositivos ZyXEL PK5001Z. Esta puerta trasera también es directa, con una contraseña de contraseña codificada como zyad5001.
CVE-2016-10401 es una explotación de escalada de privilegios, por lo que los atacantes de DoubleDoor también realizaron un ataque basado en contraseñas para obtener una cuenta de privilegio básica como administrador: CenturyL1nk antes de ir en busca del superusuario. CVE-2016-10401 se ha usado en una gran cantidad de ataques de IoT desde noviembre de 2017.
Polimorfismo en el reconocimiento: dificultando el papel de la detección
Una fase común en muchas campañas de malware, incluidas las campañas de ataque de IoT, es la fase de reconocimiento. Esta fase se ha observado en casi todas las campañas de botnets IoT, comenzando desde Mirai. En términos simples, después de que los actores de la amenaza hayan realizado el ataque, quieren una confirmación de si lograron obtener el control del dispositivo de IoT. Para esto, intentan invocar el shell con comandos no válidos. Si el atacante ha tenido éxito, se mostrará "{string}: applet no found" donde {string} es el comando no válido.
Muchos atacantes utilizan una variedad de cadenas aquí para cumplir este propósito. Muchos usan el nombre de la botnet en sí (como MIRAI, ASUNA, MASUTA, SATORI) o su propio seudónimo como daddyl33t. Tal actividad de reconocimiento actúa como una espada de doble filo. Aunque cumple el propósito del atacante, estas cadenas facilitan la tarea de detección basada en comportamiento / estática ya que estas cadenas indican que un botnet IoT está tratando de interferir con el dispositivo. DoubleDoor botnet se encarga de esto, mediante el uso de una cadena aleatoria en cada ataque (como se muestra en la imagen a continuación). La falta de una cadena estándar garantizará que no sea muy fácil clasificar la actividad de reconocimiento como maliciosa. Sin embargo, las cuerdas tienen una cosa en común, siempre son de 8 de largo.
Las cadenas de reconocimiento aleatorizadas utilizadas por DoubleDoor a la izquierda frente a las cadenas "fáciles de clasificar" utilizadas por redes de bots IoT prominentes a la derecha.
Conclusión
Los ataques botnet de DoubleDoor parecen estar en su fase naciente, ya que observamos los ataques solo durante un período del 18 de enero de 2018 al 27 de enero de 2018, con ataques que se originan principalmente en IPs de Corea del Sur. A pesar de que el código es interesante, se espera que el recuento de dispositivos en este ataque específico de DoubleDoor sea bajo ya que el ataque solo tendrá éxito si la víctima tiene una versión específica sin parche del firewall Juniper ScreenOS que protege los módems Zyxel sin parchear. La doble capa de protección IoT es más común en entornos corporativos, que no dependen de la autenticación IoT incorporada y desean protegerla con otra capa de firewall. Aunque estos dispositivos corporativos pueden ser menos numerosos, obtener el control de los enrutadores del entorno corporativo puede ser más valioso para un atacante, ya que puede conducir a ataques de IoT dirigidos. Los malwares relacionados con Microsoft Windows han dominado el arte de la evasión en varias capas, ya que una sola campaña a menudo intenta varios niveles de evasión (filtros de spam/detección estática antivirus/detección de comportamiento). Después de ver ataques de botnet DoubleDoor, parece que las campañas de ataques de IoT no se demorarán demasiado.