Thread by @ssantosv

¿Estás oyendo las noticias del ataque SAD DNS y te cuesta entenderlo? Tranquilo, es complejo entenderlo bien. Pero voy a intentar explicar desde mi punto de vista la parte interesante del ataque más importante a Internet desde el fallo de Kamisnky en 2008. Otro punto para 2020. ¬

Para falsear una petición DNS y devolverle al cliente una mentira, el atacante debe saber el TxID (transaction ID) y el puerto origen UDP desde el que la víctima realiza la consulta al servidor principal. Con esto bombardea al resolvedor, que creerá recibir la respuesta original.

Esto supone entropía de 32 bits (dos campos de 16). SAD DNS consiste (básicamente, porque el paper es muy complejo) en inferir el puerto UDP con un ingenioso método que se vale de los mensajes de vuelta de error ICMP. El atacante se enfrenta a una entropía de 16 bits, asumible.

¿Cómo deducir el puerto abierto del resolvedor (la víctima a la que se le va a envenenar la caché)? Lo más sencillo es escanear todos los puertos UDP y ver cuál está abierto, pero esto lleva demasiado tiempo. Para cuando se termine el puerto que querías estará obsoleto.

Además, si se machaca un servidor consultando puertos UDP él mismo limitará las respuestas ICMP de “error puerto cerrado” para no saturar. Todos los OS implementan este límite global. Y este límite para proteger, paradójicamente, es lo que aprovecha el ataque.

El límite global es de 1000 respuestas por segundo en Linux (200 en Windows). Se trata de un contador global compartido por cualquiera que le esté preguntado por puertos. Lanza como máximo 1000 respuestas a 1000 preguntas por, digamos, un puerto abierto en UDP.

Y el ataque consiste en 1) Enviar 1000 sondas UDP al resolvedor víctima con IPs de origen falseadas probando 1000 puertos. (En realidad son lotes de 50 cada 20 ms para superar otro límite de respuestas por IP, pero dejémoslo ahí por simplicidad).

2) Si los 1000 puertos están cerrados, la víctima devolverá (a las IPs falseadas) 1000 paquetes ICMP de error indicando que no está abierto el puerto. Si está abierto, no pasa nada, lo descarta la aplicación correspondiente en ese puerto.

No importa que el atacante no vea los ICMP respuesta (llegan a las IPs falseada). Lo que importa es ver cuánto del límite global de 1000 respuestas por segundo “se gasta” en esa tanda. Vamos al paso 3.

3) Antes de dejar pasar ese segundo, el atacante consulta un puerto UDP cualquiera que sepa cerrado y si el servidor le devuelve un ICMP de “puerto cerrado”… es que no se había gastado los 1000 ICPM de “error puerto cerrado” y por tanto…

... ¡en ese rango de 1000 había al menos un puerto abierto! Bingo. Como el límite de respuestas ICMP es global, una sola respuesta de puerto cerrado significa que no se gastó el límite de 1000 repuestas de “puerto cerrado” por segundo. Alguno había abierto.

Así, en tandas de 1000 consultas por segundo y comprobando si gasta o no el límite de paquetes de error puerto cerrado, el atacante puede ir deduciendo qué puertos están abiertos. En algo más de 65 segundos (para cubrir 65.536) tendrá mapeados los puertos abiertos del servidor.

Todo viene de una tormenta perfecta de errores, en implementación UDP, en la implementación del límite de 1000 respuestas... Esto al menos desde 2012. Ya había papers avisando de la posibilidad de ataques aprovechando este límite global desde 2016. Pero no tan "prácticos".

¿Soluciones? Pues Linux ya tiene preparado un parche. Pero hay mucha tela de cortar. Desde el DNSSEC que siempre se recomienda pero nunca termina de despegar, hasta desactivar las respuestas de ICMP… cosa que puede ser compleja.

El parche del Kernel hará que ahora no haya un valor fijo de 1000 respuestas por segundo, sino aleatoria de entre 500 y 2000. El atacante así no podrá hacer sus cábalas correctamente para saber si en un segundo se ha gastado ese límite y deducir puertos UDP abiertos.

Muchos servidores públicos ya están parcheados pero muchos más no. Resulta particularmente interesante en este ataque que es muy limpio para el atacante, no necesita estar en la red de la víctima. Puede hacerlo todo desde fuera y confundir a los servidores. Un desastre.

Más info por aquí: cybersecuritypulse.e-paths.com/index.html?lan…

Parece que el origen absoluto del problema es de implementación, no diseño. En este RFC tools.ietf.org/html/rfc1812#s… se describe ese límite de ratio de respuesta, y se deja abierto a un número. Elegirlo fijo y en 1000 como se hizo en el kernel en 2014, es parte del problema.

Apunte: esta consulta la hace desde su IP real, no falseada, para recibir de verdad (o no) la respuesta.

Atención: obviamente el atacante lo combina con búsquedas "inteligentes" binarias para optimizar, dividiendo los rangos de puertos "potencialmente abiertos" en cada tanda para ir más rápido y dar así con el dato concreto.