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.
