BotHunter es un sistema de detección de malware a través del tráfico de red creado por Computer Science Laboratory, SRI International. Si uno accede a la página web oficial del proyecto observará la siguiente descripción:
Cita:
It tracks the two-way communication flows between your computer(s) and the Internet, comparing your network traffic against an abstract model of malware communication patterns.(1) Its goal is to catch bots and other coordination-centric malware infesting your network, and it is exceptionally effective.
Hemos destacado dos aspectos de la descripción: por un lado que se compara el tráfico contra un modelo abstracto de patrones de comunicación de malware y por otro la afirmación de que es excepcionalmente efectivo. Uno con esta descripción tan sugerente no le queda otra que ver en qué consiste este modelo y qué lo puede hacer tan efectivo. Durante esta entrada vamos a revisar el paper de SRI, donde se comenta la arquitectura, la lógica y diversos componentes de gran interés.
Empecemos. BotHunter utiliza un enfoque que recibe el nombre de “Infection Dialog Correlation Strategy”. Este enfoque modela las infecciones de los bots como un conjunto de flujos de comunicación que son intercambiados entre un elemento interno de nuestra red y uno o más elementos externos. Considera que en el ciclo de vida de una infección se pueden dar las siguientes fases: escaneo del objetivo, infección mediante un exploit, descarga de un binario más ejecución, establecimiento de comunicación con un servidor Command-and-Control (C&C) y un escaneo hacia fuera en busca de nuevas víctimas (fase de propagación le podríamos llamar). Para que BotHunter lo considere como una actividad de un bot no tienen porque darse todas estas fases en su totalidad, ni en un determinado orden; como veremos durante esta entrada.
El modelo del que hablamos muestra una infección como un conjunto de participantes y una secuencia ordenada de intercambios, lo que la gente de SRI expresa de la siguiente manera:
Infección I = < A,V,C,V',E,D >
donde
A = Atacante.
V = Víctima.
E = Egg Download Location.
C = Comunicación con el C&C server.
V’ = La siguiente víctima.
D = representa un diálogo de infección compuesto por flujos bidireccionales que cruzan el límite. Este diálogo esta compuesto por cinco transacciones:
Estos elementos se modelan en el siguiente diagrama:
- E1: Escaneo desde un elemento en el exterior hacia uno en el interior.
- E2: Exploit desde un elemento situado en el exterior hacia uno en el interior.
- E3: Descarga de un binario del exterior por parte de un elemento situado en el interior.
- E4: Comunicación por parte de un elemento interno con el servidor de Command-and-Control (C&C).
- E5: Escaneo desde un elemento interior en busca de futuras víctimas.
http://www.securityartwork.es/wp-content/uploads/2010/11/1.jpg
Las transiciones contempladas serían:
1. Un atacante realiza un escaneo de la víctima (E1)
2. El atacante infecta a la víctima (E2)
3. La víctima descarga un binario (E3)
En este punto puede suceder:
Tipo I:
4. La víctima se comunica con el C&C (E4)
5. La víctima escanea para encontrar nuevas víctimas (E5)
o Tipo II:
6. La víctima escanea para encontrar nuevas víctimas (E5)
Vistos de manera rápida los elementos del modelo abstracto que comentábamos y las transiciones, vamos a ver la lógica que utilizará la herramienta para cazar a los bots:
Debe quedar claro que tienen que darse una de las dos condiciones para que salte una alerta de que hay un bot. Analizando las condiciones, vemos que la número uno espera una alerta de infección y una alerta de descarga de un binario o escaneo a otros equipos. La segunda condición busca al menos dos alertas del tipo de descarga de binario o de escaneo a terceros.Cita:
# Descripción muy simple de la lógica de BotHunter, quedan muchos aspectos por reflejar
# solo pretende ilustrar grosso modo qué mensajes tendrá en cuenta.
if ((E2 and (E3 or E5)) or ( count (E3 or E5) > 1)) then
bot_cazado();
fi
Es de suponer que llegados a estas alturas os hayáis preguntado, ¿Y qué tiene por debajo BotHunter? ¿Cómo es su arquitectura? Pues BotHunter se basa en el sistema de detección de intrusos opensource Snort, con reglas centradas en malware; además, incorpora los plugins SLADE (Statistical PayLoad Anomaly Detection Engine o Analizador de flujos de tráfico —definición muy simple, que me perdone la gente de SRI :P—) y SCADE (Statistical sCan Anomaly Detection Engine o Analizador de escaneo de puertos tanto de entrada como de salida). De una manera gráfica la arquitectura y los flujos de alertas serían:
http://www.securityartwork.es/wp-content/uploads/2010/11/2.jpg
El diagrama ilustra claramente que existen tres fuentes principales y cada una de ellas emite unos tipos de mensaje: (i) el plugin SLADE proporciona mensajes de tipo E2, (ii) el plugin SCADE proporciona mensajes de tipo E1 y E5 y (iii) las reglas de malware seleccionadas proporcionan mensajes de tipo E2, E3 y E4. Estos datos después son relacionados por el correlador que utiliza una matriz, donde cada entrada se corresponde con un elemento interno que ha generado actividad. De este elemento interno los tres sensores van rellenando E1, E2, E3, E4 y E5 durante una ventana de tiempo:
http://www.securityartwork.es/wp-content/uploads/2010/11/3.jpg
Cuando sobre alguna de las entradas se cumplan alguna de la condiciones vistas con anterioridad se caza a un bot.
Como bien indican en la introducción de su paper la gente de SRI intenta evitar la cantidad de ruido que por regla general suele producir un IDS, además de conseguir modelar la infección que acaba convirtiendo a un sistema en un bot. Por lo que hemos podido ver en su definición formal a través del paper, BotHunter promete y mucho. Se anima al lector a leer el paper, dado que les resolverá muchas de las dudas que no se aclaran en esta introductoria entrada, y a los que hayan trabajado con la herramienta se les anima a dejar comentarios que abran un poco de luz sobre su efectividad, rendimiento y otras muchas incógnitas. Es necesario también matizar que la herramienta ha evolucionado desde la escritura del documento inicial, por lo que en algunos aspectos podrían haber surgido ampliaciones, como el número de estados del modelo etc. pero manteniendo en esencia el trabajo inicial que mostramos en esta entrada introductoria.
Por José Miguel Holguín en http://www.securityartwork.es/2010/11/05/bothunter
