The OpenNET Project / Index page

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

Атака SAD DNS для подстановки фиктивных данных в кэш DNS

15.11.2020 11:42

Группа исследователей из Университета Цинхуа и Калифорнийского университета в Риверсайде разработали новый вид атаки (CVE-2020-25705), позволяющей осуществить подстановку фиктивных данных в кэш DNS-сервера, что может использоваться для подмены IP адреса произвольного домена и перенаправления обращений к домену на сервер злоумышленника. Атака позволяет обойти защиту, добавленную в DNS-серверы для блокирования классического метода отравления кэша DNS, предложенного в 2008 году Дэном Камински (Dan Kaminsky).

Метод Каминского манипулирует незначительным размером поля с идентификационным номером запроса DNS, который составляет всего 16 бит. Для подбора корректного идентификатора, необходимого для спуфинга имени хоста, достаточно отправить примерно 7000 запросов и симулировать около 140 тысяч фиктивных ответов. Атака сводится к отправке на DNS-резолвер большого числа пакетов с фиктивной привязкой к IP и с разными идентификаторами DNS-транзакции. Для предотвращения кэширования первого ответа в каждом фиктивном ответе указывается немного изменённое имя домена (1.example.com, 2.example.com, 3.example.com и т.п.).

Для защиты от данного вида атаки производители DNS-серверов реализовали случайное распределение номеров исходных сетевых портов, с которых отправляются запросы резолвинга, что компенсировало недостаточно большой размер идентификатора (для отправки фиктивного ответа кроме подбора 16 битного идентификатора стало необходимо подобрать и один из 64 тысяч портов, что увеличило число вариантов для подбора до 2^32).

Атака SAD DNS позволяет кардинально упростить определение номера порта, воспользовавшись утечкой сведений об активности сетевых портов. Проблема проявляется во всех современных операционных системах (Linux, Windows, macOS и FreeBSD) и при использовании разных DNS-серверов (BIND, Unbound, dnsmasq). Утверждается, что атаке подвержены 34% всех открытых резолверов, а также 12 из 14 протестированных крупных DNS-сервисов, включая сервисы 8.8.8.8 (Google), 9.9.9.9 (Quad9) и 1.1.1.1 (CloudFlare), а так же 4 из 6 проверенных маршрутизаторов от известных производителей.

Проблема вызвана особенностью формирования ответных ICMP-пакетов, позволяющей определить обращение к неиспользуемым и активным сетевым портам по протоколу UDP. Данная особенность даёт возможность очень быстро сканировать открытые UDP-порты и эффективно обходить защиту на основе случайного выбора исходных сетевых портов, сводя число вариантов перебора к 2^16+2^16 вместо 2^32.

Источником проблемы является механизм ограничения интенсивности отправки ICMP-пакетов в сетевом стеке, в котором применяется предсказуемое значение счётчика, на основе которого начинает действовать ограничение отправки. Указанный счётчик является общим для всего трафика, включая как поддельный трафик атакующего, так и реальный трафик. По умолчанию в Linux отправка ICMP-ответов ограничена интенсивностью в 1000 пакетов в секунду. Для каждого запроса, пришедшего на закрытый сетевой порт, сетевой стек увеличивает счётчик на 1 и отправляет ICMP-пакет с данными от недостижимости порта.

Таким образом, если отправить 1000 пакетов на разные сетевые порты, все из которых закрыты, то сервер на секунду ограничит отправку ICMP-ответов и атакующий может быть уверен, что среди перебранных 1000 портов нет открытых. Если пакет отправлен на открытый порт, сервер не вернёт ICMP-ответ и не изменит значение счётчика, т.е. после отправки 1000 пакетов ограничение на интенсивность ответов не будет достигнуто.

Так как фиктивные пакеты осуществляется с поддельного IP, атакующий не может получить ICMP-ответы, но благодаря общему счётчику может после каждых 1000 поддельных пакетов отправить запрос к несуществующему порту с реального IP и оценить приход ответа - если ответ пришёл, значит в одном из 1000 пакетов угадан верный порт, если нет - сработал лимит и все порты закрыты. Каждую секунду атакующий может отправлять 1000 поддельных пакетов на разные порты и достаточно быстро определить в каком блоке находится открытый порт, после чего cузить выборку и определить конкретный порт.

Предложен следующий сценарий атаки: Когда DNS-резолвер пытается определить доменное имя, он отправляет UDP-запрос на обслуживающий домен DNS-сервер. В момент когда резолвер ожидает ответа атакующий может быстро определить номер исходного порта, который использовался для отправки запроса, и отправить на него поддельный ответ, выдав себя за целевой DNS-сервер, используя спуфинг IP-адреса. DNS-резолвер поместит в кэш переданные в поддельном ответе данные и какое-то время на все другие DNS-запросы доменного имени будет возвращаться подставленный атакующим IP-адрес.

