The OpenNET Project / Index page

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

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

17.11.2021 19:44

Группа исследователей из Калифорнийского университета в Риверсайде опубликовала новый вариант атаки SAD DNS (CVE-2021-20322), работающий несмотря на защиту, добавленную в прошлом году для блокирования уязвимости CVE-2020-25705. Новый метод в целом аналогичен прошлогодней уязвимости и отличается лишь использованием другого типа ICMP-пакетов для проверки активных UDP-портов. Предложенная атака позволяет осуществить подстановку фиктивных данных в кэш DNS-сервера, что можно использовать для подмены в кэше IP-адреса произвольного домена и перенаправления обращений к домену на сервер злоумышленника.

Предложенный метод работоспособен только в сетевом стеке Linux из-за привязки к особенности работы механизма обработки ICMP-пакетов в Linux, который выступает источником утечки данных, упрощающих определения номера UDP-порта, использованного сервером для отправки внешнего запроса. Изменения, блокирующие утечку информации, приняты в состав ядра Linux в конце августа (исправление вошло в состав ядра 5.15 и сентябрьских обновлений LTS-веток ядра). Исправление сводится к переходу на использование в сетевых кэшах алгоритма хеширования SipHash вместо Jenkins Hash. Статус устранения уязвимости в дистрибутивах можно оценить на данных страницах: Debian, RHEL, Fedora, SUSE, Ubuntu.

По данным выявивших проблему исследователей уязвимости подвержено около 38% находящихся в сети открытых резолверов, включая популярные DNS-сервисы, такие как OpenDNS и Quad9 (9.9.9.9). Что касается серверного ПО, то атака может быть проведена при использовании на Linux-сервере таких пакетов, как BIND, Unbound и dnsmasq. На DNS-серверах, запущенных с использованием Windows и BSD-систем, проблема не проявляется. Для успешного совершения атаки необходимо использовать спуфинг IP, т.е. требуется чтобы провайдер атакующего не блокировал пакеты с поддельным исходным IP-адресом.

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

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

