Internet Systems Consortium (ISC) оприлюднила планові оновлення для BIND 9, які виправляють три значущі уразливості у модулі резолвера. Дві з них створюють умови для отруєння кешу DNS, ще одна дозволяє спричинити відмову в обслуговуванні. Патчі доступні у гілках 9.18.41, 9.20.15 і 9.21.14; для комерційної редакції BIND Supported Preview Edition — 9.18.41‑S1 і 9.20.15‑S1. Адміністраторам слід оновитися негайно.
Три уразливості в BIND 9: деталі та вплив
CVE-2025-40780 (CVSS 8.6): прогнозованість порту й TXID знижує стійкість до cache poisoning
Помилка у генераторі псевдовипадкових чисел призводила до ситуацій, коли можна було передбачити вихідний UDP‑порт і ідентифікатор транзакції (TXID) у рекурсивних DNS‑запитах. Це послаблює захист, впроваджений після відомого інциденту Дена Камінскі (2008), коли рандомізація портів стала ключовим бар’єром проти підміни відповідей. За точного таймінгу та мережевого спуфінгу зловмисник може нав’язати фальшивий запис у кеші резолвера.
CVE-2025-40778 (CVSS 8.6): надто лояльна обробка відповідей дозволяє ін’єкцію записів
Резолвер недостатньо строго перевіряв ресурсні записи, отримані у відповідях. Це відкривало можливість впровадження підроблених записів безпосередньо в кеш, що впливає на результати резолвінгу для всіх клієнтів, які використовують даний сервер.
CVE-2025-8677 (CVSS 7.5): відмова в обслуговуванні через некоректні DNSKEY
Спеціально сформовані й некоректні DNSKEY у відповідях на запити до зони могли викликати аномально високе навантаження на CPU, що призводить до деградації продуктивності або тимчасової недоступності сервісу.
Кого зачіпає та як оцінити ризик
Уразливості стосуються насамперед рекурсивних DNS‑серверів (резолверів). Авторитативні сервери, що обслуговують власні зони, не підпадають під ці проблеми. За оцінкою експертів Red Hat, експлуатація CVE-2025-40780 є нетривіальною і потребує точного спуфінгу та синхронізації; при цьому порушується цілісність кешу, але не відбувається повна компрометація сервера.
Частина галузевих контролів залишається ефективною: DNSSEC‑валідація блокує більшість сценаріїв cache poisoning, rate limiting зменшує ефект зловживань, а коректна антиспуфінг‑фільтрація на периметрі (BCP 38/84) звужує поверхню атаки. Доречно нагадати, що кейс Камінскі 2008 року показав: слабка ентропія порту й TXID різко підвищує успішність підміни відповіді; саме тому рандомізація та валідація — обов’язкові.
Рекомендації для адміністраторів і команд безпеки
Оновіться без зволікань до версій 9.18.41, 9.20.15 або 9.21.14 (для BIND SPE: 9.18.41‑S1, 9.20.15‑S1). Після інсталяції виконайте очищення кешу (rndc flush), аби усунути потенційно підкинуті записи.
Вмикайте й підтримуйте DNSSEC: перевірка підписів, актуальний trust anchor кореневої зони (KSK) та моніторинг валідності ланцюжків значно знижують шанс успішної підміни відповіді.
Обмежте рекурсію через ACL для довірених підмереж, застосовуйте Response Rate Limiting (RRL), активуйте qname minimization і переконайтеся, що рандомізація портів і TXID увімкнена. За можливості оцініть вплив NAT і порт‑preservation політик, які можуть зменшувати ефективну ентропію портів.
Зміцніть мережевий периметр антиспуфінгом згідно з BCP 38/84, контролюйте ingress/egress‑трафік, використовуйте сучасні фаєрвол‑правила та, за потреби, DNS Cookies як додатковий контроль проти підміни в окремих сценаріях.
Моніторинг і детекція: увімкніть деталізоване журналювання DNS, налаштуйте сповіщення на сплески NXDOMAIN/ServFail та аномалії CPU, періодично перевіряйте цілісність кешу і профіль затримок резолвінгу, щоб швидко виявляти спроби poisoning та DoS.
Контекст: подібні ризики в Unbound
Дослідники, які повідомили про проблеми в BIND 9, також ідентифікували споріднені уразливості у популярному резолвері Unbound. Там ризик оцінено нижче (близько 5,6 за CVSS), однак операторам змішаних середовищ варто синхронно перевірити оновлення і захисні конфігурації для всіх використовуваних компонентів DNS‑ланцюга.
Швидке встановлення патчів BIND 9, жорстка валідація відповідей і послідовне впровадження DNSSEC залишаються базовими заходами кібергігієни для DNS‑інфраструктури. Перевірте версії резолверів, проведіть rndc flush, перегляньте ACL, увімкніть RRL і антиспуфінг, а також налаштуйте проактивний моніторинг. Це мінімізує вікно атаки для cache poisoning і DoS та підвищить стійкість критичних сервісів до мережевих загроз.
