Опасная уязвимость в DNS-сервере BIND

Опасная уязвимость в DNS-сервере BIND

Организация ISC выпустила экстренные обновления DNS-сервера BIND с устранением уязвимости (CVE-2013-4854), позволяющей инициировать крах процесса named через отправку запроса со специально оформленным содержимым поля RDATA. Уязвимости подвержены как рекурсивные, так и авторитетные серверы. Ограничение доступа через ACL не позволяет защититься от проблемы, помочь может только ограничение доступа к сетевому порту на уровне пакетного фильтра. Проблема усугубляется тем, что информация о методе эксплуатации появилась в Сети до выхода исправления и несколько компаний зафиксировали применения уязвимости для атаки на DNS-серверы.

В настоящий момент уязвимость уже исправлена в выпусках BIND 9.9.3-P2 и 9.8.5-P2, все остальные версии BIND 9, новее ветки 9.6, подвержены атаке. Для BIND 9.7 официальное исправление не выпущено, так как время поддержки данной ветки прекращено, тем не менее уже доступно обновление пакетов с BIND 9.7 для Debian. Аналогичное обновление также выпустил проект FreeBSD. RHEL/CentOS, Fedora, SUSE, openSUSE, Ubuntu и другие дистрибутивы Linux обновления на момент написания новости ещё не выпустили, сообщает opennet.ru.

Отдельно можно отметить объявление о добавлении в состав будущих выпусков BIND модуля RRL, предоставляющий эффективный механизм для защиты от проведения DDoS-атак с использованием DNS. Речь ведётся не об атаках, направленных на выведение из строя DNS-сервера, а об использовании DNS-серверов для атак на другие системы. Пользуясь тем, что ответ DNS-сервера превышает по размеру DNS-запрос, путем отправки запросов с указанием фиктивного обратного адреса, в качестве которого указан IP жертвы, создаётся волна трафика из обратных ответов (исходный трафик приумножается примерно в 100 раз).

Во втором квартале 2013 года частота проведения подобных атак возросла на 20%. При этом в среднем при каждой такой DDoS атаке генерируется трафик порядка 50 млн пакетов в секунду. RRL является способом справиться с проблемой на стороне DNS-серверов, давая возможность администраторам установить лимит на интенсивность отправки ответов в привязке к адресу получателя (заданные через RRL ограничения действуют только на исходящие запросы и не влияют на входящие). Модуль RRL добавляет поддержку директивы responses-per-second в блок rate-limit, позволяющей задать допустимое число ответов в секунду. 

Android-приложения научились обходить блокировку трафика вне VPN

Исследователь Армин Шупук обнаружил в Android механизм, позволяющий обычному приложению отправлять пакеты мимо VPN даже при включённой функции «Блокировать соединения без VPN». Никакого root-доступа, ADB и опасных разрешений не требуется — достаточно штатного системного API.

Проблема связана с NAT-T keepalive — короткими пакетами UDP/4500, которые поддерживают сетевое соединение активным. Android может поручить их отправку чипу Wi-Fi, минуя обычный сетевой путь приложения и проверки VPN Lockdown.

В результате установленная программа способна регулярно обращаться к выбранному злоумышленником серверу через физическую сеть. Передавать произвольные данные таким способом нельзя: содержимое пакета задаёт сама платформа.

Однако получатель видит реальный IP-адрес устройства, время отправки и факт его присутствия в сети. Этого достаточно для определения провайдера, сопоставления активности и отслеживания перемещений между сетями.

Исследователь подтвердил утечку на Pixel 8 Pro с Android 16: роутер фиксировал пакет вне VPN каждые десять секунд. На смартфоне Samsung соединение оставалось активным более 24 часов. Работа механизма также подтверждена на устройстве Nothing, хотя отдельный перехват трафика для него не проводился.

По оценке автора, проблема затрагивает большинство устройств на Android 12 и новее, поддерживающих аппаратную отправку NAT-T keepalive через Wi-Fi. Однако полноценные испытания выполнены только на трёх моделях, поэтому речь идёт об оценке класса устройств, а не о проверке каждого смартфона на рынке.

Отчёт передали Google 15 мая 2026 года. Корпорация признала его дубликатом уже зарегистрированной проблемы, но сведения о CVE, исправлении или сроках выпуска патча публично не раскрыты.

До устранения ошибки пользователям с повышенными требованиями к анонимности рекомендуют пропускать весь трафик смартфона через внешний VPN-маршрутизатор, отключив мобильную сеть и альтернативные подключения.

RSS: Новости на портале Anti-Malware.ru