Атака NXNSAttack, затрагивающая все DNS-резолверы
21 мая 2020 года
Группа исследователей из Тель-Авивского университета и Междисциплинарного центра в Герцлии (Израиль) разработала новый метод атаки NXNSAttack ( PDF), позволяющий использовать любые DNS-резолверы в качестве усилителей трафика, обеспечивающих степень усиления до 1621 раз по числу пакетов (на каждый отправленный к резолверу запрос, можно добиться отправки на сервер жертвы 1621 запрос) и до 163 раз по трафику.
Проблема связана с особенностями работы протокола и затрагивает все DNS-серверы, поддерживающие рекурсивную обработку запросов, в том числе BIND (CVE-2020-8616), Knot (CVE-2020-12667), PowerDNS (CVE-2020-10995), Windows DNS Server и Unbound (CVE-2020-12662), а также публичные DNS-сервисы Google, Cloudflare, Amazon, Quad9, ICANN и других компаний. Исправление проблемы было скоординировано с разработчиками DNS-серверов, которые одновременно выпустили обновления с устранением уязвимости в своих продуктах. Защита от атаки реализована в выпусках Unbound 1.10.1, Knot Resolver 5.1.1, PowerDNS Recursor 4.3.1, 4.2.2, 4.1.16, BIND 9.11.19, 9.14.12, 9.16.3.
Атака основывается на использовании атакующим запросов, ссылающихся на большое число ранее не встречавшихся фиктивных 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 предложено использовать RFC-8198 для предотвращения обхода кэша DNS, так как запросы отправляются со случайными именами. Суть метода в генерации негативных ответов без обращения к авторитетным DNS-серверам, применяя проверку по диапазонам через DNSSEC. Более простым способом является ограничения числа имён, которые можно определить при обработке одного делегированного запроса, но такой метод может привести к проблемам с некоторыми существующими конфигурациями, так как лимиты не определены в протоколе.
Источники[править]
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии[править]
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.
