LINUX.ORG.RU

DNSpooq — семь новых уязвимостей в dnsmasq

 , ,


1

1

Специалисты из JSOF research labs сообщили о семи новых уязвимостях в DNS/DHCP сервере dnsmasq. Сервер dnsmasq весьма популярен и используется по умолчанию во многих дистрибутивах linux, а также в сетевом оборудовании Cisco, Ubiquiti и прочих. Уязвимости Dnspooq включают в себя отравление DNS-кэша, а также удаленное выполнение кода. Уязвимости исправлены в dnsmasq 2.83.

В 2008 году известный исследователь в области безопасности Дэн Каминский обнаружил и раскрыл фундаментальный недостаток механизма DNS в Интернете. Каминский доказал, что злоумышленники могут подменять адреса доменов и красть данные. С тех пор это стало известно как «Атака Каминского».

DNS считается небезопасным протоколом на протяжении десятилетий, хотя предполагается, что он гарантирует определенный уровень целостности. Именно по этой причине на него до сих пор сильно полагаются. В то же время были разработаны механизмы повышения безопасности исходного протокола DNS. Эти механизмы включают в себя HTTPS, HSTS, DNSSEC и другие инициативы. Тем не менее, даже при наличии всех этих механизмов, перехват DNS все равно является опасной атакой в 2021 году. Большая часть интернета все еще полагается на DNS так же, как и в 2008 году, и подвержена атакам того же типа.

Уязвимости отравления кэша DNSpooq: CVE-2020-25686, CVE-2020-25684, CVE-2020-25685. Эти уязвимости схожи с атаками SAD DNS, о которых недавно сообщали исследователи из Калифорнийского Университета и Университета Цинхуа. Уязвимости SAD DNS и DNSpooq также могут быть объединены для еще большего облегчения атак. О дополнительных атаках с неясными последствиями также сообщалось совместными усилиями университетов (Poison Over Troubled Forwarders и др.). Уязвимости работают за счет уменьшения энтропии. Из-за использования слабого хэша для идентификации DNS-запросов и неточного соответствия запроса ответу, энтропия может быть значительно уменьшена и нужно угадать только ~19 бит, что делает возможным отравление кэша. Способ, которым dnsmasq обрабатывает CNAME-записи, позволяет подделывать цепочку CNAME-записей и эффективно отравлять до 9 DNS-записей одновременно.

Уязвимости переполнения буфера: CVE-2020-25687, CVE-2020-25683, CVE-2020-25682, CVE-2020-25681. Все отмеченные 4 уязвимости присутствуют в коде с реализацией DNSSEC и проявляются только при включении в настройках проверки через DNSSEC.

>>> Подробности

★★★

Проверено: Shaman007 ()

Дык чё не придумают DNS рукопожатия как в https? Изи же.

А ещё есть хак, можно запросить ip у сразу несколькоих dns серверов перед основным запросом. И если вдруг один из них вернул иное чем все, то ууууууууу сука . (запрашивать по ip конечно явно, а у своего по dns адресу)

anonymous ()
Ответ на: комментарий от anonymous

А ещё есть хак, можно запросить ip у сразу несколькоих dns серверов перед основным запросом. И если вдруг один из них вернул иное чем все, то ууууууууу сука . (запрашивать по ip конечно явно, а у своего по dns адресу)

Уже есть TorDNS, работает как часы.

SM5T001 ()

Для тех кого интересует как максимально обезопасить DNS(лучше на данный момент ничего не придумано):

1. Берём и скачиваем Tor, нужен именно системный сервис. В дебиан это apt install tor.
2. Открываем /etc/tor/torrc и добавляем строчку DNSPort 53.
3. Теперь открываем /etc/resolv.conf, убираем всё и оставляем только nameserver 127.0.0.1
4. Дополнительно можно сделать sudo chattr +i /etc/resolv.conf, чтобы защитить файл от автоматических изменений.

Готово. DNS-запросы теперь пойдут через Tor, что фактически не позволит проводить целевую атаку на DNS-запросы. Кроме того, многие выходные узлы(именно через них проходят подобные DNS-запросы) на данный момент настроены на автоматическое копирование данных с DNS-серверов(и кеширование), что превращает эти узлы в автономные DNS-серверы.

