jueves, 20 de febrero de 2014

Simulacro de: Ataque Distribuido de Denegación de Servicio (DDoS) mediante reflección NTP, desde y contra una red científica

Compartir este artículo:
INTRODUCCION

Uno de los puntos débiles en la securización y monitorización de redes es  la aparición de alguna vulnerabilidad en nuestra infraestructura vinculada al protocolo UDP, ó un servicio que se sirva de él para la capa de transporte, pues es complicada la detección. Esto es debido a: 

1. Como bien comentó Ramón Pinuaga de s21sec [1],  el proceso de funcionamiento clásico de un scanner de red se fundamenta en: 
  • Explorar los puertos abiertos.
  • Determinar el tipo de servicio y la versión del software utilizado (normalmente a través del banner).
  • Determinar si el servicio o la versión del software está afectado por alguna vulnerabilidad.
  • Presentar un informe de lo encontrado.
Y frente a este modo de funcionamiento encontramos la oposición por la ambigüedad con la que responde UDP (“ICMP_PORT_UNREACHABLE”), para los estados filtrado y cerrado, y la dificultad que implica para la identificación que solo responda a peticiones especificas del protocolo de aplicación específico que escucha en él.

2. Por otro lado el análisis del tráfico UDP, del rango de direcciones públicas en una red científica, como la que vuelve a ocupar mi jornada laboral, omitiendo la restricción que he comentado en otras ocasiones de lo comprometido de analizar ó no el tráfico de los usuarios, es que alcanza un volumen ingente.

Coincido con Ramón Pinuaga en que algunos, entre ellos administradores en mi opinión, piensen: "bueno, los servicios UDP son marginales". En mi experiencia UDP es la chica fea del baile frente a TCP, y es posible que no esté en el recuerdo de los administradores de redes al establecer las reglas de configuración del cortafuegos en los routers, o de los administradores de sistemas al securizar las configuraciones de los servicios que lo utilizan para transporte.

Pero si algo me enseñan los atacantes en el día a día, es que siempre se nos pasa algo hermosamente simple  y elemental de explotar por alto. Porque la belleza en la seguridad informática, desde mi punto de vista, no está siempre en explotar una enrevesada vulnerabilidad a través de un puerto, haciendo uso de un desbordamiento de pila o de buffer en el servicio que se comunica a través de él, originado por estar implementado con una librería que usa un vector estático en la línea 2 millones de su código, y oportunamente lanzado por el “super-usuario” durante el arranque. Cuando un usuario con conocimientos básicos se descarga un script kiddie, lo lanza con una simple instrucción, a ser posible con los mínimos parámetros, y “arde Roma”, esquivando las configuraciones de cortafuegos y securización del sistema, ahí es cuando me quito el sombrero y solo queda decir “touché”.
Por eso y motivado también por el artículo [5] de Pablo González @pablogonzalezpe, que dio la casualidad que se publicó mientras redactaba estas líneas, he decidido simular y comentar uno de los ataques más interesantes que ocupan algunas de las incidencias de seguridad que he llevado actualmente. Esto es la realización de denegación de servicios a terceros empleando equipos vulnerables de la red R.I.C.A a través del servicio NTP, y que por ir sobre UDP, ha pasado bastante desapercibida su detección.

¿QUE ES NTP?

Es un servicio y sirve información temporal, ¿fácil verdad?

¿Y dónde lo podemos localizar y con qué fin último?, pues por ejemplo:

1. En un sistema multiservidor, para no configurar a mano la hora del sistema de cientos de equipos, lo cual sería una locura. Además es interesante que dichas horas, no solo sean aproximadas a la real, sino que estén sincronizadas de cara a la coherencia en los logs generados a partir de distintas fuentes. O dicho de otra manera, en una “granja de servidores” para dar servicio web, o un cluster para dar servicio de supercomputación al personal investigador.

2 En servidores dedicados a virtualización, para sincronizar el anfitrión y los huéspedes. O dicho de otra manera, en servidores corriendo VMware esxi/esx para dar servicio de cloud o recursos virtualizados de otra naturaleza.

3 En routers empresariales, con la finalidad de obtener coherencia en la monitorización de tráfico de red. O dicho de otra manera, las gateway que unen entre sí y dan salida al exterior  a las distintas subredes.

4 En las transferencias de bases de datos de aplicaciones multired. O dicho de otra manera en una aplicación de gestión de recursos de personal que utilice el personal administrativo.

