domingo, 19 de enero de 2014

TA14-013A: NTP Amplification Attacks Using CVE-2013-5211

Hace unas dos semanas recibí una nueva alerta del US-CERT sobre el uso del protocolo NTP para realizar DDoS, mediante ataques de amplificación. Para los que no saben/recuerdan lo que es un ataque de amplificación lo pueden refrescar  leyendo http://viviendolared.blogspot.com.ar/2013/07/ta13-088a-dns-amplification-attacks.html , si bien esa entrada trata de un ataque de amplificación utilizando DNS, conceptualmente es lo mismo.

Me llamó poderosamente la atención que se pudiese utilizar NTP para realizar este tipo de ataques, básicamente por no conocer en profundidad las posibilidades del protocolo. El problema esencialmente es que NTP junto con DNS, FTP, HTTP, etc... es de esos protocolos que fueron diseñados en una época en que internet era buena/saludable/ingenua y jamás pensaron que muchas funcionalidades podrían luego ser utilizadas para hacer el mal, JA!

Resulta ser que hay una funcionalidad del protocolo, llamada monlist que nos permite ver las estadísticas de comunicación del demonio NTP con todos los clientes. Por ejemplo, consultando a un pequeño servidor que mantiene sincronizado unos pocos nodos en una LAN podemos ver:

ntpdc -c monlist

Una simple consulta ntpdc -c monlist servidor.ntp.com nos generó el siguiente tráfico:


root@acelga:~# tcpdump -n port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:50:34.121664 IP 172.19.136.12.45612 > 172.19.136.1.123: NTPv2, Reserved, length 192
16:50:34.122140 IP 172.19.136.1.123 > 172.19.136.12.45612: NTPv2, Reserved, length 296
^C
2 packets captured
2 packets received by filter
0 packets dropped


pasado en limpio, con 192 bytes logramos una respuesta de 296 bytes, lo cual realmente no parece ser gran cosa. Pero qué pasa si en lugar de consultar a un pequeño servidor NTP de una LAN consulto a uno un poco mas grande?


root@acelga:~# tcpdump -n port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:00:41.259404 IP 172.19.136.12.37161 > 200.XXX.XXX.XXX.123: NTPv2, Reserved, length 192
17:00:41.259767 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.259780 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.259785 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.259788 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.259792 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260016 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260027 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260031 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260034 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260038 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260042 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260046 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260266 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260275 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260280 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260283 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260287 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260291 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260516 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260526 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260530 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260534 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260538 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260541 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260766 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260776 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260780 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260784 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260788 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 224
^C
30 packets captured
30 packets received by filter
0 packets dropped by kernel
root@acelga:~#  

Y ahora qué pasó? JA! a partir de una consulta de 192 bytes obtuvimos una respuesta de 12544 bytes (28*440+224), es decir pasamos de un factor de casi 2 a un factor de 65, suena mas interesante, no? Y eso que el servidor consultado solo mostró 170 clientes conectados... seguramente se pueden encontrar en internet servidores con mas clientes aún.

Según la documentación de ntpdc, el comando monlist solo nos devolvería hasta 600 entradas, por lo tanto podríamos asumir un máximo de 12544 bytes*3.5=43904 bytes con una consulta de solo 192 bytes, esto es un factor de 227 aproximadamente, interesting!!!

Haciendo un poco de números si tenemos 100 PCs zombies haciendo spoofing y realizando 1 consulta por segundo son 43904*100=4390400 bytes, aprox 4Mbytes/S de tráfico que retornará a la IP spoofeada, esto sin considerar la posibilidad de hacer mas consultas por segundo, tener mas PCs zombies o mas servidores NTP...

¿Cómo controlo mi servidor NTP para que no sea utilizado para esto?

Por defecto la mayoría de las versiones nuevas de NTP no son vulnerables, porque traen desactivada la opción de consultas de estadísticas, las opciones para evitar dolores de cabeza son:

-Desactivar las consultas de estadísticas
-Controlar las direcciones IP que tienen permitidas dichas consultas

Ambas soluciones se logran editando el archivo /etc/ntp.conf (o el equivalente en tu distribución), y asegurandose de que la opción noquey se encuentra puesta como en las siguientes lineas:

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery 

No hay comentarios:

Publicar un comentario