Група дослідників з Тель-Авівського університету та Міждисциплінарного центру у Герцлії (Ізраїль) новий метод атаки (), що дозволяє використовувати будь-які 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 разів (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