Un equipo de investigadores da Universidade de California, Riverside, publicou unha nova variante do ataque SAD DNS (CVE-2021-20322) que funciona a pesar das proteccións engadidas o ano pasado para bloquear a vulnerabilidade CVE-2020-25705. O novo método é xeralmente similar á vulnerabilidade do ano pasado e só difire no uso dun tipo diferente de paquetes ICMP para comprobar os portos UDP activos. O ataque proposto permite a substitución de datos ficticios na caché do servidor DNS, que se poden usar para substituír o enderezo IP dun dominio arbitrario na caché e redirixir as solicitudes ao dominio ao servidor do atacante.
O método proposto funciona só na pila de rede de Linux debido á súa conexión coas peculiaridades do mecanismo de procesamento de paquetes ICMP en Linux, que actúa como fonte de fuga de datos que simplifica a determinación do número de porto UDP utilizado polo servidor para enviar un solicitude externa. Os cambios que bloquean a fuga de información adoptáronse no núcleo de Linux a finais de agosto (a corrección incluíuse no núcleo 5.15 e nas actualizacións de setembro para as ramas LTS do núcleo). A corrección redúcese a usar o algoritmo de hash SipHash en cachés de rede en lugar de Jenkins Hash. O estado de arranxar a vulnerabilidade nas distribucións pódese avaliar nestas páxinas: Debian, RHEL, Fedora, SUSE, Ubuntu.
Segundo os investigadores que identificaron o problema, preto do 38% dos resolutores abertos na rede son vulnerables, incluíndo servizos DNS populares como OpenDNS e Quad9 (9.9.9.9). En canto ao software de servidor, pódese levar a cabo un ataque utilizando paquetes como BIND, Unbound e dnsmasq nun servidor Linux. O problema non aparece nos servidores DNS que se executan en sistemas Windows e BSD. Para levar a cabo un ataque con éxito, é necesario utilizar IP spoofing, é dicir. é necesario que o ISP do atacante non bloquee os paquetes cun enderezo IP de orixe falso.
Como recordatorio, o ataque DNS SAD evita as proteccións engadidas aos servidores DNS para bloquear o método clásico de intoxicación da caché DNS proposto en 2008 por Dan Kaminsky. O método de Kaminsky manipula o pequeno tamaño do campo de ID de consulta DNS, que é só de 16 bits. Para seleccionar o identificador de transacción DNS correcto necesario para a suplantación de nomes de host, abonda con enviar aproximadamente 7000 solicitudes e simular unhas 140 mil respostas ficticias. O ataque redúcese a enviar un gran número de paquetes cunha conexión IP ficticia e con diferentes identificadores de transaccións DNS ao resolutor DNS. Para evitar o almacenamento na caché da primeira resposta, cada resposta ficticia contén un nome de dominio lixeiramente modificado (1.example.com, 2.example.com, 3.example.com, etc.).
Para protexerse contra este tipo de ataques, os fabricantes de servidores DNS implementaron unha distribución aleatoria do número de portos de rede de orixe desde os que se envían solicitudes de resolución, o que compensaba o tamaño insuficientemente grande do identificador. Despois de implementar a protección para enviar unha resposta ficticia, ademais de seleccionar un identificador de 16 bits, fíxose necesario seleccionar un dos 64 mil portos, o que aumentou o número de opcións de selección a 2^32.
O método SAD DNS permítelle simplificar radicalmente a determinación do número de porto de rede e reducir o ataque ao método Kaminsky clásico. Un atacante pode detectar o acceso a portos UDP activos e non utilizados aproveitando a información filtrada sobre a actividade dos portos de rede ao procesar paquetes de resposta ICMP. O método permítenos reducir o número de opcións de busca en 4 ordes de magnitude: 2^16+2^16 en lugar de 2^32 (131_072 en lugar de 4_294_967_296). A fuga de información que lle permite determinar rapidamente os portos UDP activos prodúcese por unha falla no código para procesar paquetes ICMP con solicitudes de fragmentación (marcador de fragmentación necesaria ICMP) ou redirección (marcador de redirección ICMP). O envío deste tipo de paquetes cambia o estado da caché na pila de rede, o que permite determinar, en función da resposta do servidor, que porto UDP está activo e cal non.
Escenario de ataque: cando un resolvedor de DNS intenta resolver un nome de dominio, envía unha consulta UDP ao servidor DNS que serve o dominio. Mentres o resolvedor agarda unha resposta, un atacante pode determinar rapidamente o número de porto de orixe que se utilizou para enviar a solicitude e enviarlle unha resposta falsa, suplantando o servidor DNS que serve o dominio mediante a suplantación de enderezos IP. O resolvedor de DNS almacenará na caché os datos enviados na resposta falsa e durante algún tempo devolverá o enderezo IP substituído polo atacante para todas as demais solicitudes de DNS para o nome de dominio.
Fonte: opennet.ru