Несмотря на то, что 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.
Первая часть обнаруженных уязвимостей в Dnsmasq затрагивает защиту от атак по отравлению кэша 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).
Источник: http://www.opennet.ru/opennews/art.shtml?num=54436