Група изследователи от Технион и Междисциплинарния център в Херцлия (Израел) нов метод на атака (), който позволява да се използват всякакви DNS резолвери като усилватели на трафика, осигурявайки степен на усилване до 1621 пъти по брой пакети (за всеки изпратен до резolverа запитване, може да се достигне до изпращане на 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. В отговор на запитването на резolverа към DNS сървъра на атакуващия, се дава отговор, делегиращ определянето на адреса sd1.attacker.com на DNS сървъра на жертвата чрез указване в отговора на NS записи без детайли за IP адресите на NS сървърите. Тъй като споменатият NS сървър не е бил виждан преди и неговият IP адрес не е указан, резolverът се опитва да определи 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