Поскольку выходные узлы распределены по всей планете и сами по умолчанию используют данные разных DNS-серверов(как правило, это локальные серверы провайдера), на выходе мы получаем единственный на данный момент рабочий образец децентрализованного DNS.

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

SM5T001 ()
Ответ на: комментарий от LikeABoss

Выкинь все часы со всех своих машин, перезагрузи их и попробуй возразить мне ответным комментарием, а я посижу посмеюсь.

Спойлер: при таком подходе ответ на мой комментарий появится... НИКОГДА.

SM5T001 ()
Ответ на: комментарий от SM5T001

Вариант рабочий. Я даже на винде так делал. А все потому что Tor может поднять себя без изначально рабочего системного DNS сервера, короче айпишники только юзает для коннекта к тор сети.

Можно еще конечно dnscrypt, но его настраивать сложнее. Зато он быстрее, т.к. юзает UDP (шифрованный). Не очень дружит это все с openvpn, если адрес прописан не айпишником.

anonymous ()
Ответ на: комментарий от SM5T001

Уточню, что DNSPort 53 равносильно записи DNSPort 127.0.0.1:53, то есть Tor может быть DNS’ом и для локалки. Как собственно и socks прокси его может смотреть в локалку. Может, кому это пригодится.

anonymous ()
Ответ на: комментарий от SM5T001

/etc/resolv.conf скорее всего симлинк на всякую лабуду. И ты будешь редактировать лабуду, которая потом поменяется. Поэтому начала нужно сделать sudo rm /etc/resolv.conf а потом sudo nano /etc/resolv.conf и потом sudo chattr +i /etc/resolv.conf

resolv.conf дергают приложения network manager и resolvconf. Правильнее было бы, конечно, их укротить (удалить или задать одинаковые настройки). Но защита не помешает, без нее файл вскоре поменяется.

resolvconf кстати может еще вызываться из ovpn конфигов (только на deb системах). Есть также systemd-resolved
sudo systemctl disable systemd-resolved

anonymous ()
Ответ на: комментарий от SM5T001

Потому что надо бороться не с последствиями, а с причиной. Отключить службу, которая меняет содержимое, либо отключить изменение этого файла в той службе, которая это делает. Либо через interfaces или подобные конфиги задать нужный dns сервер.

as_lan ★★ ()
Ответ на: комментарий от anonymous

Не очень дружит это все с openvpn

А что не так с openvpn? Указываешь через --route-up скрипт, который будет перезапускать dnscrypt, чтобы тот заново установил соединение. Если я правильно понял проблему, конечно.

eve ()
Ответ на: комментарий от eve

В случае дисконнектов openvpn пытается заново установить соединение с vpn сервером. Если vpn сервер задан в виде домена, а не ip, openvpn будет разрешать это имя через системный DNS 127.0.0.1. Шлюз пока будет держаться, но адрес DNS’а (127.0.0.1) openvpn из шлюза временно вытащит. О том, что dns это некоторое приложение и ему для работы нужно обратится в интернет с других адресов, openvpn не знает. Tor или dnscrypt будут пытаться разрешить доменное имя, но они не достучатся до своих серверов, потому что маршрут идет через опенвпн’овский шлюз на котором нету интернета из-за дисконнекта. А чтобы дисконнект исчез надо разрешить доменное имя - замкнутый круг. openvpn такие ситуации отрабатывает в лучшем случае только для обычных dns, с внешним ip без всяких хитростей в виде приложений, которые лезут куда-то еще. Тут надо прописывать исключение для dns в маршруте openvpn, но только временно (что гемор, как это разруливать), иначе dns трафик пойдет мимо vpn, хоть он и шифрованный. Другое решение: указывать vpn серверы в конфиге в виде ip адресов, а не доменов. Недостаток в том, что айпишники меняются, старые отваливаются, появляются новые. Это надо самому следить за их актуальностью. Бывает так, что один из впн серверов (ip), которые ты юзал исключили из dns выдачи, но сервер по прежнему доступен, хоть тормозит и глючит, а ты его продолжаешь юзать. Например, у протона такая строчка nl-free-01.protonvpn.com и вот какие сервера ее обслуживают сейчас, согласно nslookup: 46.166.142.215, 46.166.142.214, 46.166.142.219, 46.166.142.220, 109.201.133.22, 109.201.133.24, 109.201.133.26. Кто знает какие из этих айпишников полягут и ты об этом не узнаешь.

