Blog Home Topics: DDoS , IoT , PDoS

Conversaciones con bots de IoT

ago. 01, 2017 por Radware
Conversaciones con bots de IoT

Autor : Pascal Geenens, Radware Ltd – @geenensp

Luego del ataque a Dyn con Mirai en octubre de 2016, sabíamos que estábamos frente a un punto de inflexión que podría cambiar el panorama de las amenazas DDoS en los meses o años siguientes. La Internet de las cosas (IoT) estaba destinada a convertirse en una parte importante de ese nuevo panorama. Luego del ataque, se hizo evidente la falta de seguridad en la IoT y la naturaleza poco sofisticada de las botnets que explotaron los dispositivos IoT, tales como cámaras IP, grabadoras de video digital y routers, y estos aspectos se convirtieron en el centro de atención de muchos periodistas e investigadores especializados en seguridad. La IoT comenzó como un campo de pruebas para muchos bots nuevos y, con el tiempo, se convirtió en un campo de batalla en el que bots malos, bots de sombrero blanco y bots justicieros luchan por cantidades cada vez mayores de dispositivos inseguros y mal diseñados.
 
A diciembre de 2016, la cantidad de botnets estaba en aumento.  Algunas de ellas tenían cientos de miles de bots, y podrían haber alcanzado casi 1 millón de bots si el intento de control de DT en noviembre de 2016 no hubiera hecho que 900 000 módems de Internet residenciales se negaran a funcionar tras el exploit TR-069.  La IoT se convirtió en un arma central para los ataques DDoS y es hora de que comencemos a cuantificar la amenaza y estar atentos a exploits nuevos y renovados utilizados por las botnets de IoT.
 
Debido al método de escaneo y recolección agresivo que utiliza Mirai y la abrumadora cantidad de botnets denunciadas durante los últimos nueve meses, no debería pasar mucho tiempo hasta que un dispositivo desprotegido e inseguro sea atacado y se convierta en víctima una vez que se conecta a Internet. A menos que su IP sea parte de los rangos excluidos programados en el Mirai original —que incluyen las direcciones IP del Servicio Postal de los EE. UU., el Departamento de Defensa y la Autoridad de Números Asignados en Internet (IANA), así como rangos de direcciones pertenecientes a Hewlett-Packard y General Electric— cualquier conexión a Internet, esté donde esté y sea residencial o no, probablemente reciba periódicamente intentos de infección por parte de Mirai y sus secuaces. A principios de enero, comenzamos a desplegar algunos sensores para tener una idea de cuán grave era la situación. Comenzamos con un servidor telnet muy simple de desarrollo propio que atendía el puerto 23, aceptaba cualquier combinación de nombre de usuario y contraseña, y presentaba a la parte remota algo que se parecía a un shell o una interfaz por línea de comandos.  Al rastrear las conexiones iniciales, observamos que transcurrían menos de 10 minutos entre dos conexiones sucesivas de bots que intentaban atacar nuestro nodo.  Al día de la fecha, este intervalo ha disminuido a un tiempo de tres a cinco minutos entre dos intentos de captura.
 
Dada esta actividad regular, nos propusimos crear un bot conversador (al que nos referiremos como señuelo) que mantuviera un diálogo con los bots para intentar hacerlos revelar su código binario malicioso. Algunos bots esperan ciertas respuestas a los comandos emitidos y, si estas no se proveen, desaparecen. Dado que los intentos de ataque no escaseaban, pudimos —tras un proceso iterativo— establecer un diálogo consistente con la mayoría de los bots y mantener el diálogo hasta que el atacante mostraba su verdadera identidad y nos daba la ubicación de su código binario malicioso, generalmente a través de un comando wget o ftp/tftp.
 
