Colaboración entre Level 3 y Cisco para destruir a las Botnets (redes robóticas)

La habilidad de la comunidad de seguridad de la información para responder ante las amenazas y descubrir vulnerabilidades mejora cada mes. La reacción colectiva de la comunidad de seguridad ante un nuevo hash de archivo, una nueva técnica o método de comunicación nunca ha sido tan sólida. No obstante, los atacantes también realizan avances, superando inclusive a las defensas del mundo de la seguridad.

Una forma de equilibrar este problema consiste no solo en focalizarse para identificar las amenazas, sino también en encontrar un método efectivo para eliminarlas de Internet. Frecuentemente se confunde la identificación del problema con la remoción del mismo, dejando a los atacantes bajo observación, pero aún con la capacidad de alcanzar sus metas.

Es por ello que los Laboratorios de Investigación sobre Amenazas de Level 3 y el Talos Group de Cisco trabajaron en forma conjunta para investigar y mitigar el riesgo que presentan el escaneo de toda la Internet en manos de un atacante y las botnet de DDoS, SSHPsychos.

Investigando a los actores maliciosos

A fines de septiembre de 2014, el blog Malware Must Die! informó sobre un nuevo malware Linux y rootkit utilizado para los ataques de DDoS. A pesar de la completa descripción, la amenaza persistió. Más de cuatro meses después, FireEye identificó un ataque de fuerza bruta SSH inusualmente grande intentando cargar el mismo malware, que aún seguía siendo un rootkit y herramienta de DDoS extremadamente efectiva cuando se combinaba con los intentos de login de fuerza bruta SSH.

Afortunadamente para la Comunidad de Internet, el Talos Group de Cisco continuó trabajando en esta campaña y realizando un seguimiento. En el primer trimestre de 2015, los señuelos o honeypots de Talos tuvieron más intentos de autenticación de este atacante en particular (103.41.125.0/23 y 43.255.190.0/23) que de todos los demás en su conjunto.

Claramente la toma de conocimiento de la comunidad de seguridad respecto del evento en general no fue suficiente para desalentar al atacante y había que hacer algo más sustancial para que ocurriera alguna mejora.

Nuestra meta, al confirmar un riesgo para Internet, consiste en eliminarlo lo más ampliamente posible; no obstante, antes de eliminar algo de la Internet, es importante entender acabadamente el impacto que puede tener para anfitriones más benignos. Y para lograrlo, es necesario contar con más información acerca de las herramientas e infraestructura del atacante.

Los datos del honeypot del Talos Group permitieron identificar qué acciones se tomaron luego de que tuviera lugar un login exitoso de fuerza bruta de raíz SSH. En este ejemplo, la cadena de eventos condujo a la descarga de un archivo de un servidor web, ejecutándose en 23.234.60.140 (resuelto desde ftp.rxxiaoao.com) y 23.234.19.202. El primer host inserta /instala archivos denominados 8000.rar a través de 8008.rar, y el segundo a06 a través de a11 dentro del /directorio i.

Una vez descargados los archivos, el equipo de Investigaciones de Amenazas de Level 3 confirmó la información suministrada en el blog Malware Must Die! de septiembre, el nombre del archivo está estructurado para alinearse con el puerto en donde tendrá lugar la eventual comunicación con la botnet. Sin embargo, el atacante se había movilizado desde el puerto 3502 a través del 3505 que fueron utilizados nuevamente en septiembre y ahora están usando los puertos TCP 8000 hasta el 8008 y 3306.

Monitoreo de la Comunicación Botnet en acción

Después de recuperar y ejecutar el binario ejecutable desde la __download_url__ en 23.234.60.140 y 23.234.19.202, el bot comienza inmediatamente a buscar su anfitrión de comando y de control. El ejecutable registra los códigos 8.8.8.8 y 8.8.4.4 como sus resolvedores de DNS y procede a intentar resolución DNS para los nombres de host configurados. Luego, intenta conexiones con las IP y nombres host resueltos que estaban contenidos dentro de la línea __remote__ del shell script.

En el caso de nuestra máquina virtual (VM) las diversas versiones del malware pudieron establecer conectividad con C2s en:

• 103.240.140.152 (resuelto desde ndns.dsaj2a.org y ns2.hostasa.org)
• 162.218.112.7 (resuelto a partir de ndns.dsaj2a1.org)
• 104.143.5.25 (resuelto a partir de ndns.dsaj2a1.org y ns1.hostasa.org)
• 103.240.141.54 (resuelto a partir de ndns.dsaj2a.com, ndns.hcxiaoao.com, y ns3.hostasa.org)

Otras conductas de comunicación ocurrieron tal como se esperaba: Como parte de una botnet de DDoS, nuestro bot tenía la instrucción de lanzar inundaciones SYN (SYN floods) cada vez que se conectaba a la C2. Los paquetes SYN no tenían ningún relleno para maximizar el uso de la banda ancha y no se molestaron en tener que crear una conexión falsa de origen (spoof). La comunicación de ataque desde el C2 ordenándole a nuestro bot que atacara, fue confirmada como XORed con la misma clave (BB2FA36AAA9541F0) que ha estado en uso desde la investigación original del malware.

Impacto a la víctima

Fuente: laboratorios de Investigación de Amenazas de Level 3

Durante dos semanas a fines de marzo y principios de abril, monitoreamos un amplio número de IP escaneadas por los atacantes. También identificamos cuáles hosts en Internet eran participantes activos en la botnet. De los hosts de la botnet, podemos ver que las comunicaciones C2 se dan entre los puertos TCP 8000-8008 y 3306, como se aprecia en la versión actual del malware. No obstante, una serie de hosts seguían aún comunicándose por los puertos TCP 3502-3508 como vimos en las versiones previas.

Luego de evaluar la escala masiva, impacto y duración, decidimos que era hora de trabajar para sacar a esta infraestructura maliciosa de circulación de la Internet.

Qué debería hacer

Para quienes tengan máquinas Linux ejecutando sshd en la Internet abierta, asegúrense de seguir las mejores prácticas para inhabilitar login raíz en su archivo de configuración sshd. Ya con esa medida estaría evitando que este atacante en particular tenga éxito en su entorno.

Adicionalmente, debería considerar ejecutar su demonio SSH de modo tal que evite estos tipos de ataques. Ejecutar un firewall localmente en la máquina Linux para protegerse de intentos de ataques desconocidos es una medida sólida cuando es posible. Sin embargo, cuando ocurre un escaneado no sofisticado, aún la medida extremadamente simple de ejecutar SSH en un puerto no estándar puede utilizarse como un método de prevención. La mayoría de los escáneres de commodity y clientes de malware no buscarán servicios en puertos no estándar.

Resulta asimismo importante asegurarse que las contraseñas tengan una complejidad mínima y que los ataques comunes de diccionario no sean efectivos contra la contraseña de cualquier usuario. Para ayudarlo a protegerse de este problema, hemos anexado las contraseñas que este atacante intentó y que fueran compiladas por los honeypots de Cisco. El listado, disponible aquí, puede encriptarse y compararse a las contraseñas de los usuarios para validar que no puedan ser atacadas fácilmente.

Asimismo recomendamos que todo el mundo monitoree el tráfico DNS que atraviesa sus redes buscando anomalías. Este malware en particular pre-programó IP resolvedoras abiertas que habrían sido un indicador para las víctimas infectadas sobre la presencia de anomalías en su entorno.