Suicide
20.01.2021, 21:34
В пакете Dnsmasq (http://www.thekelleys.org.uk/dnsmasq/doc.html), объединяющем кэширующий DNS-резолвер и сервер DHCP, выявлено 7 уязвимостей (https://kb.cert.org/vuls/id/434904), которым присвоено кодовое имя DNSpooq (https://www.jsof-tech.com/disclosures/dnspooq/). Проблемы позволяют осуществить атаки по подстановке фиктивных данных в кэш DNS или вызвать переполнение буфера, потенциально способное (https://access.redhat.com/security/vulnerabilities/RHSB-2021-001) привести к удалённому выполнению кода атакующего. Уязвимости устранены (http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014599.html) в сегодняшнем обновлении Dnsmasq 2.83. В качестве обходных путей защиты рекомендуется отключить DNSSEC и кэширование запросов при помощи опций командной строки "--dnssec" и "--cache-size=0" или настроек "dnssec" (нужно закомментировать) и "cache-size=0" в файле конфигурации dnsmasq.conf (https://github.com/imp/dnsmasq/blob/master/dnsmasq.conf.example).
Несмотря на то, что Dnsmasq последнее время перестал применяться по умолчанию в качестве резолвера в обычных дистрибутивах Linux, он продолжает использоваться в Android (https://android.googlesource.com/platform/external/dnsmasq/+/68a974de72b5091ce608815a349daaeb05cdeab5/FAQ) и специализированных дистрибутивах, таких как OpenWrt и DD-WRT, а также в прошивках беспроводных маршрутизаторов многих производителей. В обычных дистрибутивах не исключено неявное применение dnsmasq, например, при использовании libvirt он может запускаться для обеспечения работы DNS-сервиса в виртуальных машинах или может активироваться при изменении настроек в конфигураторе NetworkManager. Статус устранения проблем в дистрибутивах можно оценить на данных страницах: Debian (https://security-tracker.debian.org/tracker/source-package/dnsmasq), OpenWRT (https://openwrt.org/advisory/2021-01-19-1), SUSE (https://www.suse.com/security/cve/CVE-2020-25681/), Ubuntu (https://ubuntu.com/security/CVE-2020-25681), RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-25681), Fedora (https://bodhi.fedoraproject.org/updates/?releases=F33&type=security), Arch (https://security.archlinux.org/CVE-2020-25681), FreeBSD (https://www.freshports.org/dns/dnsmasq/).
Так как культура обновления беспроводных маршрутизаторов оставляет желать лучшего, исследователи опасаются, что выявленные проблемы могут долго оставаться неисправленными и будут вовлечены в проведение автоматизированных атак на маршрутизаторы для получения контроля над ними или для перенаправления пользователей на подставные вредоносные сайты. Всего сообщается о примерно 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, основанных на методе, предложенном (https://www.opennet.ru/opennews/art.shtml?num=16872) в 2008 году Дэном Камински (Dan Kaminsky). Выявленные проблемы делают имеющуюся защиту неэффективной и позволяют подменить IP-адрес произвольного домена в кэше. Метод Каминского манипулирует незначительным размером поля с идентификационным номером запроса DNS, который составляет всего 16 бит. Для подбора корректного идентификатора, необходимого для спуфинга имени хоста, достаточно отправить примерно 7000 запросов и симулировать около 140 тысяч фиктивных ответов. Атака сводится к отправке на DNS-резолвер большого числа пакетов с фиктивной привязкой к IP и с разными идентификаторами DNS-транзакции.
Выявленные уязвимости снижают (https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq_Technical-Whitepaper.pdf) уровень энтропии с ожидаемых 32 бит до необходимости угадать 19 бит, что делает атаку по отравлению кэша вполне реалистичной. Кроме того, особенности обработки записей CNAME в dnsmasq позволяют применять спуфинг цепочки записей CNAME для эффективной подмены разом до 9 DNS-записей.
CVE-2020-25684 - отсутствие проверки идентификатора запроса в комбинации с IP-адресом и номером порта при обработке DNS-ответов от внешних серверов. Подобное поведение не соответствует требованиям RFC-5452, предписывающим использование дополнительных атрибутов запроса при его сопоставлении с ответом.
CVE-2020-25686 - отсутствие проверки ожидающих обработки запросов с тем же именем, что позволяет применить метод "дней рождения (https://ru.wikipedia.org/wiki/%D0%90%D1%82%D0%B0%D0%BA%D0%B0_%C2%AB%D0%B4%D0%BD% D0%B5%D0%B9_%D1%80%D0%BE%D0%B6%D0%B4%D0%B5%D0%BD%D 0%B8%D1%8F%C2%BB)" для существенного снижения числа попыток, необходимых для подделки ответа. В сочетании с уязвимостью CVE-2020-25684, указанная особенность позволяет значительно снизить сложность проведения атаки.
CVE-2020-25685 - использование ненадёжного алгоритма хэширования CRC32 при проверке ответов, в случае сборки без DNSSEC (с DNSSEC применяется SHA-1). Уязвимость может применяться для значительного снижения числа попыток, благодаря возможности использовать домены, имеющие тот же хэш CRC32, что и у целевого домена.https://www.opennet.ru/opennews/pics_base/0_1611138157.png (https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq_Technical-Whitepaper.pdf)
Вторая часть проблем (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, но проблемы проявляются (https://access.redhat.com/security/vulnerabilities/RHSB-2021-001) в пакете для RHEL 8, который собран с DNSSEC.
Для эксплуатации уязвимостей требуется совершение действий со стороны клиента - атакующий каким-то образом должен вынудить пользователя отправить к dnsmasq специально оформленные запросы, в которых фигурирует подконтрольный атакующему домен. Выделяется четыре основных сценария атаки:
Атаки на открытые резолверы, принимающие запросы извне.https://www.opennet.ru/opennews/pics_base/0_1611138322.png
Атаки на корпоративные сети с привлечением внутреннего злоумышленника, имеющего доступ к сети, или через компрометацию незащищённого устройства/пользователя во внутренней сети.https://www.opennet.ru/opennews/pics_base/0_1611138299.png
Атаки на открытые беспроводные сети.
Атаки с привлечением web-браузера для трансляции запросов к внутреннему резолверу при открытии жертвой специально подготовленной страницы или при просмотре вредоносной рекламы на обычном сайте (запросы могут генерироваться через JavaScript, по аналогии с атаками NAT slipstreaming (https://www.opennet.ru/opennews/art.shtml?num=54058) и Cable Haunt (https://www.opennet.ru/opennews/art.shtml?num=52169)). К счастью, проведение подобных атак существенно сложнее и возможно не во всех браузерах (например, атаку удалось провести в Safari на iPhone, но метод не сработал в Chrome).https://www.opennet.ru/opennews/pics_base/0_1611138281.png
20.01.2021
https://www.opennet.ru/opennews/art.shtml?num=54436
Несмотря на то, что Dnsmasq последнее время перестал применяться по умолчанию в качестве резолвера в обычных дистрибутивах Linux, он продолжает использоваться в Android (https://android.googlesource.com/platform/external/dnsmasq/+/68a974de72b5091ce608815a349daaeb05cdeab5/FAQ) и специализированных дистрибутивах, таких как OpenWrt и DD-WRT, а также в прошивках беспроводных маршрутизаторов многих производителей. В обычных дистрибутивах не исключено неявное применение dnsmasq, например, при использовании libvirt он может запускаться для обеспечения работы DNS-сервиса в виртуальных машинах или может активироваться при изменении настроек в конфигураторе NetworkManager. Статус устранения проблем в дистрибутивах можно оценить на данных страницах: Debian (https://security-tracker.debian.org/tracker/source-package/dnsmasq), OpenWRT (https://openwrt.org/advisory/2021-01-19-1), SUSE (https://www.suse.com/security/cve/CVE-2020-25681/), Ubuntu (https://ubuntu.com/security/CVE-2020-25681), RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-25681), Fedora (https://bodhi.fedoraproject.org/updates/?releases=F33&type=security), Arch (https://security.archlinux.org/CVE-2020-25681), FreeBSD (https://www.freshports.org/dns/dnsmasq/).
Так как культура обновления беспроводных маршрутизаторов оставляет желать лучшего, исследователи опасаются, что выявленные проблемы могут долго оставаться неисправленными и будут вовлечены в проведение автоматизированных атак на маршрутизаторы для получения контроля над ними или для перенаправления пользователей на подставные вредоносные сайты. Всего сообщается о примерно 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, основанных на методе, предложенном (https://www.opennet.ru/opennews/art.shtml?num=16872) в 2008 году Дэном Камински (Dan Kaminsky). Выявленные проблемы делают имеющуюся защиту неэффективной и позволяют подменить IP-адрес произвольного домена в кэше. Метод Каминского манипулирует незначительным размером поля с идентификационным номером запроса DNS, который составляет всего 16 бит. Для подбора корректного идентификатора, необходимого для спуфинга имени хоста, достаточно отправить примерно 7000 запросов и симулировать около 140 тысяч фиктивных ответов. Атака сводится к отправке на DNS-резолвер большого числа пакетов с фиктивной привязкой к IP и с разными идентификаторами DNS-транзакции.
Выявленные уязвимости снижают (https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq_Technical-Whitepaper.pdf) уровень энтропии с ожидаемых 32 бит до необходимости угадать 19 бит, что делает атаку по отравлению кэша вполне реалистичной. Кроме того, особенности обработки записей CNAME в dnsmasq позволяют применять спуфинг цепочки записей CNAME для эффективной подмены разом до 9 DNS-записей.
CVE-2020-25684 - отсутствие проверки идентификатора запроса в комбинации с IP-адресом и номером порта при обработке DNS-ответов от внешних серверов. Подобное поведение не соответствует требованиям RFC-5452, предписывающим использование дополнительных атрибутов запроса при его сопоставлении с ответом.
CVE-2020-25686 - отсутствие проверки ожидающих обработки запросов с тем же именем, что позволяет применить метод "дней рождения (https://ru.wikipedia.org/wiki/%D0%90%D1%82%D0%B0%D0%BA%D0%B0_%C2%AB%D0%B4%D0%BD% D0%B5%D0%B9_%D1%80%D0%BE%D0%B6%D0%B4%D0%B5%D0%BD%D 0%B8%D1%8F%C2%BB)" для существенного снижения числа попыток, необходимых для подделки ответа. В сочетании с уязвимостью CVE-2020-25684, указанная особенность позволяет значительно снизить сложность проведения атаки.
CVE-2020-25685 - использование ненадёжного алгоритма хэширования CRC32 при проверке ответов, в случае сборки без DNSSEC (с DNSSEC применяется SHA-1). Уязвимость может применяться для значительного снижения числа попыток, благодаря возможности использовать домены, имеющие тот же хэш CRC32, что и у целевого домена.https://www.opennet.ru/opennews/pics_base/0_1611138157.png (https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq_Technical-Whitepaper.pdf)
Вторая часть проблем (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, но проблемы проявляются (https://access.redhat.com/security/vulnerabilities/RHSB-2021-001) в пакете для RHEL 8, который собран с DNSSEC.
Для эксплуатации уязвимостей требуется совершение действий со стороны клиента - атакующий каким-то образом должен вынудить пользователя отправить к dnsmasq специально оформленные запросы, в которых фигурирует подконтрольный атакующему домен. Выделяется четыре основных сценария атаки:
Атаки на открытые резолверы, принимающие запросы извне.https://www.opennet.ru/opennews/pics_base/0_1611138322.png
Атаки на корпоративные сети с привлечением внутреннего злоумышленника, имеющего доступ к сети, или через компрометацию незащищённого устройства/пользователя во внутренней сети.https://www.opennet.ru/opennews/pics_base/0_1611138299.png
Атаки на открытые беспроводные сети.
Атаки с привлечением web-браузера для трансляции запросов к внутреннему резолверу при открытии жертвой специально подготовленной страницы или при просмотре вредоносной рекламы на обычном сайте (запросы могут генерироваться через JavaScript, по аналогии с атаками NAT slipstreaming (https://www.opennet.ru/opennews/art.shtml?num=54058) и Cable Haunt (https://www.opennet.ru/opennews/art.shtml?num=52169)). К счастью, проведение подобных атак существенно сложнее и возможно не во всех браузерах (например, атаку удалось провести в Safari на iPhone, но метод не сработал в Chrome).https://www.opennet.ru/opennews/pics_base/0_1611138281.png
20.01.2021
https://www.opennet.ru/opennews/art.shtml?num=54436