Un grupo de investigadores da Universidade de Tel Aviv e do Centro Interdisciplinar de Herzliya (Israel) novo método de ataque (), o que lle permite utilizar calquera resolutor DNS como amplificador de tráfico, proporcionando unha taxa de amplificación de ata 1621 veces en canto ao número de paquetes (por cada solicitude enviada ao resolutor, podes conseguir 1621 solicitudes enviadas ao servidor da vítima) e ata 163 veces en canto ao tráfico.
O problema está relacionado coas peculiaridades do protocolo e afecta a todos os servidores DNS que admiten o procesamento de consultas recursivas, incluíndo (CVE-2020-8616) (CVE-2020-12667) (CVE-2020-10995) и (CVE-2020-12662), así como servizos DNS públicos de Google, Cloudflare, Amazon, Quad9, ICANN e outras empresas. A corrección coordinouse cos desenvolvedores do servidor DNS, que lanzaron ao mesmo tempo actualizacións para corrixir a vulnerabilidade dos seus produtos. Protección contra ataques implementada nas versións
, , , .
O ataque baséase en que o atacante utiliza solicitudes que se refiren a un gran número de rexistros NS ficticios non vistos anteriormente, aos que se delega a determinación do nome, pero sen especificar rexistros adhesivos con información sobre os enderezos IP dos servidores NS na resposta. Por exemplo, un atacante envía unha consulta para resolver o nome sd1.attacker.com controlando o servidor DNS responsable do dominio attacker.com. En resposta á solicitude do resolutor ao servidor DNS do atacante, emítese unha resposta que delega a determinación do enderezo sd1.attacker.com no servidor DNS da vítima indicando rexistros NS na resposta sen detallar os servidores IP NS. Dado que o servidor NS mencionado non se atopou antes e non se especifica o seu enderezo IP, o resolvedor tenta determinar o enderezo IP do servidor NS enviando unha consulta ao servidor DNS da vítima que serve o dominio de destino (victim.com).
O problema é que o atacante pode responder cunha lista enorme de servidores NS que non se repiten con nomes de subdominio de vítimas ficticios inexistentes (fake-1.victim.com, fake-2.victim.com,... fake-1000. victim.com). O resolvedor tentará enviar unha solicitude ao servidor DNS da vítima, pero recibirá unha resposta de que non se atopou o dominio, despois de que intentará determinar o seguinte servidor NS da lista, e así sucesivamente ata que intente todos os Rexistros NS listados polo atacante. En consecuencia, para a solicitude dun atacante, o resolutor enviará un gran número de solicitudes para determinar os hosts NS. Dado que os nomes dos servidores NS xéranse aleatoriamente e fan referencia a subdominios inexistentes, non se recuperan da caché e cada solicitude do atacante dá lugar a unha serie de solicitudes ao servidor DNS que serve o dominio da vítima.
Os investigadores estudaron o grao de vulnerabilidade dos resolvedores de DNS públicos ante o problema e determinaron que ao enviar consultas ao resolvedor CloudFlare (1.1.1.1), é posible aumentar en 48 veces o número de paquetes (PAF, Packet Amplification Factor), Google. (8.8.8.8) - 30 veces, FreeDNS (37.235.1.174) - 50 veces, OpenDNS (208.67.222.222) - 32 veces. Obsérvanse indicadores máis notables para
Nivel 3 (209.244.0.3) - 273 veces, Quad9 (9.9.9.9) - 415 veces
SafeDNS (195.46.39.39) - 274 veces, Verisign (64.6.64.6) - 202 veces,
Ultra (156.154.71.1) - 405 veces, Comodo Secure (8.26.56.26) - 435 veces, DNS.Watch (84.200.69.80) - 486 veces e Norton ConnectSafe (199.85.126.10) - 569 veces. Para servidores baseados en BIND 9.12.3, debido á paralelización de solicitudes, o nivel de ganancia pode alcanzar ata 1000. En Knot Resolver 5.1.0, o nivel de ganancia é aproximadamente varias decenas de veces (24-48), xa que a determinación de Os nomes NS realízanse secuencialmente e dependen do límite interno do número de pasos de resolución de nomes permitidos para unha solicitude.
Hai dúas estratexias de defensa principais. Para sistemas con DNSSEC uso para evitar o desvío da caché DNS porque as solicitudes se envían con nomes aleatorios. A esencia do método é xerar respostas negativas sen contactar con servidores DNS autorizados, utilizando a comprobación de rango a través de DNSSEC. Un enfoque máis sinxelo é limitar o número de nomes que se poden definir ao procesar unha única solicitude delegada, pero este método pode causar problemas con algunhas configuracións existentes porque os límites non están definidos no protocolo.
Fonte: opennet.ru