URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 122433
[ Назад ]

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

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

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


Содержание

Сообщения в этом обсуждении
"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 15-Ноя-20 12:29 
> Так как фиктивные пакеты осуществляется с поддельного IP, атакующий не может получить ICMP-ответы, но благодаря общему счётчику может после каждых 1000 поддельных пакетов отправить запрос к несуществующему порту с реального IP и оценить приход ответа - если ответ пришёл, значит в одном из 1000 пакетов угадан верный порт, если нет - сработал лимит и все порты закрыты.

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


"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено одним словом , 15-Ноя-20 14:15 
только забыли о пропуске трафика на динамически открываемые порты
совсем мелочь
и весь совет лесом
как жаль

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 15-Ноя-20 15:12 
Можно сделать, например, так (в PF):

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

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


"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Ivan_83 , 15-Ноя-20 20:09 
А можно почитать документацию к unbound и сделать чтобы он ходил по TCP и/или чтобы использовал name case (днс куки кажется) и тп.

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Всем Анонимам Аноним , 15-Ноя-20 20:09 
это будет работать на домашнем сервере, а на больших нагрузках conntrack выключен. там еще какие-то были фишки, не помню уже. даже nat просто модуль загруженный уже как-то влиял на производительность, если не ошибаюсь.

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено пох. , 16-Ноя-20 12:37 
Если у тебя, васян, рекурсивный кэширующий намед - это "большая нагрузка", что аж conntrack в iptables (не дерьмо-nft, а обычных, in-kernel без всяких чудо-трансляций в чудо-язычки), требуется выключать - тебе следует сменить профессию.
В выгульщики собак, пожалуйста, не ходи - это не твое. Там тоже мозги нужны, а то еще и укусят.

Вот, к примеру, "оператор уборочной машины" - востребованная и нужная профессия (только к собеседованию получше подготовься, а то ж могут подумать что и полотер сломаешь, с такими-то умениями)


"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Всем Анонимам Аноним , 16-Ноя-20 18:04 
Ой, какой же ты умный, и как ты мозг свой не забыл даже упомянуть. Да ты просто супер профессионал.
Извини, правда вакансий на наш сервис, обслуживающий 10% интернет трафика пока нет для такого супер ума.

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено пох. , 17-Ноя-20 09:41 
> Извини, правда вакансий на наш сервис, обслуживающий 10% интернет трафика

что ж ты такой скромный, васян, и название чудо-сервиса рашкованцев, обслуживающего аж 10% траффика аж всего интернета (!) не назвал, те у кого есть мозги поржали бы.

> пока нет для такого супер ума.

да, там похоже только ди6илы и нужны.

Главное верь, что у тебя там ажно 10%, а не 0.01 (впрочем, и это вряд ли).


"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Ivan_83 , 15-Ноя-20 20:07 
Всё бы вам костылить через фаервол, вместо того чтобы реально что то исправлять.

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Ivan_83 , 15-Ноя-20 20:24 
И да, специально для таких любителей костылей как вы я ещё раз напишу.

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


"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 15-Ноя-20 21:59 
А если правительство требует заворачивать трафик на 8.8.8.8 и 1.1.1.1 на свои сервера, то ваши пляски с фаерволами выглядят смешно, неуместно! У нас снемцами просто проблемы разные :)

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Ivan_83 , 15-Ноя-20 22:07 
Мы тут обсуждали DNS а не особенности местной политики.

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 16-Ноя-20 00:15 
Вы, это Николай Второй? А подмена ДНС серверов, это не особенность - это местное правило?

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 16-Ноя-20 00:34 
Но сначала он должен послать запросы вам со своего 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 кусок сети и перебирают все порты..)


"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено InuYasha , 15-Ноя-20 12:29 
М-да, хитро. Есть даже мысль как можно этот перебор портов оптимизировать (хотя, на практике, наверное, уже всё так и сделали).
Давно пора уже S2S-соединения обезопашивать. )

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Ivan_83 , 15-Ноя-20 20:10 
Хакер и столовая.

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено InuYasha , 16-Ноя-20 13:53 
> Хакер и столовая.

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