Como podemos ver, si nos ponemos a pensar, este servicio está muy presente en grandes redes para tareas monitorización, coordinación y configuración, pero curiosamente pasa desapercibido junto con el resto del tráfico que depende de UDP como protocolo de transporte.

FUNDAMENTO DE LA DENEGACION DE SERVICIO DISTRIBUIDA MEDIANTE REFLECCIÓN

Vamos con la “chicha”, y veremos lo tremendamente sencillo y peligroso del asunto. Hay tres términos claves en la referencia de estos ataques. Denegación de servicio, Reflección y Distribuida

Denegación de servicio: El fundamento es simple, un productor  de respuestas es colapsado por uno o varios consumidores (productores de preguntas). Si la relación mínima productor:consumidor para llegar al colapso es de 1:1, ya estamos ante una vulnerabilidad realmente peligrosa. 

En este caso la trama/pregunta de origen, da lugar a miles de tramas/respuestas, sin control en número de  peticiones de servicio e identidad de quien la solicita dichas respuestas.

El “principio activo” en concreto es el comando monlist, presente la versión 4.2.7 y anteriores de NTP. Este nos devuelve la lista de los 600 últimos hosts que conectaron con y el servicio.

 
Fig1: Salida del comando monlist al servicio NTP.

Si hacemos una prueba con wireshark podemos observar la relación entre el trafico UDP enviado y recibido.

 
Fig2: La trama 2 (pregunta) tiene un tamaño de 234 bytes, frente a 43958 bytes de la respuesta, de un total de 44192 bytes de tráfico generado por el dialogo UDP. Esto es una relación de 1 frente a 187.
 
Llegado a este punto, el ataque empieza a ser interesante, pero no deja ser una simple denegación de servicio, le falta cierta “gracia”. Por ejemplo:
  • La víctima puede “ver” directamente al atacante y se registran comunicaciones que vinculan atacante y víctima.
  • Estamos limitados a que la víctima este sirviendo NTP.
  • Sino necesitamos la colaboración de varios atacantes, es por lo que comentamos del tamaño de la respuesta. Esto no suele ser lo habitual.
Reflección y Distribuida: Varias respuestas de fuentes distintas, inciden en un solo punto, que para el caso no es quien realizo las preguntas (atacante), si no por quien se hizo pasar el atacante (víctima) falsificando su identidad, hizo “spoofing”. Es decir se busca proyectar la denegación de servicio utilizando de pasarela y amplificadores de tráfico a los servidores NTP, en equipos  no relacionados directamente con el servicio. Con el siguiente dibujo queda más claro, y ya de paso ejemplarizamos los escenarios del experimento que vendrá a continuación.

 Fig3: Escenarios 1,2 y3 planteados para el ejercicio de simulación.
 
Todo lo anterior unido es una bomba de relojería y si no está familiarizado con la seguridad en equipos y redes, en el análisis de riesgos al final lo comentaremos.

ACTORES DEL SIMULACRO

Atacante


Servidor NTP implicado en la denegación de servicio (150.214.x.y visto desde fuera).

~# nmap -sU -sS –A 150.214.n.m



MATERIAL BASICO

Para llevar a cabo la simulación del ataque vamos a necesitar de un

a lista de equipos susceptibles a ser empleados para el ataque de reflección NTP y una herramienta que nos facilite la explotación.

A. Las máquinas que utilizaremos para la reflección las encontraremos mediante nmap. Nmap tiene vida más hallá del escaneo de puertos y permite utilizar scripts desarrollados para el NSE (Nmap Scripting Engine), en este caso nos permite consultar la existencia del comando monlist en NTP y que nos devuelve.

~# nmap -sU -pU:123 -Pn -n --script=ntp-monlist 150.214.0.0/16
 
 
B. El método anterior requiere de tiempo y recursos, es elegante pero aún se podría hacer más a nivel de usuario básico. Si no buscamos involucrar equipos de una procedencia concreta, servicios de registro de incidentes en seguridad mal planteados comparten y nos dan todo el material de manera extremadamente simple. Por ejemplo el de skial.com[2] con hosting en CloudFare[3].
 

 Fig3: La información sobre ataques interceptados debe ser manejada con cuidado, pues expone equipos explotables. 
 

HERRAMIENTA DE DENEGACIÓN DE SERVICIO
 
