The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Атака NXNSAttack, затрагивающая все DNS-резолверы

21.05.2020 11:23

Группа исследователей из Тель-Авивского университета и Междисциплинарного центра в Герцлии (Израиль) разработала новый метод атаки 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. Более простым способом является ограничения числа имён, которые можно определить при обработке одного делегированного запроса, но такой метод может привести к проблемам с некоторыми существующими конфигурациями, так как лимиты не определены в протоколе.

  1. Главная ссылка к новости (https://en.blog.nic.cz/2020/05...)
  2. OpenNews: Зафиксировано использование Memcached в качестве усилителя трафика для DDoS-атак
  3. OpenNews: Предупреждение о задействовании UPnP/SSDP в качестве усилителя DDoS-атак
  4. OpenNews: Зафиксировано использование протокола RIPv1 в качестве усилителя DDoS-атак
  5. OpenNews: DDoS-атака в 400 Гбит/с была совершена с привлечением всего 4529 NTP-серверов
  6. OpenNews: Рост атак, связанных с захватом контроля над DNS
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/52995-nxnsattack
Ключевые слова: nxnsattack, dns, ns, ddos
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (56) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, ryoken (ok), 12:53, 21/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Хм.. это чтобы по всему глобусу котиков не посмотреть было? :D
     
  • 1.2, InuYasha (?), 13:06, 21/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    Во что вырос DNS! А так всё просто начиналось... )
     
     
  • 2.4, Жека Воробьев (?), 13:37, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • –7 +/
    да в it вагон и маленькая тележка окаменелых технологий: dns, smtp, http, ipv4/6
     
     
  • 3.6, Fracta1L (ok), 13:38, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • –14 +/
    Весь интернет-стек, начиная с tcp/ip, пора выбрасывать на свалку и пилить что-то с нуля. Про разжиревший веб даже говорить нечего.
     
     
  • 4.13, qwe (??), 14:56, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Весь интернет-стек, начиная с tcp/ip, пора выбрасывать на свалку и пилить что-то с нуля.

    ты вероятно имел ввиду всё что выше tcp-ip. Это правда, всё что поверх http работает надо выкинуть)

     
     
  • 5.20, Аноним (20), 16:20, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    TCP тоже устарел. Как только не пытаются его раскочегарить, да всё бестолку. Жаль, что SCTP не прижился - была бы отличная замена. А так - теперь все протоколы будут постепенно переползать на UDP (если не уже), и каждый будет изобретать колесо заново.
     
     
  • 6.22, Аноним (22), 16:55, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    В сетях с потерями 70% пакетов (и 2/3 из оставшегося приходят в произвольном порядке) tcp и сегодня обеспечивает наилучшие показатели. Это спутниковый/мобильный интернет, adsl. Естественно, в оптоволоконных сетях что-нибудь поверх udp может быть лучше, с идеальным соединением куча всего сразу не таким критичным становится.
     
     
  • 7.32, topin89 (ok), 21:55, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А разве этот новый протокол не был сделан из-за постоянных проблем с tcp в сотовых сетях?
    Честное любопытство, я нихера в сетях не разбираюсь.
     
     
  • 8.36, Аноним (22), 22:49, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Который из А то они всё решают проблемы, решают, да решить не могут Какие проб... текст свёрнут, показать
     
     
  • 9.52, topin89 (ok), 17:14, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    QUIC... текст свёрнут, показать
     
  • 9.53, Lex (??), 07:34, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да кто ж спорит, что у tcp т н 171 стабильность 187 выше Другое дело, когда... текст свёрнут, показать
     
  • 7.42, Аноним (42), 02:20, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема, правда, в алгоритмах congestion control, а не в самом tcp. Надо дефолты менять, а не протокол
     
  • 7.47, t28 (?), 10:16, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > В сетях с потерями 70% пакетов (и 2/3 из оставшегося приходят в произвольном порядке)
    > tcp и сегодня обеспечивает наилучшие показатели.

    В сетях с потерей 14% (и более) пакетов TCP не работает от слова "совсем".
    При потерях до 3,5% еще кое-как живет, а начиная, приблизительно, с 4% доступ
    к современным сервисам начинает напоминать dial-up.

    Для доставки инфы в сетях с потерями рекомндую использовать старый проверенный X.25
    (но ни в коем случае не поддаваться на разводку под названием XOT).

     
     
  • 8.48, Аноним (22), 10:38, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Может, и диалап задержки действительно были , но вполне работало и даже очень ... текст свёрнут, показать
     
     
  • 9.50, JL2001 (ok), 12:36, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    что именно у вас работало http over tcp про какие альтернативы речь ... текст свёрнут, показать
     
     
  • 10.51, Аноним (22), 14:00, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Http over tcp включая модем , socket over tcp приложуха Были ещё варианты ис... текст свёрнут, показать
     
  • 6.29, Michael Shigorin (ok), 21:04, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Жаль, что SCTP не прижился - была бы отличная замена.

    Что ж Вы в нём весь тот вагон дырок сразу не фиксили?..

     
     
  • 7.43, Нолекс (?), 02:49, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так он певец ртом, а не головой...
     
  • 4.24, vsg (?), 17:16, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Уже делается и проходит тестирование.
     
     
  • 5.26, Fracta1L (ok), 18:29, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    По какому запросу искать?


     
  • 4.40, Аноним (42), 02:13, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что, опять гениев-передельщиков подвезли? Или оттаяли по весне просто?
     
  • 4.54, Tifereth (ok), 06:29, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так и вижу: "сегодня мы отключаем весь Интернет - подождите лет двадцать, может, что эффективнее напишем".
     
  • 4.61, AntonAlekseevich (ok), 19:31, 25/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Весь интернет-стек, начиная с tcp/ip, пора выбрасывать на свалку и пилить что-то с нуля.

    Согласен, DNS и udp/ip должны жить.

    А если честно, попробуйте изобрести и затем продемонстрировать новый стек протоколов, так чтобы он был понятен как и***у с первого раза, так и человеку вашего уровня.

     
  • 3.12, qwe (??), 14:53, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +13 +/
    Какой жирный. Ща придут неокаменевшие девелоперы и запилят нам правильные протоколы на основе обмена json-ами :)
     
     
  • 4.21, Аноним (21), 16:22, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +10 +/
    С эталонной реализицией на Node.js
     

  • 1.3, crypt (ok), 13:35, 21/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Comodo Secure (8.26.56.26) - 435 раз и Norton ConnectSafe (199.85.126.10) - 569 раз.

    не удивлен

     
     
  • 2.5, Fracta1L (ok), 13:37, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Очень секурно, очень сейфно
     

  • 1.8, ryoken (ok), 14:19, 21/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Выкапывайте\допиливайте уже NetBEUI :D.
     
  • 1.10, КО (?), 14:37, 21/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ежели днс от провайдера, мне, ламеру, секурно?
     
     
  • 2.14, Аноним (-), 14:59, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    пока провайдера либо твой (ламера) любимый сайтик не задудосили - то да. У тебя же нет своего (ламерского) ресолвера на арендованом у этого провайдера реальном айпи, так ведь? Если есть - от трёх до пяти, насчёт конфискации не уверен.
     

  • 1.11, Аноним (11), 14:50, 21/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это не баг, а фича. ИМХО, единственный нормальный способ защиты это DPI, для самых бедных -- fail2ban или что-то в этом духе. Предложенные защиты почему-то нацелены на то, что атакующий сервер является контролируемым и его надо делать защищенным. Однако, имеется достаточно большие ботнеты, где поднять любые сервера не проблема.

    Решение на DNSSEC-Validated Cache является самодостаточным и походу всех рано или поздно заставят переходить на DNSSEC-сервера.

     
     
  • 2.17, Онаним (?), 15:20, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Про любовь к DNSSEC могу сказать только одно:
    https://ianix.com/pub/dnssec-outages.html
    Любитесь с ним сами.
     
     
  • 3.30, Michael Shigorin (ok), 21:10, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > http://ianix.com/pub/dnssec-outages.html

    Спасибо, вот этого не слышал:

    DNSSEC is not encrypted, which is responsible for many of its failures. Rather than doing per-message/packet encryption like other secure protocols, DNSSEC was made compatable with censorship and surveillance. To enable censorship and surveillance, an extremely complex and thus fragile protocol was required, thereby resulting in outages, semi-outages, and sometimes just plain bizarre situations.

     
     
  • 4.33, Онаним (?), 21:55, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да не за что.
    Как сталкивающийся в силу характера деятельности - подтверждаю, DNSSEC - это просто подпись.
     
     
  • 5.58, suffix (ok), 14:28, 25/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да, но полезная - таже валидация tlsa dane, sshfp
     
     
  • 6.59, Онаним (?), 18:46, 25/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Да, но полезная - таже валидация tlsa dane, sshfp

    Первое не работает почти нигде, от слова "совсем", а учитывая, что тот же виндорезолвер валидации DNSSEC не имеет, в винде не заработает ещё дольше. Второе, ну, вы поняли. Слишком узко-специфичное, можно бы было и другими способами реализовать.

     
     
  • 7.60, suffix (ok), 18:49, 25/05/2020 [^] [^^] [^^^] [ответить]  
  • +/

    > Первое не работает почти нигде, от слова "совсем".

    В exim работает а это уже хорошо !

     
  • 2.38, Ivan_83 (ok), 00:08, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Всё гораздо проще - рейтлимиты, и по меньше выставлять резолверы наружу.

    В современном мире вообще не понятно зачем они сдались пользователям: встроить рекурсивный резолвер можно во что угодно, ресурсов он не жрёт.
    Поскольку 99% это хомяки то у них будет просто всё работать.
    Корпораты могут просто днс запросы на шлюзе заворачивать в свой днс сервер, который знает локальные зоны и умеет рекурсию в инет и кеш.

    Никакие DNSSEC, DoT, DoH - не нужны.

     
     
  • 3.49, JL2001 (ok), 12:32, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Корпораты могут просто днс запросы на шлюзе заворачивать в свой днс сервер,
    > который знает локальные зоны и умеет рекурсию в инет и кеш.
    > Никакие DNSSEC, DoT, DoH - не нужны.

    всё с вами понятно, любитель переадресовать на свой айпишник

     

  • 1.15, Аноним (15), 15:16, 21/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хех, а ведь бывают домашние роутеры, светящие во внешний мир 53м портом (таких много среди асусов, например).
     
     
  • 2.27, Alen (??), 19:20, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Они кэширующие и к теме не относятся
     

  • 1.16, YetAnotherOnanym (ok), 15:18, 21/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > атакующий может выдать в ответе огромный список не повторяющихся NS-серверов с несуществующими фиктивными именами поддоменов жертвы (fake-1.victim.com, fake-2.victim.com,... fake-1000.victim.com). Резолвер попытается отправить запрос DNS-серверу жертвы, но получит ответ, что домен не найден, после чего попытается определить следующий NS-сервер в списке и так до тех пор пока не переберёт все перечисленные атакующим NS-записи

    Гениально, чо...

     
  • 1.23, псевдонимус (?), 16:59, 21/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хорошая уязвимость. Полезная.
     
  • 1.25, nathoo (?), 17:51, 21/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Дело за малым: зарегистрировать валидный DNS на краденый паспорт...
     
  • 1.28, Ward (?), 20:53, 21/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    И как вовремя-то. DoH-сервера-то не подвержены.
     
     
  • 2.34, Аноним (34), 22:00, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    С хрена ли не подвержены если все эти DoH DoT это только прокси к обычному ресолверу?.. не все ли равзно как на тот ресолвер прилетит запрос на ресолв DNS имени атакуещего.
     
  • 2.37, Онаним (?), 22:57, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > И как вовремя-то. DoH-сервера-то не подвержены.

    С ДоХ другая проблема, их надо ДоХ чтобы справиться с нагрузкой, либо акселераторы, потому что очень уж монструозно.

     
  • 2.39, Ivan_83 (ok), 00:09, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Они и не нужны вовсе.
     
  • 2.41, Аноним (42), 02:17, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это ты сам придумал. DoH это транспорт до клиента, к самому резолверу он никак относится
     

  • 1.35, Аноним (35), 22:38, 21/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Bind по производительности всех уделал
     
     
  • 2.44, Нолекс (?), 02:55, 22/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    двачую...
     

  • 1.45, sn (??), 02:56, 22/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А если иметь запись, например
    *.victim.com. A ns.victim.com.

    Как думаете поможет?

     
  • 1.46, sn (??), 02:58, 22/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    вернее CNAME
     
  • 1.55, antonimous (?), 20:49, 24/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Легаси, ёп. Чемодан без ручки.
    Причем, везде.
    arpanet, BIOS, x86 и прочее говно мамонта ибо "бизнес" и "обратная совместимость". XXI век. Деградация технологий ака екстенсивное "развитие".
     
     
  • 2.56, Michael Shigorin (ok), 20:54, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Легаси, ёп. Чемодан без ручки.

    Вы бы знали, каким "легаси" являетесь сами...

    PS: кто-то подметил, что ссылки на век, год и подобные ахи-охи характерны для секты свидетелей линейного прогресса -- модное западное течение последних нескольких десятилетий и веков (в разную силу), сводящее всё развитие мира к убогому вектору, да ещё и путающее его направленность по знаку (хотя некоторые и там замечают, в итоге появляются словосочетания вроде "highway to hell").

    PPS: штаты, кстати, "здесь и сейчас" (tm) подкидывают таким вот лопоухим новые задачки -- например, как одновременно верить в "рынок" и... легитимность мер по принудительному ограничению международной конкуренции.  Ну там, make competition run slower, а то и прям бряк -- impede progress.

     
     
  • 3.57, все такойже ононим как и всегда (?), 14:17, 25/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    самое весёлое, что в основном легаси то и работает, а смузи решения не очень.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру