La unión hace la fuerza– Etapas colaborativas para destruir a las Botnets (redes robóticas): Cómo Level 3 y Cisco trabajaron en conjunto para mejorar la seguridad de Internet y frenar a los SSHPsychos

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.

A fines de marzo, Level 3 comenzó sus tratativas con el Talos Group de Cisco para trabajar en tándem, con el fin de mitigar esta amenaza para Internet. Los datos de la red de Level 3 confirmaron la escala masiva lograda por este atacante al compararla con todo el tráfico de Internet para SSH. Por momentos, este solo atacante fue responsable de más del 35% del total del tráfico SSH de Internet.

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.

El primer archivo del host es un shell script más detallado, que provee una visión sobre parte de la lógica usada por el atacante. A pesar llevar por nombre una extensión .rar, cada archivo es realmente un shell script Unix, que utiliza la misma ofuscación que en septiembre:

dec(){ echo $@|tr “[a-zA-Z0-9\;-=+*\/]” “[.0-9a-zA-Z\/\/\:]”; }

La cadena de caracteres de traducción no cambió en absoluto.

Esta simple función bash dec() toma el texto ofuscado y traduce los caracteres nuevamente al texto propuesto. Con esta función podemos extraer las cadenas de caracteres interesantes desde el archivo 8000.rar file recuperado:

Las líneas más importantes aquí son las de la variable __download_url__ donde se recupera la ejecutable real y la variable __remote__, que se usa para comunicación de comando y control.

La única diferencia entre cada script (8000.rar vs 8008.rar por ejemplo) es el nombre del documento __download_url__ y los números de puerto para cambio __remote__, que coinciden con el número del nombre del archivo del script.

Luego de confirmar que el malware no había tenido ningún cambio estructural, los Laboratorios de Investigación de Amenazas de Level 3 lo cargaron dentro de un CentOS 7 VM como raíz y lo observaron trabajar.

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.

La otra comunicación digna de destacar fue la recuperación cada 30 minutos de /config.rar desde el sitio original que alojaba al malware (23.234.60.140), esta vez resolviendo el nombre host info.3000uc.com. El archivo fue recuperado con el usuario-agente: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; TencentTraveler ; .NET CLR 1.1.4322)

Este archivo, al igual que los demás, no era un archivo RAR, sino que esta vez era XORed con la misma clave de 128bit que la comunicación C2. Después de decodificarla, el equipo descubrió un archivo de configuración que contenía las siguientes claves: md5, denyip, filename, y rmfile. Los mismos contienen valores que hacen referencia a una serie de otros troyanos y malware conocidos. Los investigadores en avast! confirmaron que la configuración se usa para remover y destruir al malware competidor de modo que el bot pueda tener control total de la máquina.

Los contenidos actuales del archivo decodificado pueden leerse aquía modo de una fuente que le ayude a encontrar indicadores de que otros atacantes están comprometiendo su red.

Ahora que hemos confirmado qué hace el malware, cómo se comunica, y con quién está hablando, comenzamos a evaluar su impacto a las víctimas en la Internet en general.

Impacto a la víctima

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.

Desmantelamiento

El martes 7 de abril de 2015, Level 3 intervino creando un gran agujero negro para atraer todo el tráfico del atacante hacia nuestras redes globales.  De esta manera nos aseguramos de que ningún tráfico del atacante se enviaría exitosamente a través de Level 3. Comenzamos a comunicarnos con otros operadores de red, informándoles acerca de la amenaza y solicitándoles que siguieran nuestro ejemplo para eliminarla de la Internet global en forma permanente.

Asimismo estamos monitoreando las acciones del atacante para estar atentos ante cualquier cambio que realicen a la infraestructura de ataque. A lo largo del período de análisis el atacante cambió sus operaciones de escaneo SSH de 103.41.124.0/23 a 43.255.190.0/23, junto con cambios múltiples de C2 e IP de malware. Nuestro equipo espera continuar con este monitoreo en la medida que el atacante intente resucitar su capacidad de DDoS.

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.

Naturalmente, que debería revisar el tráfico a cualquiera de las IP o nombres host mencionados aquí para asegurarse de que no tiene ningún dispositivo hablando o comunicándose con el atacante o participando de la botnet:

Defendiendo Internet

Con posterioridad al hallazgo de un ataque, resulta crítico que la comunidad de seguridad limpie la infraestructura del atacante y su habilidad de ejecutar, en lugar de simplemente observar el problema. Dicha colaboración lleva a una mejora en la postura de seguridad de Internet en su conjunto. En el caso de los SSHPsychos, el trabajo realizado por los equipos combinados de Level 3 y Cisco ha arrojado como resultado una mejora en la seguridad para todos aquellos que usen Internet. En Level 3 y Cisco esperamos continuar con dicha tendencia juntos y ver que otros se sumen a nuestros esfuerzos. La unión hace la fuerza.