"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Ivan_83 , 17-Ноя-20 07:11 
Суть в том, что можно этой фигнёй страдать, да толку нынче мало.
И сама атака мягко говоря тоже малорезультативная.
И митигировать её просто.

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Sw00p aka Jerom , 15-Ноя-20 13:31 
а как же blackhole?

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 15-Ноя-20 13:44 
Такая фича удалена, так как это звучит не толерантно. А вы приговариваетесь к смертной казни за разжигание межрасовый неприязни.

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 15-Ноя-20 13:38 
2^16+2^16 == 2*2^16 == 2^17

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено одним словом , 15-Ноя-20 14:11 
умножить
ибо для каждого порта, брат аноним

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено leibniz , 15-Ноя-20 14:54 
2^1 чашки чего-нибудь этому анониму

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Lex , 15-Ноя-20 15:14 
Выфселжете! Уязвимости есть только в npm и его пакетах!!111

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено anoname , 15-Ноя-20 15:52 
Да, сравнивать зеленое с кислым - любимое занятие анонима опеннета.

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 15-Ноя-20 15:46 
> В качестве обходных путей защиты можно временно отключить отправку ICMP-пакетов, изменить значение rate-лимита и таймаута в сетевом стеке, а также использовать DNSSEC или DNS cookie.

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


"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 15-Ноя-20 15:52 
А какова ситация с DNSSEC?

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Сейд , 15-Ноя-20 18:36 
DNSSEC защищает от этой атаки.

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено microsoft , 15-Ноя-20 18:54 
Точно защищает?

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Сейд , 15-Ноя-20 19:08 
И да, и нет, сервер должен реализовать строгую проверку DNSSEC (т. е. отклонить ответы, которые нарушают цепочку доверия), чтобы предотвратить атаку. Однако, поскольку DNSSEC всё ещё находится в стадии распространения, серверы вынуждены принимать такие ответы при посещении неправильно настроенного домена.

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 16-Ноя-20 10:03 
Эоотможно исправить только одним способом - отключить неправильно настроенные домены от DNS. Если всё и так работает, то админы и не почешутся исправить.

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 15-Ноя-20 19:37 
Верните Балмера!

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Ivan_83 , 15-Ноя-20 20:20 
Он как и раньше не нужен.
Более того, если бы производители днс серверов реально были обеспокоены этим, то они бы ввели явное DNS cookie или nonce в протокол уже давным давно.
Суть в том, что сервер обязан был бы включать в ответ какое то поле пришедшее с запросом, а его сможно сделать хоть 32 бита хоть 32 байта, рандом естессно, и после этого уже бесполезно что то пытатся подобрать.

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

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

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


"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 15-Ноя-20 22:09 
>lets encrypt и вся эта движуха с сертификатами и https везде - это всё не про вашу безопасность, это про тотальный контроль интернета и централизацию управления.

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



"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Ivan_83 , 15-Ноя-20 23:44 
Вы чего то не понимаете.

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

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

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

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

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


"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 16-Ноя-20 10:00 
Дело в том, что сам браузер менять не надо. Нужно обращаться к DNS не напрямую, а через локальный прокси, который сам уже будет разговаривать проверять OpenPGP и разговаривать с блокчейном и т.д. Так я пользуюсь DNSCrypt, хотя его сайты из коробки не поддерживают, всё идёт через чужие сервера.

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


"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Ivan_83 , 17-Ноя-20 07:13 
Можно, только это путь в никуда, как и всякие альтернативные днс системы.

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено АнониМММ , 17-Ноя-20 20:25 
https://hub.docker.com/r/jedisct1/dnscrypt-server

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


"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено пох. , 16-Ноя-20 00:41 
> Он как и раньше не нужен.

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

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

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

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


"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 16-Ноя-20 10:01 
Это не защитит от поддельных ответов со стороны DNS-сервера.

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 16-Ноя-20 11:05 
> напомнить, сколько remote code exec в нем находят каждый год?

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


"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Sw00p aka Jerom , 16-Ноя-20 13:01 
SIGRed CVE-2020-1350

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 16-Ноя-20 21:26 
Вынь-дос-сервер? Познавательно, но хотелось бы чего-нибудь более жизненного. И ежегодного, как было обещано.

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 15-Ноя-20 19:58 
D SAD NS

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Аноним , 16-Ноя-20 04:10 
DNSCrypt

"Атака SAD DNS для подстановки фиктивных данных в кэш DNS"
Отправлено Michael Shigorin , 16-Ноя-20 13:06 
> DNSCrypt

#33