Como uno esperaría, la mayoría de las secuencias de comandos de instalación (droppers) eran consistentes y mostraban muchas similitudes, excepto por cierta aleatoriedad en algunos identificadores y en las ubicaciones de descarga de los archivos binarios. Al concatenar y normalizar las secuencias de comandos de los bots y crear un resumen criptográfico (hash) de las mismas, pudimos crear una huella digital que identifica de forma única familias de bots similares.
 
hajime-dropper-command-sequence.png

Figura: Secuencia de comandos de instalación (dropper) del bot Hajime

Una vez que los bots se sentían confiados a compartir con nuestro señuelo la dirección para descargar el código binario malicioso, agregamos algunas funciones que le permitían al señuelo descargar el código binario y guardarlo en memoria para poder realizar resúmenes criptográficos del contenido y crear una huella digital del código malicioso. Las nuevas huellas digitales que son desconocidas para el señuelo se analizan mediante el envío de los resúmenes md5 y sha256 a virustotal.com y, si se trata de malware nuevo o desconocido, este se informa a virustotal. Así, obtenemos un buen candidato para el análisis posterior. Las huellas digitales de los archivos son una excelente herramienta para ayudar a identificar los bots idénticos con código binario malicioso que evoluciona con el tiempo, tal como el bot Hajime. La huella digital de la secuencia de comandos coincide con la de Hajime pero las huellas digitales de los archivos binarios cambian con el tiempo, lo que nos permite rastrear nuevas versiones transmitidas por el mismo bot.
 
Por otra parte, almacenamos información sobre la parte remota (que incluye información de geolocalización geoip, la secuencia de comandos original y la huella digital de la secuencia de comandos, así como la huella digital del código binario malicioso) en una base de datos MongoDB para su análisis posterior. Al consultar los datos almacenados en la base de datos, podemos hacer un seguimiento de la historia y evolución de los bots nuevos y existentes que intentaban atacar nuestros señuelos. Con el tiempo, incorporamos nuevos protocolos y exploits, tales como el exploit NewNTPServer y el servidor TR-064/069, los exploits de RCE go-ahead en HTTP y el protocolo SSH normal. Buscamos replicar los dispositivos reales tan aproximadamente como fuera posible y engañar a los bots para que creyeran que tenían una nueva víctima real.
 
tr-064-newntpserver-rce-exploit.png
Figura: Exploit de RCE NewNTPServer en el estándar TR-064
 
La última incorporación a nuestra infraestructura de señuelos de IoT es un stack ELK (Elasticsearch, Logstash, Kibana) que cuenta con paneles e información en tiempo real sobre la actividad de las botnets de IoT en nuestros señuelos.

kibana-dashboard.png
Figura: Panel Kibana de uno de nuestros señuelos
 
Usar un señuelo con una estructura de bot conversador ofrece una herramienta de detección más segura y robusta con mucha más flexibilidad para la creación de huellas digitales y el análisis de la actividad. El señuelo no ejecuta realmente ninguno de los comandos del bot. Solo las solicitudes conocidas y preprogramadas generan respuestas (que también están preprogramadas). Debido a la elevada cantidad de intentos de infección recibidos por hora, este patrón de diseño funcionó bien para estudiar y recopilar información sobre las amenazas de IoT y las botnets. El señuelo no es comparable con un sueño telnet/SSH tradicional en el sentido de que no permite comandos y respuestas inesperados o no programados. Otros señuelos exponen funciones reales del shell y permiten más creatividad al atacante, lo cual ofrece un método superior para estudiar el comportamiento de nuevos atacantes. El señuelo de IoT no ofrece tal libertad y creatividad y, aunque es capaz de descubrir intentos de ataque de nuevos tipos de bots y droppers, requiere trabajo para programar y simular nuevos comandos, protocolos y exploits. De todas formas, para los fines de nuestro estudio, el señuelo ofrece las herramientas y las estadísticas que necesitamos para entender y apreciar el panorama de amenazas que presentan las botnets de IoT.
 

Radware
© 2008-2017 Radware, Ltd. All rights reserved.