URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 125872
[ Назад ]
Исходное сообщение
"Новый вариант атаки SAD DNS для подстановки фиктивных данных в кэш DNS "
Отправлено opennews , 17-Ноя-21 20:06 
Группа исследователей из Калифорнийского университета в Риверсайде опубликовала новый вариант атаки SAD DNS (CVE-2021-20322), работающий несмотря на защиту, добавленную в прошлом году для блокирования уязвимости CVE-2020-25705. Новый метод в целом аналогичен прошлогодней уязвимости и отличается лишь использованием другого типа ICMP-пакетов для проверки активных UDP-портов. Предложенная атака позволяет осуществить подстановку фиктивных данных в кэш DNS-сервера, что можно использовать для подмены в кэше IP адреса произвольного домена и перенаправления обращений к домену на сервер злоумышленника...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=56176

Содержание
Сообщения в этом обсуждении
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено QwertyReg , 17-Ноя-21 20:06 
>Предложенный метод работоспособен только в сетевом стеке Linux

Дякую, Б-же, що на магистральных маршрутизаторах стоит IOS, а не вот это вот.

"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено YetAnotherOnanym , 17-Ноя-21 21:56 
Типа, если DNS-сервер с отравленным кэшем получит запрос от магистрального маршрутизатора на IOS, то сумеет выдать правильный ответ несмотря на неверные данные, хранящиеся в кэше? Или IOS не обращается к кэширующим DNS-серверам и любое имя резолвит самостоятельно, запрашивая только авторитетные сервера и спускаясь каждый раз от *.root-servers.net?
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено AntonAlekseevich , 17-Ноя-21 23:09 
Магистралы пользуются теми решениями которые продвигали сертифицированные сетевые профессионалы. (И не уровня CCNP:ENCOR, выше.)
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Урри , 17-Ноя-21 21:01 
Патч зачетный, из двух строк. Замена
-    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);
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Аноним , 17-Ноя-21 21:51 
Дай ссылку на патч.
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Аноним , 17-Ноя-21 22:42 
В тексте новости ссылки на словах "приняты в состав".
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено d , 20-Ноя-21 01:20 
Оставлю ссылку на новость, а то мало ли. https://www.opennet.me/opennews/art.shtml?num=56176
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Онаним , 17-Ноя-21 22:02 
Ждём DE SADE DNS
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Аноним , 18-Ноя-21 10:55 
SODOM DNS
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Robin Bobin , 18-Ноя-21 14:15 
Для доменов и сервисов в целом, но для https мимо. В любом случае, какой ip не получишь, а сервер должен будет подписать хендшейк приватником, которому соответствует единственный публичник этого домена, который апрувлен/подписан всей цепочкой до корневых сертификатов.
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Аноним , 17-Ноя-21 22:03 
У меня сегодня прикол. На свежеустановленной Arch pacman без проблем устанавливает любые пакеты из реп, а chromium и firefox не открывают ни один сайт. DNS_PROBE_FINISHED_NO_INTERNET. Куда копать? Причем на другом компе с практически теми же настройками всё работает.
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Аноним , 17-Ноя-21 23:05 
В systemd
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Аноним , 18-Ноя-21 09:16 
Не... systemd-networkd и systemd-resolved использую, да. Но pacman же работает без проблем. DNSSEC и DNSOverTLS отключал в настройках там - не помогает.
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено AntonAlekseevich , 17-Ноя-21 23:11 
Если поставил NetworkManager то nmtui и вперед. Если ничего то проверь /etc/resolv.conf
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Аноним , 18-Ноя-21 09:18 
Не... Не ставил.  /etc/resolv.conf такой же, как и на рабочем компе.
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено AntonAlekseevich , 20-Ноя-21 12:59 
> Не... Не ставил.  /etc/resolv.conf такой же, как и на рабочем компе.

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

`traceroute -U -4 -p 53 1.1.1.1`

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

`traceroute -4 1.1.1.1`

"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено microcoder , 17-Ноя-21 23:14 
Открывает, но оооочень долго. Ютуб без кеша DNS в самом firefox, открывает секунд 40. И кажется только с ютубом такие жестокие задержки.
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Аноним , 18-Ноя-21 09:22 
Отключал DNSoverHTTPS, запускал с чистыми профилями - не помогло. Интернет то работает. Почему только браузеры не хотят?
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Robin Bobin , 18-Ноя-21 14:18 
Stubby через TLS?

обнови finger pin

"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Аноним , 18-Ноя-21 19:21 
Stubby с systemd-resolved не нужен. Не установлен.
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено IZh. , 18-Ноя-21 00:27 
DNSSEC.
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено leap42 , 18-Ноя-21 04:28 
> 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

"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено leap42 , 18-Ноя-21 04:30 
[morph@wrkstation] ~$ cat /etc/nsswitch.conf:
passwd:         files systemd
group:          files systemd
shadow:         files
gshadow:        files
hosts:          resolve [!UNAVAIL=return] dns myhostname
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Аноним , 18-Ноя-21 06:38 
DoH не защитит сам сервер 1.1.1.1 от этой атаки. Если отравить его кеш, то все пользователи DoH получат ядовитый ответ.
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено leap42 , 18-Ноя-21 08:33 
> DoH не защитит сам сервер 1.1.1.1 от этой атаки. Если отравить его
> кеш, то все пользователи DoH получат ядовитый ответ.

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

"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Аноним , 18-Ноя-21 10:01 
> Справделиво. Но вероятность успешной атаки на Клаудфлару ничтожна.

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

"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Аноним , 19-Ноя-21 21:05 
А если я использую 5-ь ДНС серверов от разных провайдеров, и все они вернули различные IP адреса, что делать, открывать 5-ь вкладок в браузере??? ;)
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Аноним , 20-Ноя-21 06:12 
> А если я использую 5-ь ДНС серверов от разных провайдеров, и все
> они вернули различные IP адреса

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

"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Аноним , 18-Ноя-21 13:45 
Не поэтому. Провайдеры его просто никогда не внедрят, ибо им предписано блокировать сайты.
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено нах.. , 18-Ноя-21 13:50 
MulticastDNS=yes
LLMNR=yes

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

"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено leap42 , 19-Ноя-21 07:02 
> Ахахахахаохохо... ох уж эти локалхосты.

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

"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Sem , 18-Ноя-21 22:50 
DNSSEC в systemd-resolved был сломан (не знаю как сейчас). Не стоит делать заключений о DNSSEC только в этой реализации.
"Новый вариант атаки SAD DNS для подстановки фиктивных данных..."
Отправлено Аноним , 18-Ноя-21 00:52 
DoH или DoT в браузере проверить