ДнсПук. Уязвимости в Dnsmasq, позволяющие подменить содержимое в кэше DNS

В пакете 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. Статус устранения проблем в дистрибутивах можно оценить на данных страницах: Debian, OpenWRT, SUSE, Ubuntu, RHEL, Fedora, Arch, FreeBSD.

Так как культура обновления беспроводных маршрутизаторов оставляет желать лучшего, исследователи опасаются, что выявленные проблемы могут долго оставаться неисправленными и будут вовлечены в проведение автоматизированных атак на маршрутизаторы для получения контроля за ними или для перенаправления пользователей на подставные вредоносные сайты. Всего сообщается о примерно 40 компаниях, выпускающих продукты с Dnsmasq, включая Cisco, Comcast, Netgear, Ubiquiti, Siemens, Technicolor, Aruba, Wind River, Asus, AT&T, D-Link, Huawei, Juniper, Motorola, Synology, Xiaomi, ZTE и Zyxel. Пользователям подобных устройств можно рекомендовать не использовать предоставляемый в них штатный сервис перенаправления запросов DNS.

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

Выявленные уязвимости снижают уровень энтропии с ожидаемых 32 бит до необходимости угадать 19 бит, что делает атаку по отравлению кэша вполне реалистичной. Кроме того, особенности обработки записей CNAME в dnsmasq позволяют применять спуфинг цепочки записей CNAME для эффективной подмены разом до 9 DNS-записей.

CVE-2020-25684 - отсутствие проверки идентификатора запроса в комбинации с IP-адресом и номером порта при обработке DNS-ответов от внешних серверов. Подобное поведение не соответствует требованиям RFC-5452, предписывающим использование дополнительных атрибутов запроса при его сопоставлении с ответом.
CVE-2020-25686 - отсутствие проверки ожидающих обработки запросов с тем же именем, что позволяет применить метод "дней рождения" для существенного снижения числа попыток, необходимых для подделки ответа. В сочетании с уязвимостью CVE-2020-25684, указанная особенность позволяет значительно снизить сложность проведения атаки.
CVE-2020-25685 - использование ненадёжного алгоритма хэширования CRC32 при проверке ответов, в случае сборки без DNSSEC (с DNSSEC применяется SHA-1). Уязвимость может применяться для значительного снижения числа попыток, благодаря возможности использовать домены, имеющие тот же хэш CRC32, что и у целевого домена.

Вторая часть проблем (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).