Для успешного совершения атаки необходимо использовать спуфинг IP (отправку с поддельного адреса). По данным CAIDA в 2019 году 30.5% автономных систем не выполняли блокировку пакетов с поддельным исходным IP-адресом (отмечается, что найти дешёвый хостинг у провайдера, не блокирующего спуфинг не составляет труда).

В ядре Linux проблема решена при помощи патча, который рандомизирует параметры ограничения интенсивности отправки ICMP-пакетов, что вносит шум и минимизирует утечку данных по сторонним каналам. Статус устранения уязвимости в дистрибутивах можно оценить на данных страницах: Debian, RHEL, Fedora, SUSE, Ubuntu. В качестве обходных путей защиты можно временно отключить отправку ICMP-пакетов, изменить значение rate-лимита и таймаута в сетевом стеке, а также использовать DNSSEC или DNS cookie.



  1. Главная ссылка к новости (https://headwayapp.co/nextdns-...)
  2. OpenNews: Атака NXNSAttack, затрагивающая все DNS-резолверы
  3. OpenNews: Фундаментальная уязвимость в DNS
  4. OpenNews: Представлен инструмент для проведения атак "DNS rebinding"
  5. OpenNews: Атака на последние версии DNS сервера BIND
  6. OpenNews: Опубликован код эксплоита для атаки на DNS серверы
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/54091-dns
Ключевые слова: dns, attack
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (45) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 12:29, 15/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Так как фиктивные пакеты осуществляется с поддельного IP, атакующий не может получить ICMP-ответы, но благодаря общему счётчику может после каждых 1000 поддельных пакетов отправить запрос к несуществующему порту с реального IP и оценить приход ответа - если ответ пришёл, значит в одном из 1000 пакетов угадан верный порт, если нет - сработал лимит и все порты закрыты.

    Закрывается элементарным дропом незапрошенного трафика в фаерволе (именно DROP, не REJECT). Естественно, ESTABLISHED & RELATED, а также NEW только на 53 пропускаем.

     
     
  • 2.7, одним словом (?), 14:15, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    только забыли о пропуске трафика на динамически открываемые порты
    совсем мелочь
    и весь совет лесом
    как жаль
     
     
  • 3.9, Аноним (9), 15:12, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Можно сделать, например, так (в PF):

    pass out on egress proto { tcp, udp } user _unbound

    Это создаст правила для пропуска трафика с сокета, созданного процессом, работающим (в момент создания сокета) от имени пользователя _unbound, и связанного с ним ответного (опция keep state применяется по умолчанию).

     
     
  • 4.22, Ivan_83 (ok), 20:09, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А можно почитать документацию к unbound и сделать чтобы он ходил по TCP и/или чтобы использовал name case (днс куки кажется) и тп.
     
  • 4.23, Всем Анонимам Аноним (?), 20:09, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    это будет работать на домашнем сервере, а на больших нагрузках conntrack выключен. там еще какие-то были фишки, не помню уже. даже nat просто модуль загруженный уже как-то влиял на производительность, если не ошибаюсь.
     
     
  • 5.39, пох. (?), 12:37, 16/11/2020 Скрыто модератором
  • –7 +/
     
     
  • 6.43, Всем Анонимам Аноним (?), 18:04, 16/11/2020 Скрыто модератором
  • –1 +/
     
     
  • 7.47, пох. (?), 09:41, 17/11/2020 Скрыто модератором
  • +/
     
  • 2.21, Ivan_83 (ok), 20:07, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Всё бы вам костылить через фаервол, вместо того чтобы реально что то исправлять.
     
  • 2.26, Ivan_83 (ok), 20:24, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    И да, специально для таких любителей костылей как вы я ещё раз напишу.

    Фаервол вам не поможет, поскольку если у атакующего есть возможность спуфить src IP то он туда пропишет и 8.8.8.8 и 1.1.1.1 и адреса тех самых DNS серверов которые отвечают за то доменное имя которое хотят проспуфить.
    Это очень не существенное усложнение.

     
     
  • 3.27, Аноним (27), 21:59, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А если правительство требует заворачивать трафик на 8.8.8.8 и 1.1.1.1 на свои сервера, то ваши пляски с фаерволами выглядят смешно, неуместно! У нас снемцами просто проблемы разные :)
     
     
  • 4.28, Ivan_83 (ok), 22:07, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Мы тут обсуждали DNS а не особенности местной политики.
     
     
  • 5.31, Аноним (27), 00:15, 16/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы, это Николай Второй? А подмена ДНС серверов, это не особенность - это местное правило?
     
  • 3.32, Аноним (32), 00:34, 16/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Но сначала он должен послать запросы вам со своего IP, чтобы узнать какие у вас порты открыты-закрыты, чтобы знать куда же слать фейковый ответ от 8.8.8.8. Причем послать их много. чтобы понять на каких именно портах не так тригерется отправка "порт закрыт" и имено туда и надо слать фейковый ответ..

    Но фаервол для этого действительно не нужен, достатчочно вообще не отправлять ICMP на попытку чтото послать на закрытый порт как tcp так и udp.. соотв  настройка есть, кажется, в любой современной ОС..

    Вообще последние месяца 4 идет просто вал попыток соеденений с верхними портами. Наблюдается в разных, не связанных собой сетях, по 100 попыток в минуту на 1 IP и более. Вот набежало за вчера больше 2М запросов  на /24 сеть (это с 1024-65535 на 1024-65535 tcp с уже замеченых в попытках соедениться более 1000 раз ранее. udp тоже сканят, но я не считаю..).. Что делают - непонятно. шлют просто рандомно, в том числе и в полные блекхолы, откуда на внешние раздражители не отвечают.. за 4 месяца уж явно все порты не 1 раз перебрали, зачем долбиться снова и снова?. Но ответы похоже ловят, т.к. не просто с рандомных адресов шлют, по IP явно прослеживаются сети хостингов. зачемто перебирают и IPv6 (берут существующий в DNS адрес, например веб сервера, и начинают к нему перебирать последнюю часть, после последнего : весь /112 кусок сети и перебирают все порты..)

     

  • 1.2, InuYasha (??), 12:29, 15/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    М-да, хитро. Есть даже мысль как можно этот перебор портов оптимизировать (хотя, на практике, наверное, уже всё так и сделали).
    Давно пора уже S2S-соединения обезопашивать. )
     
     
  • 2.24, Ivan_83 (ok), 20:10, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Хакер и столовая.
     
     
  • 3.42, InuYasha (??), 13:53, 16/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Хакер и столовая.

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

     
     
  • 4.45, Ivan_83 (ok), 07:11, 17/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Суть в том, что можно этой фигнёй страдать, да толку нынче мало.
    И сама атака мягко говоря тоже малорезультативная.
    И митигировать её просто.
     

  • 1.3, Sw00p aka Jerom (?), 13:31, 15/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а как же blackhole?
     
     
  • 2.5, Аноним (5), 13:44, 15/11/2020 Скрыто модератором
  • +5 +/
     

  • 1.4, Аноним (4), 13:38, 15/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    2^16+2^16 == 2*2^16 == 2^17
     
     
  • 2.6, одним словом (?), 14:11, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    умножить
    ибо для каждого порта, брат аноним
     
  • 2.8, leibniz (ok), 14:54, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    2^1 чашки чего-нибудь этому анониму
     

  • 1.10, Lex (??), 15:14, 15/11/2020 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • –2 +/
     
     
  • 2.13, anoname (?), 15:52, 15/11/2020 Скрыто модератором
  • +/
     

  • 1.11, Аноним (11), 15:46, 15/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > В качестве обходных путей защиты можно временно отключить отправку ICMP-пакетов, изменить значение rate-лимита и таймаута в сетевом стеке, а также использовать DNSSEC или DNS cookie.

    Чтобы обезопасить интернет - нужно его еще немножечко замедлить.

     
  • 1.14, Аноним (14), 15:52, 15/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А какова ситация с DNSSEC?
     
     
  • 2.16, Сейд (ok), 18:36, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    DNSSEC защищает от этой атаки.
     
     
  • 3.17, microsoft (?), 18:54, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Точно защищает?
     
     
  • 4.18, Сейд (ok), 19:08, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    И да, и нет, сервер должен реализовать строгую проверку DNSSEC (т. е. отклонить ответы, которые нарушают цепочку доверия), чтобы предотвратить атаку. Однако, поскольку DNSSEC всё ещё находится в стадии распространения, серверы вынуждены принимать такие ответы при посещении неправильно настроенного домена.
     
     
  • 5.37, Аноним (14), 10:03, 16/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Эоотможно исправить только одним способом - отключить неправильно настроенные домены от DNS. Если всё и так работает, то админы и не почешутся исправить.
     
  • 4.19, Аноним (19), 19:37, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Верните Балмера!
     
  • 2.25, Ivan_83 (ok), 20:20, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Он как и раньше не нужен.
    Более того, если бы производители днс серверов реально были обеспокоены этим, то они бы ввели явное DNS cookie или nonce в протокол уже давным давно.
    Суть в том, что сервер обязан был бы включать в ответ какое то поле пришедшее с запросом, а его сможно сделать хоть 32 бита хоть 32 байта, рандом естессно, и после этого уже бесполезно что то пытатся подобрать.

    Сейчас с проблемой борятся в виде костылей/методов:
    - ходят по TCP
    - к 16 битам в DNS поле ID прибавляют 16 бит (чуть меньше) номер порта, ещё рандомизируют case букв в запросе и проверяют что в ответе имя домена совпадает, например: EXaMPlE.cOM
    - и вот этот ваш ненужный DNS Sec, который по сути задуман для другого, и lets encrypt и вся эта движуха с сертификатами и https везде - это всё не про вашу безопасность, это про тотальный контроль интернета и централизацию управления.

    К великому счастью лень и раздолбайство не дают внедрять DNS sec, по крайней мере сильно тормозят его внедрение, и никакого гугла тут нет чтобы с одной стороны выкручивать яйца админам с другой подкидывать бабла послушным.

    В целом резолвер уже сейчас может с лёгкостью детектировать попытки отравить кеш и скажем переключатся на TCP и слать алерты админу.
    Опять же, никто этого не делает.
    Потому что это мало кому интересно, и то что кто то завернёт трафик на себя - обычни мало к чему приводит, ибо нынче много tls трафика, просто соединения не будут проходить либо содержимое не будет раскрыто.

     
     
  • 3.29, Аноним (14), 22:09, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >lets encrypt и вся эта движуха с сертификатами и https везде - это всё не про вашу безопасность, это про тотальный контроль интернета и централизацию управления.

    Главное криптографию приделать. А сертификаты CA x.509 для неё нужные можно потом поставить. Или не сертификаты x.509, a OpenPGP, или вообще ключи из блокчейна, главное чтобы аппарат имелся.


     
     
  • 4.30, Ivan_83 (ok), 23:44, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Вы чего то не понимаете.

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

    Так вот, благодаря тому что есть DNS Sec и https везде стал обязателен достаточно у вашего издания отобрать днс имя и/или отозвать ваш сертификат (чёрные списки быстро разлетаются).
    После этого на ваш сайт смогут попасть полтора человека, остальные увидят страшное сообщение и убегут в ужасе.

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

    Я не сторонник шизопатриотии, я сторонник децентрализации.
    То что сейчас происходит с DNS sec + https - это игра в долгую для получения контроля.
    Возможно ситуация на рынке браузеров, когда их все делают одни и теже люди тоже из этой оперы.

    В общем, все эти ваши фантазии про крипту, они далеки от реальности, вы похоже совсем не понимаете как это устроено. И даже если понимаете то почему то думаете что сможете разом у всех изменить все криптобиблиотеки, в тч которые в браузерах.
    Посмотрите вон как банальный ГОСТ пытаются завезти и как оно туго заходит, а с вашими революционными предложениями вас просто пошлют сразу.

     
     
  • 5.35, Аноним (14), 10:00, 16/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Дело в том, что сам браузер менять не надо. Нужно обращаться к DNS не напрямую, а через локальный прокси, который сам уже будет разговаривать проверять OpenPGP и разговаривать с блокчейном и т.д. Так я пользуюсь DNSCrypt, хотя его сайты из коробки не поддерживают, всё идёт через чужие сервера.

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

     
     
  • 6.46, Ivan_83 (ok), 07:13, 17/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Можно, только это путь в никуда, как и всякие альтернативные днс системы.
     
     
  • 7.48, АнониМММ (?), 20:25, 17/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    https://hub.docker.com/r/jedisct1/dnscrypt-server

    поднимается за 2 минуты

     
  • 3.33, пох. (?), 00:41, 16/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Он как и раньше не нужен.

    Тут тов.майор с вами не согласны - напомнить, сколько remote code exec в нем находят каждый год? И еще долго будут - поскольку невменяемая блоатварь.

    А белкам-истеричкам, разумеется - "главное криптографию приделать". К чему, зачем, и от чего она должна их защитить - они без понятия, но очень нада!

    А надежный протокол - не нада, зачем, это очень сложно.

    И ietf'овские пердуны с ними всецело и полностью - вместо тривиальных исправлений протокола, придуманного во времена, когда компьютеры были большие - всякие dns fuck day с ломанием всего что не шагает в ногу.

     
     
  • 4.36, Аноним (14), 10:01, 16/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это не защитит от поддельных ответов со стороны DNS-сервера.
     
  • 4.38, Аноним (38), 11:05, 16/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > напомнить, сколько remote code exec в нем находят каждый год?

    А напомни. С пруфами, конечно, а не как всегда.

     
     
  • 5.40, Sw00p aka Jerom (?), 13:01, 16/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    SIGRed CVE-2020-1350
     
     
  • 6.44, Аноним (38), 21:26, 16/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вынь-дос-сервер? Познавательно, но хотелось бы чего-нибудь более жизненного. И ежегодного, как было обещано.
     

  • 1.20, Аноним (20), 19:58, 15/11/2020 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • +/
     
  • 1.34, Аноним (34), 04:10, 16/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    DNSCrypt
     
     
  • 2.41, Michael Shigorin (ok), 13:06, 16/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > DNSCrypt

    #33

     

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



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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