Suicide
21.05.2020, 20:36
Группа исследователей из Тель-Авивского университета и Междисциплинарного центра в Герцлии (Израиль) разработала (https://en.blog.nic.cz/2020/05/19/nxnsattack-upgrade-resolvers-to-stop-new-kind-of-random-subdomain-attack/) новый метод атаки NXNSAttack (http://www.nxnsattack.com/) (PDF (http://www.nxnsattack.com/dns-ns-paper.pdf)), позволяющий использовать любые DNS-резолверы в качестве усилителей трафика, обеспечивающих степень усиления до 1621 раз по числу пакетов (на каждый отправленный к резолверу запрос, можно добиться отправки на сервер жертвы 1621 запрос) и до 163 раз по трафику.
Проблема связана с особенностями работы протокола и затрагивает все DNS-серверы, поддерживающие рекурсивную обработку запросов, в том числе BIND (https://www.mail-archive.com/bind-announce@lists.isc.org/msg00571.html) (CVE-2020-8616), Knot (https://www.openwall.com/lists/oss-security/2020/05/19/2) (CVE-2020-12667), PowerDNS (https://www.openwall.com/lists/oss-security/2020/05/19/3) (CVE-2020-10995), Windows DNS Server (https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV200009) и Unbound (https://www.openwall.com/lists/oss-security/2020/05/19/5) (CVE-2020-12662), а также публичные DNS-сервисы Google, Cloudflare, Amazon, Quad9, ICANN и других компаний. Исправление проблемы было скоординировано с разработчиками DNS-серверов, которые одновременно выпустили обновления с устранением уязвимости в своих продуктах. Защита от атаки реализована в выпусках Unbound 1.10.1 (https://nlnetlabs.nl/news/2020/May/19/unbound-1.10.1-released/), Knot Resolver 5.1.1 (https://www.knot-resolver.cz/2020-05-19-knot-resolver-5.1.1.html), PowerDNS Recursor 4.3.1, 4.2.2, 4.1.16 (https://downloads.powerdns.com/releases), BIND 9.11.19, 9.14.12, 9.16.3 (https://www.mail-archive.com/bind-announce@lists.isc.org/msg00573.html).
Атака основывается на использовании атакующим запросов, ссылающихся на большое число ранее не встречавшихся фиктивных 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).
https://www.opennet.ru/opennews/pics_base/0_1590050644.png (http://www.nxnsattack.com/dns-ns-paper.pdf)
Проблема в том, что атакующий может выдать в ответе огромный список не повторяющихся NS-серверов с несуществующими фиктивными именами поддоменов жертвы (fake-1.victim.com, fake-2.victim.com,... fake-1000.victim.com). Резолвер попытается отправить запрос DNS-серверу жертвы, но получит ответ, что домен не найден, после чего попытается определить следующий NS-сервер в списке и так до тех пор, пока не переберёт все перечисленные атакующим NS-записи. Соответственно, на один запрос атакующего резолвером будет отправлено огромное число запросов для определения NS-хостов. Так как имена NS-серверов формируются случайно и ссылаются на несуществующие поддомены, они не извлекаются из кэша и каждый запрос атакующего приводит к шквалу запросов к DNS-серверу, обслуживающему домен жертвы.
https://www.opennet.ru/opennews/pics_base/0_1590051660.png (https://en.blog.nic.cz/2020/05/19/nxnsattack-upgrade-resolvers-to-stop-new-kind-of-random-subdomain-attack/)
Исследователи изучили степень подверженности проблеме публичных 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 предложено (https://en.blog.nic.cz/2020/05/19/nxnsattack-upgrade-resolvers-to-stop-new-kind-of-random-subdomain-attack/) использовать RFC-8198 (https://tools.ietf.org/html/rfc8198) для предотвращения обхода кэша DNS, так как запросы отправляются со случайными именами. Суть метода в генерации негативных ответов без обращения к авторитетным DNS-серверам, применяя проверку по диапазонам через DNSSEC. Более простым способом является ограничения числа имён, которые можно определить при обработке одного делегированного запроса, но такой метод может привести к проблемам с некоторыми существующими конфигурациями, так как лимиты не определены в протоколе.
21.05.2020
https://www.opennet.ru/opennews/art.shtml?num=52995
Проблема связана с особенностями работы протокола и затрагивает все DNS-серверы, поддерживающие рекурсивную обработку запросов, в том числе BIND (https://www.mail-archive.com/bind-announce@lists.isc.org/msg00571.html) (CVE-2020-8616), Knot (https://www.openwall.com/lists/oss-security/2020/05/19/2) (CVE-2020-12667), PowerDNS (https://www.openwall.com/lists/oss-security/2020/05/19/3) (CVE-2020-10995), Windows DNS Server (https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV200009) и Unbound (https://www.openwall.com/lists/oss-security/2020/05/19/5) (CVE-2020-12662), а также публичные DNS-сервисы Google, Cloudflare, Amazon, Quad9, ICANN и других компаний. Исправление проблемы было скоординировано с разработчиками DNS-серверов, которые одновременно выпустили обновления с устранением уязвимости в своих продуктах. Защита от атаки реализована в выпусках Unbound 1.10.1 (https://nlnetlabs.nl/news/2020/May/19/unbound-1.10.1-released/), Knot Resolver 5.1.1 (https://www.knot-resolver.cz/2020-05-19-knot-resolver-5.1.1.html), PowerDNS Recursor 4.3.1, 4.2.2, 4.1.16 (https://downloads.powerdns.com/releases), BIND 9.11.19, 9.14.12, 9.16.3 (https://www.mail-archive.com/bind-announce@lists.isc.org/msg00573.html).
Атака основывается на использовании атакующим запросов, ссылающихся на большое число ранее не встречавшихся фиктивных 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).
https://www.opennet.ru/opennews/pics_base/0_1590050644.png (http://www.nxnsattack.com/dns-ns-paper.pdf)
Проблема в том, что атакующий может выдать в ответе огромный список не повторяющихся NS-серверов с несуществующими фиктивными именами поддоменов жертвы (fake-1.victim.com, fake-2.victim.com,... fake-1000.victim.com). Резолвер попытается отправить запрос DNS-серверу жертвы, но получит ответ, что домен не найден, после чего попытается определить следующий NS-сервер в списке и так до тех пор, пока не переберёт все перечисленные атакующим NS-записи. Соответственно, на один запрос атакующего резолвером будет отправлено огромное число запросов для определения NS-хостов. Так как имена NS-серверов формируются случайно и ссылаются на несуществующие поддомены, они не извлекаются из кэша и каждый запрос атакующего приводит к шквалу запросов к DNS-серверу, обслуживающему домен жертвы.
https://www.opennet.ru/opennews/pics_base/0_1590051660.png (https://en.blog.nic.cz/2020/05/19/nxnsattack-upgrade-resolvers-to-stop-new-kind-of-random-subdomain-attack/)
Исследователи изучили степень подверженности проблеме публичных 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 предложено (https://en.blog.nic.cz/2020/05/19/nxnsattack-upgrade-resolvers-to-stop-new-kind-of-random-subdomain-attack/) использовать RFC-8198 (https://tools.ietf.org/html/rfc8198) для предотвращения обхода кэша DNS, так как запросы отправляются со случайными именами. Суть метода в генерации негативных ответов без обращения к авторитетным DNS-серверам, применяя проверку по диапазонам через DNSSEC. Более простым способом является ограничения числа имён, которые можно определить при обработке одного делегированного запроса, но такой метод может привести к проблемам с некоторыми существующими конфигурациями, так как лимиты не определены в протоколе.
21.05.2020
https://www.opennet.ru/opennews/art.shtml?num=52995