Метод SAD DNS позволяет кардинально упростить определение номера сетевого порта и свести атаку к классическому методу Каминского. Атакующий может определить обращение к неиспользуемым и активным UDP-портам, воспользовавшись утечкой сведений об активности сетевых портов при обработке ответных ICMP-пакетов. Метод позволяет на 4 порядка сократить число вариантов перебора - 2^16+2^16 вместо 2^32 (131_072 вместо 4_294_967_296). Утечка сведений, позволяющих быстро определить активные UDP-порты, вызвана недоработкой в коде обработки ICMP-пакетов с запросами фрагментации (флаг ICMP Fragmentation Needed) или перенаправления (флаг ICMP Redirect). Отправка подобных пакетов изменяет состояние кэша в сетевом стеке, что позволяет на основе реакции сервера определить какой из UDP-портов активен, а какой нет.

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

  1. Главная ссылка к новости (https://arstechnica.com/gadget...)
  2. OpenNews: Атака SAD DNS для подстановки фиктивных данных в кэш DNS
  3. OpenNews: Атака NXNSAttack, затрагивающая все DNS-резолверы
  4. OpenNews: Фундаментальная уязвимость в DNS. Рекомендуется срочно обновить BIND
  5. OpenNews: Опубликован код эксплоита для атаки на DNS серверы
  6. OpenNews: Уязвимости в Dnsmasq, позволяющие подменить содержимое в кэше DNS
Лицензия: CC BY 3.0
Наводку на новость прислал Artem S. Tashkinov
Короткая ссылка: https://opennet.ru/56176-dns
Ключевые слова: dns, attack
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (33) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, QwertyReg (ok), 20:06, 17/11/2021 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –20 +/
     

     ....ответы скрыты (2)

  • 1.4, Урри (ok), 21:01, 17/11/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Патч зачетный, из двух строк. Замена
    - hval = jhash_1word((__force u32)daddr, fnhe_hashrnd);
    - return hash_32(hval, FNHE_HASH_SHIFT);
    на
    + hval = siphash_1u32((__force u32)daddr, &fnhe_hash_key);
    + return hash_64(hval, FNHE_HASH_SHIFT);
     
     
  • 2.5, Аноним (5), 21:51, 17/11/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дай ссылку на патч.
     
     
  • 3.9, Аноним (9), 22:42, 17/11/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В тексте новости ссылки на словах "приняты в состав".
     
     
  • 4.35, d (??), 01:20, 20/11/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Оставлю ссылку на новость, а то мало ли. https://www.opennet.ru/opennews/art.shtml?num=56176
     

  • 1.7, Онаним (?), 22:02, 17/11/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ждём DE SADE DNS
     
     
  • 2.26, Аноним (26), 10:55, 18/11/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    SODOM DNS
     
     
  • 3.29, Robin Bobin (?), 14:15, 18/11/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Для доменов и сервисов в целом, но для https мимо. В любом случае, какой ip не получишь, а сервер должен будет подписать хендшейк приватником, которому соответствует единственный публичник этого домена, который апрувлен/подписан всей цепочкой до корневых сертификатов.
     

  • 1.8, Аноним (8), 22:03, 17/11/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    У меня сегодня прикол. На свежеустановленной Arch pacman без проблем устанавливает любые пакеты из реп, а chromium и firefox не открывают ни один сайт. DNS_PROBE_FINISHED_NO_INTERNET. Куда копать? Причем на другом компе с практически теми же настройками всё работает.
     
     
  • 2.10, Аноним (10), 23:05, 17/11/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В systemd
     
     
  • 3.22, Аноним (22), 09:16, 18/11/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Не... systemd-networkd и systemd-resolved использую, да. Но pacman же работает без проблем. DNSSEC и DNSOverTLS отключал в настройках там - не помогает.
     
  • 2.12, AntonAlekseevich (ok), 23:11, 17/11/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Если поставил NetworkManager то nmtui и вперед. Если ничего то проверь /etc/resolv.conf
     
     
  • 3.23, Аноним (22), 09:18, 18/11/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Не... Не ставил.  /etc/resolv.conf такой же, как и на рабочем компе.
     
     
  • 4.37, AntonAlekseevich (ok), 12:59, 20/11/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Не... Не ставил.  /etc/resolv.conf такой же, как и на рабочем компе.

    До 53/UDP порта любого хоста из resolv.conf трасса есть?

    'traceroute -U -4 -p 53 1.1.1.1'

    + отдельно проверить трассу до хоста без указания протокола.

    'traceroute -4 1.1.1.1'

     
  • 2.13, microcoder (ok), 23:14, 17/11/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Открывает, но оооочень долго. Ютуб без кеша DNS в самом firefox, открывает секунд 40. И кажется только с ютубом такие жестокие задержки.
     
     
  • 3.24, Аноним (22), 09:22, 18/11/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Отключал DNSoverHTTPS, запускал с чистыми профилями - не помогло. Интернет то работает. Почему только браузеры не хотят?
     
  • 2.30, Robin Bobin (?), 14:18, 18/11/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Stubby через TLS?

    обнови finger pin

     
     
  • 3.31, Аноним (22), 19:21, 18/11/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Stubby с systemd-resolved не нужен. Не установлен.
     

  • 1.15, IZh. (?), 00:27, 18/11/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    DNSSEC.
     
     
  • 2.18, leap42 (ok), 04:28, 18/11/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > DNSSEC

    Нет конечно. Оно никогда не было 100% рабочим и уже скорее всего не будет. Иногда корректные ответы развалидируются и всё, приплыли. Поэтому и появились DoT и DoH.

    cat /etc/systemd/resolved.conf:

    DNS=1.1.1.1#one.one.one.one 9.9.9.10#dns10.quad9.net
    FallbackDNS=
    Domains=lan local ~.
    DNSSEC=no
    DNSOverTLS=yes
    MulticastDNS=yes
    LLMNR=yes
    Cache=yes
    CacheFromLocalhost=yes
    DNSStubListener=udp
    DNSStubListenerExtra=
    ReadEtcHosts=yes
    ResolveUnicastSingleLabel=no

    ll /etc/resolv.conf
    /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

    cat /etc/NetworkManager/NetworkManager.conf:
    [main]
    plugins=ifupdown,keyfile
    dns=none
    rc-manager=unmanaged
    systemd-resolved=false

    [ifupdown]
    managed=true

    [connection]
    connection.llmnr=1

     
     
  • 3.19, leap42 (ok), 04:30, 18/11/2021 [^] [^^] [^^^] [ответить]  
  • +/
    [morph@wrkstation] ~$ cat /etc/nsswitch.conf:
    passwd:         files systemd
    group:          files systemd
    shadow:         files
    gshadow:        files
    hosts:          resolve [!UNAVAIL=return] dns myhostname
     
  • 3.20, Аноним (20), 06:38, 18/11/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    DoH не защитит сам сервер 1.1.1.1 от этой атаки. Если отравить его кеш, то все пользователи DoH получат ядовитый ответ.
     
     
  • 4.21, leap42 (ok), 08:33, 18/11/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > DoH не защитит сам сервер 1.1.1.1 от этой атаки. Если отравить его
    > кеш, то все пользователи DoH получат ядовитый ответ.

    Справделиво. Но вероятность успешной атаки на Клаудфлару ничтожна. Я раньше тож был фанатом DNSSEC и постоянно использовал его. И именно он не пускал на легитимные сайты (ох и не сразу я это понял, но когда понял, нагуглил что это норма).

     
     
  • 5.25, Аноним (20), 10:01, 18/11/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Справделиво. Но вероятность успешной атаки на Клаудфлару ничтожна.

    Сервера у всех одинаковые. Вероятность отравления кеша cloudflare столько же высока как и кеша провайдера. Сервер сам нам скажет, сколько времени будет жить его кеш для определённого домена и в этот момент нужно отправить ему запрос этого домена и ответ на правильно угаданный порт. Строго говоря особо гадать и не нужно, можно отправить на все порты, благо их всего лишь 65000. Главное для атаки это возможность отправлять трафик с произвольного ip-адреса и к сожалению, есть ещё довольно много мест где это возможно.

     
     
  • 6.34, Аноним (34), 21:05, 19/11/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А если я использую 5-ь ДНС серверов от разных провайдеров, и все они вернули различные IP адреса, что делать, открывать 5-ь вкладок в браузере??? ;)
     
     
  • 7.36, Аноним (20), 06:12, 20/11/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > А если я использую 5-ь ДНС серверов от разных провайдеров, и все
    > они вернули различные IP адреса

    Это кстати штатная ситуация для Google с его CDN. Как поступать в такой странной ситуации решать тому, кто настроил эту проблему с 5 серверами. В штатной ситуации несколько серверов настраиваются для отказоустойчивости, а не для верификации. Подлинность ответа можно проверить только через DNSSEC, но оказывается есть горе-админы, что умудряются слать ответы за свой домен с неправильными подписями.

     
  • 3.27, Аноним (27), 13:45, 18/11/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не поэтому. Провайдеры его просто никогда не внедрят, ибо им предписано блокировать сайты.
     
  • 3.28, нах.. (?), 13:50, 18/11/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    MulticastDNS=yes
    LLMNR=yes

    Ахахахахаохохо... ох уж эти локалхосты.

     
     
  • 4.33, leap42 (ok), 07:02, 19/11/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ахахахахаохохо... ох уж эти локалхосты.

    Да, на всех домашних тачках Linux. А что не так? К чему коммент? Тут далеко не все с десяточки через pussy.exe работают.

     
  • 3.32, Sem (??), 22:50, 18/11/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    DNSSEC в systemd-resolved был сломан (не знаю как сейчас). Не стоит делать заключений о DNSSEC только в этой реализации.
     

  • 1.17, Аноним (17), 00:52, 18/11/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    DoH или DoT в браузере проверить
     

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



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

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