Кратко

  • Отравление класса Kaminsky вызывало запросы к новым именам и снова запускало гонку вне пути: поддельный ответ должен был угадать параметры ожидающего запроса и обогнать авторитетный сервер.
  • Согласованные исправления 2008 года не аутентифицировали данные DNS. Они добавили к локальной границе непредсказуемые идентификаторы и исходные порты, чья энтропия должна была сохраниться после межсетевого экрана и NAT и проверяться в реальном трафике.

Первое совпадение становилось ответом

Рекурсивный резолвер обычно отправлял неподписанный UDP-запрос. В обычном ответе не было криптографического доказательства происхождения. Поэтому резолвер проверял, относится ли пакет к операции, которую он действительно начал и ещё не завершил.

RFC 5452 сформулировал границу: секция вопроса и ID должны совпадать, источник должен выглядеть как опрошенный сервер, а пакет — вернуться на адрес и порт, с которых ушёл запрос. Как правило, принимался первый ответ, удовлетворяющий условиям.

Атакующий вне пути не видел запрос, но мог подделать адрес авторитетного сервера и отправить множество кандидатов. Один точный вариант, пришедший раньше, попадал в кеш. Затем сам резолвер распространял ложь клиентам.

Это была ограниченная власть: один кеш, определённые записи и срок. Не контроль над всем DNS. Поэтому доступ к рекурсии, сопоставление, bailiwick, случайность и проверка подписей требуют разных средств.

Неудача сама создавала следующую попытку

Отравление кеша существовало до 2008 года. RFC 3833 ещё в 2004-м описывал угадывание ID, прогнозирование запросов и цепочки имён. Поле ID имеет 16 бит; слабые генераторы оставляли меньше; постоянный UDP-порт не добавлял неизвестности.

Dan Kaminsky показал практическую комбинацию. Атакующий заставлял резолвер спросить ранее не встречавшуюся случайную метку под целевым доменом. Кеша не было — уходил новый запрос. Подделки соревновались с настоящим ответом. После промаха другая метка открывала новое окно.

Одноразовое имя было спусковым механизмом, а не обязательно целью. Подделка могла попытаться установить сведения о делегировании для родительского домена в пределах правил релевантности и bailiwick. Ждать окончания TTL ценного объекта больше не требовалось.

RFC 5452 моделирует эффективный TTL некоторых повторяемых атак как почти нулевой. При 7 000 ложных пакетов в секунду и одном порте вероятность 50% достигается примерно за семь секунд. Это не универсальный срок, а демонстрация того, как дешёвое повторение превращает малый шанс в операционный риск.

Порт стал вторым идентификатором

Экстренная защита расширила набор угадываемых значений. Исправленные резолверы выбирали непредсказуемый исходный порт для каждого запроса и усиливали ID вместо повторного использования постоянного порта.

RFC 5452 оценивал около 64 тысяч вариантов и такое же увеличение пространства. В той же модели отметка 50% сдвигалась с семи секунд примерно к 116 часам. CERT/CC говорил почти о 16 дополнительных битах в принципе, но оговаривал занятые и зарезервированные порты.

Формат DNS менять не пришлось. Авторитетный сервер уже отвечал на исходный порт. Поставщики могли исправить код, а операторы — внедрить его независимо.

Цена сохранялась. ISC предупреждал о заметной потере производительности первоначального патча BIND выше примерно 10 тысяч запросов в секунду и предлагал оптимизированные бета-ветви. Правила, выпускавшие DNS только с порта 53, требовали изменения; устройства с состоянием расходовали больше отображений.

Патч не отменил инженерную работу. Он заменил предсказуемую комбинацию более сложным управлением сокетами и состоянием. Такой обмен можно измерять и откатывать локально.

NAT мог снова сузить пространство

Инвентарь мог показывать исправленную версию, а снаружи оставался малый набор портов. NAT/PAT переписывает исходные порты. CERT/CC предупреждал об уменьшении или исчезновении выигрыша; RFC 5452 выделял устройства, которые последовательно назначают или жёстко ограничивают порты.

Не всякий NAT вреден. Одни сохраняют выбор, другие меняют видимое распределение по-разному. Контрольная величина — число вариантов после ОС, межсетевого экрана и трансляции, там, где их угадывает противник.

DNS-OARC предложил тесты портов и ID со стороны авторитетного узла. Оператор видел распределение фактически полученных значений, а не выводил защиту из номера пакета.

Так принцип Running-Code Primacy получает проверяемое содержание: бюллетень описывает намерение, менеджер пакетов — установку, но лишь работающий трафик показывает, не уничтожила ли окружная система результат.

Совместный выпуск не означал совместное внедрение

DNS-OARC фиксирует встречу в Microsoft 31 марта 2008 года. 8 июля CERT/CC опубликовал VU#800113 вместе с обновлениями многих производителей. ISC исправил BIND; Microsoft изменила ID, UDP-сокеты и кеш.

Секретность не дожила до запланированного доклада. Хронология указывает фактическую утечку 21 июля, рабочий код 23-го и новые реализации 24-го. 25 июля Microsoft сообщил о росте угрозы из-за публичного кода. Компания также заявила, что тогда не знала об активных атаках или ущербе клиентам, а проверенный эксплойт не действовал на системы с MS08-037.

Это не доказывает глобального отсутствия эксплуатации. Код увеличил возможности, обзор одного поставщика был ограничен, а один тест не сертифицировал все сочетания резолвера и сети.

Kaminsky выступил на Black Hat 7 августа. RFC 5452 вышел в январе 2009 года. Сначала исполняемый совместимый патч дал защиту, затем документ закрепил правила. Стандарт не устанавливал июльские обновления сам.

Дорогая ложь ещё не стала подлинным ответом

Случайные порты сильно усложнили подделку вне пути, но не доказали, что неподписанные данные принадлежат делегированному владельцу зоны. Утечка состояния, сужающий транслятор, множество попыток или положение на пути меняли условия.

Поэтому ISC называл DNSSEC окончательным решением, признавая нереалистичность немедленного общего внедрения. DNSSEC проверяет источник и целостность подписями и цепочкой доверия. Это иное свойство, а не просто более трудная лотерея.

Слои дополняются. Строгое сопоставление и энтропия дешёво отбрасывают мусор; DNSSEC оценивает полномочия данных. Ни один контроль не должен присваивать функцию другого.

Minimum Initial Specification Хэн Лу оставляет общий слой небольшим: точное сопоставление и достаточная непредсказуемость, без превращения генератора, распределителя сокетов или графика производителя в мировой приказ. Будущие решения остаются локальными, а принятие подтверждается работающим наблюдаемым поведением.

Границы доказательств

Источники подтверждают межпроизводственную уязвимость и более практичную технику. Они не подтверждают одинаковый дефект в каждом резолвере, всеобщее обновление 8 июля или универсальность семи секунд и 116 часов. Порты усложнили атаку при заданных предположениях, но не устранили всё отравление. Спецификация DNSSEC также не доказывает фактическую валидацию.

Точный вывод достаточен: часть доверия DNS зависела от малой гонки, а многие системы непреднамеренно сокращали её неопределённость. Исправление увеличило и сделало измеримым пространство, оставив аутентификацию отдельной задачей развёртывания.

Источники