anonymous ()
Ответ на: комментарий от anonymous

Может openvpn и разорвет шлюз, чем он таки часто грешит, но я не раз видел подобные висяки. Надо же еще чтобы dns проги продуплились. Тут правда у меня еще и модем исчезает из системы на время.

anonymous ()
Ответ на: комментарий от Harald

т.е. уязвимости из сабжа не связаны с кодом, т.е. там всё инструментально уже проверено? И остаются лишь алгоритмические уязвимости, которые невозможно проверить не вникая глубоко?

Уязвимости переполнения буфера

Однако в тексте темы всё таки присутствует тупейший тип уязвимостей, насколько можно судить

I-Love-Microsoft ★★★★★ ()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от as_lan

Чукча не читай, сразу отвечай.

All hostnames are constantly monitored for updates. In case the A, AAAA, CNAME and NS records return NXDOMAIN they will be marked as dead and removed. Domains are tested on their whois data and removed if they have been unregistered for a certain time.

post-factum ★★★★★ ()
Ответ на: комментарий от anonymous

Не очень дружит это все с openvpn, если адрес прописан не айпишником.

Тут больше проблема в том, что openvpn меняет таблицу маршрутизации. Нужно либо заранее добавлять исключения, вроде ip route add *адрес текущих сторожевых узлов* via *адрес маршрутизатора/шлюза*(можно добавить скрипт прямо в конфигурационный файл .ovpn), либо перезагружать tor, чтобы он переключился на ip-адрес VPN.

Ясное дело, если настраивать VPN поверх Tor(прописав в конфигурационный файл прокси), сработает только первый вариант, зато так будет UDP работать даже поверх Tor, естественно сам VPN должен быть настроен на работу через TCP.

Это отличный способ обходить блокировки Tor без потери анонимности. Я так даже википедию могу редактировать.

Второй же вариант сделает Tor через VPN — тоже может быть полезно в некоторых случаях.

SM5T001 ()
Ответ на: комментарий от as_lan

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

«Костыль» работает универсально, я им не призываю пользоваться бездумно, но если трогать настройки нельзя или нежелательно — сойдёт.

SM5T001 ()
Ответ на: комментарий от SM5T001

Я так даже википедию могу редактировать

Вивипедия позабанила все подряд. Не только тор, ВПН’ы, даже провайдерские айпишники, видите ли кто-то через них гадит. Мне теперь доступ перекрыт для редактирования полностью. Анально огороженный сайт. Да и смысл редактировать, если статьи массово сносят, придираясь к незнаничимости.

Deniska-Rediska ()
Ответ на: комментарий от Deniska-Rediska

Да, есть такое.

Что говорить, если там с конца нулевых сформировалась несменяемая тоталитарная секта операторов, жёстко «охраняющих границы», с примкнувшим к ним клоунажным комитетом. Я из числа тех, кто громко хлопнул дверью в те времена.

И тем не менее, как бы ни хотела(или хотела?) эта тоталитарная секта, википедия — СМИ, да не просто СМИ, а один из самых популярных источников информации, в том числе об актуальных событиях.

Но главное — ей активно зачитываются студенты, по многим причинам, в том числе из-за устаревших бумажных материалов. Хотя секта операторов в основном бдит за «политическими» статьями, скатывая их в качестве, даже относительно спокойный сегмент технических статей подвергается вандализму, а получающаяся на выходе «субстанция» в неизменном виде вливается в неокрепшие головы студентов.

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

А так да, стараюсь держаться в стороне от этого прогнившего насквозь проекта.

SM5T001 ()
Ответ на: комментарий от SM5T001

педивикия

про технические и т.п. - мне всё с ними стало понятно, когда я внёс поправку, что Ту-154 сняли с производства позже чем у них написано (сославшись при этом на оф.сайт завода). поправили тут же обратно. типа ибонефиг, доктор сказал в морг и всё такое. я её использую только для первоначального знакомства с материалом в т.ч. как каталог ссылок на тематические источники.

а то поулчается как с фразой Твена про выборы. бгг

mumpster ★★★★★ ()
Ответ на: Решето от anonymous

/etc/dnsmasq.conf

да ладно?

If you want dnsmasq to listen for DHCP and DNS requests only on

specified interfaces (and the loopback) give the name of the

interface (eg eth0) here.

Repeat the line for more than one interface.

mumpster ★★★★★ ()