Група изследователи от Тел Авивския университет и Междисциплинарния център в Херцлия (Израел) нов метод на атака (), позволяваща използването на всякакви DNS резолвери като усилватели на трафика, осигуряващи усилване до 1621 пъти по число пакети (за всеки изпратен към резолвера запитване, може да се постигне изпращане на 1621 запитвания към сървъра на жертвата) и до 163 пъти по трафик.
Проблемът е свързан с особеностите на работата на протокола и засяга всички DNS сървъри, които поддържат рекурсивна обработка на запитвания, включително (CVE-2020-8616), (CVE-2020-12667), (CVE-2020-10995), и (CVE-2020-12662), а също така публичните DNS услуги на Google, Cloudflare, Amazon, Quad9, ICANN и други компании. Коригирането на проблема беше координирано с разработчиците на DNS сървъри, които едновременно пуснаха обновления с отстраняване на уязвимостта в своите продукти. Защита срещу атаката е реализирана в изданията
, , , .
Атаката се основава на употребата от нападателя на запитвания, отнасящи се до голям брой преди това не срещани фиктивни NS записи, на които се делегира определянето на името, но без указване в отговора на glue записи с информация за IP адресите на NS сървърите. Например, нападателят изпраща запитване за определянето на името sd1.attacker.com, контролирайки DNS сървъра, отговарящ за домейна attacker.com. В отговор на запитването на резолвера към DNS сървъра на нападателя, се дава отговор, делегиращ определянето на адреса sd1.attacker.com на DNS сървъра на жертвата чрез указване в отговора на NS записи без детайлизиране на IP адресите на NS сървърите. Тъй като споменатият NS сървър не е срещан преди и неговият IP адрес не е указан, резолверът се опитва да определи IP адреса на NS сървъра, отправяйки запитване към DNS сървъра на жертвата, обслужваща целевия домейн (victim.com).
Проблемата е, че атакуващият може да издаде в отговора огромен списък от уникални NS-сервери с не съществуващи фиктивни имена на поддомейни на жертвата (fake-1.victim.com, fake-2.victim.com,… fake-1000.victim.com). Резолверът ще се опита да изпрати заявка до DNS-сервера на жертвата, но ще получи отговор, че домейнът не е намерен, след което ще се опита да определи следващия NS-сървър в списъка, и така нататък, докато не изчерпи всички изброени NS-записи от атакуващия. Следователно, за едно запитване от атакуващия, резолверът ще изпрати множество запитвания за определяне на NS-хостовете. Тъй като имената на NS-сървърите се генерират случайно и сочат към несъществуващи поддомейни, те не се извлекат от кеша и всяко запитване от атакуващия води до лавина от запитвания към DNS-сервера, обслужващ домейна на жертвата.
Изследователите проучиха степента на уязвимост на публичните DNS-резолвери и установиха, че при изпращане на запитвания до резолвера на CloudFlare (1.1.1.1) може да се постигне умножаване на броя на пакетите (PAF, Packet Amplification Factor) с 48 пъти, Google (8.8.8.8) — 30 пъти, FreeDNS (37.235.1.174) — 50 пъти, OpenDNS (208.67.222.222) — 32 пъти. По-забележителни показатели се наблюдават за
Level3 (209.244.0.3) — 273 пъти, Quad9 (9.9.9.9) — 415 пъти
SafeDNS (195.46.39.39) — 274 пъти, Verisign (64.6.64.6) — 202 пъти,
Ultra (156.154.71.1) — 405 пъти, Comodo Secure (8.26.56.26) — 435 пъти, DNS.Watch (84.200.69.80) — 486 пъти, и Norton ConnectSafe (199.85.126.10) — 569 пъти. За сървъри, базирани на BIND 9.12.3, чрез паралелизиране на запитванията, нивото на усилване може да достигне 1000. В Knot Resolver 5.1.0, нивото на усилване е около няколко десетки пъти (24-48), тъй като определянето на NS-имената се извършва последователно и се натъква на вътрешно ограничение на броя стъпки за разрешаване на имена, позволени за едно запитване.
Определят се две основни стратегии за защита. За системи с DNSSEC използваме за предотвратяване на заобикаляне на DNS кеша, тъй като запитванията се изпращат с произволни имена. Същността на метода е в генерирането на негативни отговори без да се обръщат към авторитетни DNS-сървъри, прилагане на проверка по диапазони чрез DNSSEC. По-простият начин е ограничаване на броя имена, които могат да се определят при обработката на една делегирана заявка, но такъв метод може да доведе до проблеми с някои съществуващи конфигурации, тъй като лимитите не са определени в протокола.
Източник: opennet.ru