Ntpdos.py [4] es un script en python, obra de vpnboy, que nos permite lanzar el ataque de manera simple y muy efectiva. No voy a entrar a analizarlo en profundidad, pero si hay que mencionar que permite lanzar hebras, una por servidor NTP vulnerable, de una lista en un fichero de texto, y que envía en bucle una trama a medida, ensamblada mediante la librería scapy, para el caso, UDP con origen la ip “spoofeada” y de payload el comando monlist.



Fig4: La primera trama (pregunta), de “ntpdc –c monlist <ip>”, capturada con wireshark permite obtener el payload que utiliza ntpdos.py.

data = "\x17\x00\x03\x2a" + "\x00" * 4
#BUILD IT
packet = IP(dst=ntpserver,src=target)/UDP(sport=48947,dport=123)/Raw(load=data)
#SEND IT
send(packet,loop=1) 
 
SIMULACRO
 
Manos a la obra, vamos a entrar en acción y replicar y/o comentar cada uno de los escenarios.
 
Escenario1
 
El primer ataque simula un ataque ideal, desde fuera de la red R.I.C.A, a través de host internos y hacia una víctima interna.
 
 
Para este escenario no se observaba actividad alguna en el tráfico de la víctima. Probando con “hping3 --udp 150.214.x.y --spoof 150.214.n.m”, confirmamos del lado de la víctima, que los routers del camino hacen su trabajo y no llega tráfico “spoofeado” a ella. Mala suerte.
 
Escenario2
 
El segundo escenario es desde un atacante interno, usando para la reflección hosts internos y contra una víctima interna de la red R.I.C.A.
 
 
 
Este escenario es muy interesante, si bien los routers hicieron su trabajo y no permitieron directamente el ataque NTP, obsérvese el mensaje “Communication Administratively Prohibited”. Si se genera tráfico de red ICMP, aunque no para todos los atacantes implicados, avisando de que el destino es inalcanzable. Esto dependiendo del número de servidores vulnerables que empleemos para el ataque y su ancho de banda puede llegar a ralentizar la red y la víctima de manera indirecta por tráfico ICMP. Potencialmente es factible hacer una denegación de servicio.
 
Escenario3
 
El tercer escenario es un ataque desde fuera de la red R.I.C.A, valiéndose de servidores NTP internos, haciendo reflección contra un host externo a dicha red. La información es la capturada por la víctima externa y que denunció en su día el incidente al correo abuse de Red-Iris.
 
 
Se puede observar como el ataque recibido, desde el exterior, utilizando servidores NTP internos y con reflección hacia fuera alcanza a su objetivo (lo que recibe la victima son respuestas). Si echamos un vistazo con instrucción monlist al servidor NTP involucrado confirmamos que solo se realizaron consultas externas, algunas muy insistentes, como muestra el valor count de las estadísticas.
 
 
ANALISIS DE RIESGOS
El ancho de banda puesto a disposición para los usuarios de las redes científicas es bastante elevado. 
Esto implica que una vulnerabilidad presente en un equipo conectado a la red y que permita emplearlo dentro de un escenario de denegación de servicio, se convierta en un arma bastante eficaz.




Fig5: Esto es lo que uno de “la vieja guardia” me definió como “estar pinchado al cable gordo”.
 
No lo he mencionado anteriormente pero es posible dar una vuelta de tuerca más a los escenarios planteados en el simulacro. Imaginemos que  alguno de los equipos que dan servicio NTP tiene lo que comúnmete se llama una “pata” en una red privada o en la zona militarizada (MZ) de la red, y que este por descuido tuviera activado el forwarding entre patas de dicha máquina en las dos redes, esto supondría una fractura en la seguridad perimetral, y permitiría atacarla indirectamente mediante flooding NTP.

Finalmente comentar la problemática que suponen estos ataques no ya por lo peligrosos sino también porque implican a terceros, lo cual en la legislación de algunos países se contempla como delito, incluso acto de guerra si los objetivos son militares.

Me despido dando las gracias al “amo” Pablo (“La Maldad” mi jefe del trabajo) que me dio la oportunidad de seguir jugando en la “cueva” (#cosasDeLaCueva) junto con @rgonza y @lone_chanero.


Artículo cortesía de Juan Luis Martin Acal.

No hay comentarios:

Publicar un comentario en la entrada

Related Posts Plugin for WordPress, Blogger...