Вразливість BIND дозволяє "впустити" будь-який сервер як і чому це працює
Ми поставили собі за мету створити правила (NAD) для виявлення експлуатації даних уразливостей по мережі — щоб це зробити, нам довелося глибше розібратися з кодом BIND і написати власні експлоїти. Наш розбір допоможе зрозуміти, як все влаштовано всередині настільки популярного DNS-сервера, а також дізнатися про прорахунки, допущені розробниками проекту, і можливі рішення цих проблем.
В чому проблема
Під найбільшим ризиком знаходяться рекурсивні сервери з підтримкою DNSSEC, тому ми розглянемо саме випадок рекурсивного запиту.
В описі патча стверджується, що певне поєднання DNSSEC записів у відповіді на рекурсивний запит може викликати відмову в обслуговуванні сервера або, по-простому, креш. Крім того, розробники доповнюють, що таке поєднання полів не зустрічається у нормальному DNS-трафіку.
Для подальшого розуміння проблеми необхідно вивчити публічно доступний патч цієї CVE. Патч виправляє всього кілька рядків коду в одному з модулів, які відповідають за обробку DNS відповідей.
Як ми можемо бачити, патч виправляє логічну помилку за умови
Виконання всіх трьох виразів стало обов'язковим для зміни змінної have_answer у true. Це необхідно для визначення того, чи пакет містить відповідь на наш запит:
Таким чином, стає очевидним, що експлуатація вразливості відбувається через неповне виконання умови з патчу. Спробуємо зрозуміти, яке поєднання записів у пакеті необхідне експлуатації.
Пишемо експлоїти
Потрапити у гілку з уразливим кодом можна через таку коротку умову
Змінна found встановлюється в п'яти блоках коду з цієї ж функції, які обробляють різні варіації відповідей, такі як перенаправлення імен записами CNAME абоDNAME , відповідь на запит з типом ANY і т.д.
Згадаймо невелику підказку в описі патчу:
“Найменений хитромудрий певні відповіді, де поширюються RRSIG записи, які відновлюються без затверджених даних, що беруть участь у визначенні помилки. (CVE-2016-9147)”
Яка каже, що один із записів має бути записом RRSIG . RRSIG - це один із механізмів DNSSEC, що забезпечує цілісність DNS даних у відповіді. Для записів будь-якого типу (A, AAAA, NS, DNAME, CNAME і т.д.) у відповіді передається відповідний запис RRSIG , що містить цифровий підпис. Для того, щоб зрозуміти, для якого типу RRSIG містить підпис, у RRSIG існує поле Type Covered .
Усього 2 з 5 умов пов'язані з виявленням RRSIG у DNS відповіді:
Ця перевірка спрацьовує, якщо ми виявили RRSIG з підписом для того запису, що ми шукаємо (для якого надсилали запит).
А ця умова подібна до першого, тільки запис RRSIG повинен покрити тип CNAME.
Ми прийшли до висновку, що для експлуатації цієї помилки потрібен один єдиний запис RRSIG в ANSWER_SECTION . І справді, така ситуація має зустрічатися у звичайному DNS трафіку, т.к. RRSIG не може бути не прив'язана до іншого запису.
Пробуємо відтворити топологію з рекурсивним DNS сервером і на рекурсивний запит надіслати відповідь з одного RRSIG запису, який покриває або CNAME або тип із DNS запиту.
Як і передбачалося, ми бачимо екстрене завершення роботи Named демона:
Що в результаті
Розглянута вразливість досить проста і небезпечна ще й тим, що її експлуатації не потрібно складних умов. Розробники BIND постійно виправляють серйозні вразливості сервера DNS, що дозволяють порушити його роботу.
ЕкспертиPositive Technologies уважно вивчили всі усунуті розробниками вразливості, відтворили їх у реальних умовах та розробили IDS сигнатури для виявлення експлуатації.
— Attack Detection (@AttackDetection) February 7, 2017
Автор: Кирило Шипулін, спеціаліст групи дослідження методів виявлення атак. Positive Technologies
Ви можете допомогти і переказати трохи коштів на розвиток сайту