Уязвимости в Dnsmasq, позволяющие подменить содержимое в кэше DNS
20 января 2021 года
В пакете Dnsmasq, объединяющем кэширующий DNS-резолвер и сервер DHCP, выявлено 7 уязвимостей, которым присвоено кодовое имя DNSpooq. Проблемы позволяют осуществить атаки по подстановке фиктивных данных в кэш DNS или вызвать переполнение буфера, потенциально способное привести к удалённому выполнению кода атакующего. Уязвимости устранены в сегодняшнем обновлении Dnsmasq 2.83. В качестве обходных путей защиты рекомендуется отключить DNSSEC и кэширование запросов при помощи опций командной строки "--dnssec" и "--cache-size=0" или настроек "dnssec" (нужно закомментировать) и "cache-size=0" в файле конфигурации dnsmasq.conf.
Несмотря на то, что Dnsmasq последнее время перестал применяться по умолчанию в качестве резолвера в обычных дистрибутивах Linux, он продолжает использоваться в Android и специализированных дистрибутивах, таких как OpenWrt и DD-WRT, а также в прошивках беспроводных маршрутизаторов многих производителей. В обычных дистрибутивах dnsmasq может применяться неявно, например, при использовании libvirt может запускаться для обеспечения работы DNS-сервиса в виртуальных машинах или может активироваться при изменении настроек в конфигураторе NetworkManager.
Так как культура обновления беспроводных маршрутизаторов оставляет желать лучшего, выявившие проблемы исследователи опасаются, что выявленные проблемы могут долго оставаться неисправленными и использоваться в автоматизированных атаках на маршрутизаторы для получения контроля за ними или для перенаправления пользователей на подставные вредоносные сайты. Всего сообщается о примерно 40 компаниях, выпускающих продукты с Dnsmasq, включая Cisco, Comcast, Netgear, Ubiquiti, Siemens, Technicolor, Aruba, Wind River, Asus, AT&T, D-Link, Huawei, Juniper, Motorola, Synology, Xiaomi, ZTE и Zyxel.
Первая часть уязвимостей затрагивает защиту от атак по отравлению кэша DNS, основанных на методе, предложенном в 2008 году Дэном Камински (Dan Kaminsky). Выявленные проблемы делают имеющуюся защиту неэффективной и позволяют подменить IP-адрес произвольного домена в кэше. Метод Каминского манипулирует незначительным размером поля с идентификационным номером запроса DNS, который составляет всего 16 бит. Для подбора корректного идентификатора, необходимого для спуфинга имени хоста, достаточно отправить примерно 7000 запросов и симулировать около 140 тысяч фиктивных ответов. Атака сводится к отправке на DNS-резолвер большого числа пакетов с фиктивной привязкой к IP и с разными идентификаторами DNS-транзакции.
- CVE-2020-25684 - отсутствие проверки идентификатора запроса в комбинации с IP-адресом и номером порта при обработке DNS-ответов от внешних серверов. Подобное поведение не соответствует требованиям RFC-5452, предписывающим использование дополнительных атрибутов запроса при его сопоставлении с ответом.
- CVE-2020-25685 - использование ненадёжного алгоритма хэширования CRC32 при проверке ответов, в случае сборки без DNSSEC (с DNSSEC применяется SHA-1). Уязвимость может применяться для значительного снижения числа попыток, благодаря возможности использовать домены, имеющие тот же хэш CRC32, что и у целевого домена.
- CVE-2020-25686 - отсутствие проверки ожидающих обработки других запросов с тем же именем, что позволяет применить метод "дней рождения" для существенного снижения числа попыток, необходимых для подделки ответа. В сочетании с уязвимостью CVE-2020-25684, указанная особенность позволяет значительно снизить сложность проведения атаки.
Выявленные уязвимости снижают уровень энтропии с ожидаемых 32 бит до необходимости угадать 19 бит, что делает атаку по отравлению кэша вполне реалистичной. Кроме того, особенности обработки записей CNAME в dnsmasq позволяют применять спуфинг цепочки записей CNAME для эффективной подмены разом до 9 DNS-записей.
Вторая часть проблем (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683 и CVE-2020-25687) вызвана ошибками, приводящими к переполнению буфера при обработке определённых внешних данных. Для уязвимостей CVE-2020-25681 и CVE-2020-25682 не исключается создание эксплоитов, способных привести к выполнению кода в системе. Все отмеченные 4 уязвимости присутствуют в коде DNSSEC и проявляются только при включении в настройках проверки через DNSSEC. Например, пакет dnsmasq из состава RHEL 6 и 7 не подвержен данным уязвимостям, так как собран без поддержки DNSSEC, но проблемы проявляются в пакете для RHEL 8, который собран с DNSSEC.
Для эксплуатации уязвимостей требуется совершение действий со стороны клиента - атакующий каким-то образом должен вынудить пользователя отправить к dnsmasq специально оформленные запросы, в которых фигурирует подконтрольный атакующему домен. Выделяется четыре основных сценария атаки:
- Атаки на открытые резолверы, принимающие запросы извне.
- Атаки на корпоративные сети с привлечением внутреннего злоумышленника, имеющего доступ к сети, или через компрометацию незащищённого устройства/пользователя во внутренней сети.
- Атаки на открытые беспроводные сети.
- Атаки с привлечением web-браузера для трансляции запросов к внутреннему резолверу при открытии жертвой специально подготовленной страницы или при просмотре вредоносной рекламы на обычном сайте (запросы могут генерироваться через JavaScript, по аналогии с атаками NAT slipstreaming и Cable Haunt). К счастью, проведение подобных атак существенно сложнее и возможно не во всех браузерах (например, атаку удалось провести в Safari на iPhone, но метод не сработал в Chrome).
Источники
править
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.
