Suicide
04.05.2022, 20:58
В стандартных Си-библиотеках uClibc (https://www.uclibc.org/) и uClibc-ng (https://uclibc-ng.org/), применяемых во многих встраиваемых и портативных устройствах, выявлена (https://www.nozominetworks.com/blog/nozomi-networks-discovers-unpatched-dns-bug-in-popular-c-standard-library-putting-iot-at-risk/) уязвимость (CVE не присвоен), позволяющая подставить фиктивные данные в кэш DNS, что можно использовать для подмены в кэше IP-адреса произвольного домена и перенаправления обращений к домену на сервер злоумышленника.
Проблема затрагивает различные Linux-прошивки для маршрутизаторов, точек доступа и устройств интернета-вещей, а также Linux-дистрибутивы для встраиваемых систем, такие как OpenWRT и Embedded Gentoo. Отмечается, что уязвимость проявляется в устройствах многих производителей (например, uClibc используется (https://uclibc.org/products.html) в прошивках Linksys, Netgear и Axis), но так как в uClibc и uClibc-ng уязвимость остаётся неисправленной, детальные сведения о конкретных устройствах и производителях, в продуктах которых присутствует проблема, пока не разглашаются.
Уязвимость вызвана использованием в коде отправки DNS-запросов предсказуемых идентификаторов транзакции. Идентификационный номер запроса DNS выбирался путём простого увеличения счётчика без применения дополнительной рандомизации номеров портов, что позволяло добиться отравления кэша DNS через упреждающую отправку UDP-пакетов с фиктивными ответами (ответ будет принят, если он пришёл раньше ответа реального сервера и включает корректный ID). В отличие от предложенного (https://www.opennet.ru/opennews/art.shtml?num=16872) в 2008 году метода Каминского, идентификатор транзакции даже не нужно угадывать, так как он изначально предсказуем (вначале выставляется значение 1, которое при каждом запросе увеличивается, а не выбирается случайным образом).
https://www.opennet.ru/opennews/pics_base/0_1651663787.jpg (https://www.nozominetworks.com/wp-content/uploads/2022/04/Figure-4-DNS-lookup-function.jpg)
В спецификации для защиты от подбора идентификатора рекомендуется дополнительно применять случайное распределение номеров исходных сетевых портов, с которых отправляются DNS-запросы, что компенсирует недостаточно большой размер идентификатора. При включении рандомизации портов для формирования фиктивного ответа кроме подбора 16 битного идентификатора необходимо подобрать и номер сетевого порта. В uClibc и uClibc-ng подобная рандомизация не включалась явно (при вызове bind не указывался случайный исходный UDP порт) и её применение зависело от настроек операционной системы.
При отключении рандомизации портов определение инкриментируемого идентификатора запроса отмечается как тривиальная задача. Но даже в случае применения рандомизации, атакующему необходимо лишь угадать сетевой порт из диапазона 32768–60999, для чего можно использовать массированную одновременную отправку фиктивных ответов по разным сетевым портам.
https://www.opennet.ru/opennews/pics_base/0_1651663764.jpg (https://www.nozominetworks.com/wp-content/uploads/2022/04/Figure-2-Trace-of-DNS-requests.jpg)
Наличие проблемы подтверждено во всех актуальных выпусках uClibc и uClibc-ng, включая самые свежие версии uClibc 0.9.33.2 и uClibc-ng 1.0.40. В сентябре 2021 года информация об уязвимости была отправлена в CERT/CC для согласованной подготовки исправлений. В январе 2022 года данные о проблеме были переданы более 200 производителям, сотрудничающим с CERT/CC. В марте была попытка отдельно связаться с сопровождающим проект uClibc-ng, но он ответил, что не в состоянии исправить уязвимость самостоятельно и рекомендовал публично раскрыть информацию о проблеме, рассчитывая получить помощь в разработке исправления от сообщества. Из производителей о выпуске обновления с устранением уязвимости объявил NETGEAR (https://kb.netgear.com/000064894/Security-Advisory-for-a-Disclosure-on-a-Vulnerability-in-the-uClibc-and-uClibc-ng-Embedded-C-Libraries-on-Some-Products-PSV-2022-0017).
4.05.2022
https://www.opennet.ru/opennews/art.shtml?num=57131
Проблема затрагивает различные Linux-прошивки для маршрутизаторов, точек доступа и устройств интернета-вещей, а также Linux-дистрибутивы для встраиваемых систем, такие как OpenWRT и Embedded Gentoo. Отмечается, что уязвимость проявляется в устройствах многих производителей (например, uClibc используется (https://uclibc.org/products.html) в прошивках Linksys, Netgear и Axis), но так как в uClibc и uClibc-ng уязвимость остаётся неисправленной, детальные сведения о конкретных устройствах и производителях, в продуктах которых присутствует проблема, пока не разглашаются.
Уязвимость вызвана использованием в коде отправки DNS-запросов предсказуемых идентификаторов транзакции. Идентификационный номер запроса DNS выбирался путём простого увеличения счётчика без применения дополнительной рандомизации номеров портов, что позволяло добиться отравления кэша DNS через упреждающую отправку UDP-пакетов с фиктивными ответами (ответ будет принят, если он пришёл раньше ответа реального сервера и включает корректный ID). В отличие от предложенного (https://www.opennet.ru/opennews/art.shtml?num=16872) в 2008 году метода Каминского, идентификатор транзакции даже не нужно угадывать, так как он изначально предсказуем (вначале выставляется значение 1, которое при каждом запросе увеличивается, а не выбирается случайным образом).
https://www.opennet.ru/opennews/pics_base/0_1651663787.jpg (https://www.nozominetworks.com/wp-content/uploads/2022/04/Figure-4-DNS-lookup-function.jpg)
В спецификации для защиты от подбора идентификатора рекомендуется дополнительно применять случайное распределение номеров исходных сетевых портов, с которых отправляются DNS-запросы, что компенсирует недостаточно большой размер идентификатора. При включении рандомизации портов для формирования фиктивного ответа кроме подбора 16 битного идентификатора необходимо подобрать и номер сетевого порта. В uClibc и uClibc-ng подобная рандомизация не включалась явно (при вызове bind не указывался случайный исходный UDP порт) и её применение зависело от настроек операционной системы.
При отключении рандомизации портов определение инкриментируемого идентификатора запроса отмечается как тривиальная задача. Но даже в случае применения рандомизации, атакующему необходимо лишь угадать сетевой порт из диапазона 32768–60999, для чего можно использовать массированную одновременную отправку фиктивных ответов по разным сетевым портам.
https://www.opennet.ru/opennews/pics_base/0_1651663764.jpg (https://www.nozominetworks.com/wp-content/uploads/2022/04/Figure-2-Trace-of-DNS-requests.jpg)
Наличие проблемы подтверждено во всех актуальных выпусках uClibc и uClibc-ng, включая самые свежие версии uClibc 0.9.33.2 и uClibc-ng 1.0.40. В сентябре 2021 года информация об уязвимости была отправлена в CERT/CC для согласованной подготовки исправлений. В январе 2022 года данные о проблеме были переданы более 200 производителям, сотрудничающим с CERT/CC. В марте была попытка отдельно связаться с сопровождающим проект uClibc-ng, но он ответил, что не в состоянии исправить уязвимость самостоятельно и рекомендовал публично раскрыть информацию о проблеме, рассчитывая получить помощь в разработке исправления от сообщества. Из производителей о выпуске обновления с устранением уязвимости объявил NETGEAR (https://kb.netgear.com/000064894/Security-Advisory-for-a-Disclosure-on-a-Vulnerability-in-the-uClibc-and-uClibc-ng-Embedded-C-Libraries-on-Some-Products-PSV-2022-0017).
4.05.2022
https://www.opennet.ru/opennews/art.shtml?num=57131