Заражение кэша DNS-серверов провайдеров за счет манипуляции DNS-ответами от легитимных авторитетных DNS-серверов

[nikitasius]

DNSSEC?

[kolu4iy]

Ну видимо да. На https же ушло в итоге больше половины интернета, и сюда уйдут. Главное опасность раздуть посильнее, и сами все побегут.

[younghacker]

Да-да!
Недавно столкнулся с интересным поведением домена (у клиента).
На него невозможно было навесить сертификат letsencrypt
Скрипт упорно возвращал ошибку «сервер не найден». Ошибка приходила от сервиса letsencrypt.
Но хост у меня нормально грузился и ресолвился. И в ступор меня ставило то что nslookup на мой DNS работал, на яндекса работал, а на гугл 8.8.8.8 возвращал ошибку: «хост не найден». dig-ом раскопал что в домене кто-то начал настраивать DNSSEC но не закончил. Была прописана только запись DS. Запись удалили — и гугл вернул адрес!
Вывод — гугл и letsencrypt поступают значительно логичнее чем все остальные: Если в домене есть какие-то упоминания о DNSSEC но полная верификация невозможна то нужно вернуть ошибку, а не пытаться ресолвнуть без DNSSEC!

[mvv-rus]

Можно и без DNSSEC. Достаточно проверять, что данные, возвращаемые в поле Additional, имеют отношение к запрошенному имени. То есть, ответу на запрос для имени test.b позволяется вернуть записи для, максимум, домена b — но никак, не записи для домена victim.com или, тем более, com.
Мезанизм атаки, описанный в статье, известен уже давно. И, к примеру, в DNS сервере из состава MS Windows такие левые ответы блокируются включеной по умолчанию настройкой «Secure cache against pollution». В bind аналогичная опция тоже должна быть.

[Furriest]

Понятно, что 100% внедрение dnssec в каком-то очень далеком будущем может спасти. Но в текущей реальности — можно ли научить того же bind, как самый распространенный кэширующий сервер, не принимать то, что приходит в additional options? Если да — то как?

[mayorovp]

Кто-нибудь может перевести это все на русский? Я уже во второй главе запутался кто тут злодей, а кто — жертва...

[Furriest]

Все просто — какой-нибудь совершенно честный сервер, поддерживающий, например, habrahabr.ru, может прислать вместе с ответом на валидный запрос IP-адреса для www.habrahabr.ru дополнительную опцию, в которой укажет, что www.microsoft.com на самом деле доступен на совершенно левом IP. И ваш неймсервер запомнит этот резолв и будет отдавать его клиентам.

[mayorovp]

Эту часть я понял. Но какой смысл в качестве этого самого левого IP указывать адрес межсетевого экрана, который и без того слушает весь трафик до www.microsoft.com, потому что находится между сервером и его провайдером?

[yetiman]

С точки зрения защиты, МСЭ может выполнять функции защиты от утечки информации, а с точки зрения нарушителя, это не МСЭ, а типичный MitM, позволяющий «случать», «подменять» и так далее. Обозначение «МСЭ» — чисто условное.

[mayorovp]

Тем не менее, по схеме — он уже между сервером и клиентом. Зачем в этой ситуации сложности с DNS?

[Furriest]

Это был простой эксперимент. Подразумевалось (как я предполагаю), что указывается адрес сервера, реализующего MitM-атаку и в общем случае не находящегося между клиентом и сервером.

[rekby]

Кстати сейчас от такого mitm и https не спасёт, без дополнительных средств вроде привязки к сертификату в заголовке и/или мониторинга в реальном времени выпущенных сертификатов.

точно так же можно подменить DNS-ответы для сервера lets encrypt, получить их сертификат.

Потом уже атаковать DNS-сервер провайдера/клиента чтобы встроится посередине с сертификатом Let's encrypt. Тогда и клиент увидит валидный сертификат и браузер паниковать не будет и трафик будет прослушан.

[ValdikSS]

Заражение кеша через Additional Section исправили во всех популярных DNS-серверах и резолверах году так в 1997.

[Chupaka]

А BIND 9.4 вышел в 2007-м. Выходит, автор что-то недоговаривает?

[yetiman]

Тестили на BIND 9.4. Только и всего… По части комментария ValdikSS ничего не могу сказать. Дополнительные секции предназначены ведь для передаче в ответе «запасных» IP для «заказанных» в запросе доменов. Насколько это можно исправить, если у них назначение — добавлять записи как запасные, в том числе в кэш… Спорить не буду, просто не в курсе.

[ValdikSS]

Сделал тестовый DNS-сервер, который отвечает следующим образом:

;; QUESTION SECTION:
;testcache.domain.ru.           IN      A

;; ANSWER SECTION:
testcache.domain.ru.    60      IN      A       1.2.3.4

;; AUTHORITY SECTION:
ru.                     3600    IN      NS      ns1.yandex.ru.

;; ADDITIONAL SECTION:
ns1.yandex.ru.          3600    IN      A       1.2.3.4

При резолве через BIND 9.10.4 возвращаются следующие данные:

;; QUESTION SECTION:
;testcache.domain.ru.           IN      A

;; ANSWER SECTION:
testcache.domain.ru.    60      IN      A       1.2.3.4

;; AUTHORITY SECTION:
testcache.DOMAIN.ru.    36      IN      NS      ns.testcache.domain.ru.

;; ADDITIONAL SECTION:
ns.testcache.DOMAIN.ru. 36      IN      A       1.2.3.4

Как можно видеть, bind перезаписал значения authority section и additional section значением домена.

[yetiman]

Так вы не то «резолвили». Попробуйте у вашего кеширующего bind'a запросить ns1.yandex.ru

[ValdikSS]

Пробовал, естественно — вернулся настоящий IP-адрес ns1.yandex.ru.

[yetiman]

Ммм, вы знаете, было бы правильней показать дамп сетевых пакетов DNS-запросов и DNS-ответов. Дело в том, что настройки BIND`а это одно, а то, как он формирует пакеты — несколько иное. Подобные настройки, указанные вами в рамках эксперимента тестировались, однако, как ни странно, BIND «отвечал» совсем не так, как указанно в настройках, добавляя справа к домену «дописки». Именно поэтому в эксперименте, описанном в данном материале, использовался для формирования DNS-ответов и полей Additional не BIND, а самописный скрипт.

Тем не менее, нисколько не умаляю довод, что данная особенность BIND`ов и их аналогов, связанная с обработкой полей Additional, могла быть исправлена.

[ValdikSS]

О каких настройках вы говорите, о записях зоны? Я bind использовал только для резолва, ответ формировал DNS-сервером на основе dnslib (библиотека Python) вручную. У вас тоже нет никаких дампов пакетов в статье.

Данная уязвимость была исправлена в 1997, если не раньше. Если бы она работала, ей бы пользовались все злоумышленники, чего не происходит. Пожалуйста, выложите все необходимые действия и настройки для осуществления атаки и получения такого результата, какой описан в статье. На данный момент статья не соответствует действительности.

[yetiman]

Чем вас не устраивают дампы Wireshark`а?

[ValdikSS]

Не вижу дампов, вы о визуальном представлении? Визуально мой пакет выглядит примерно так же. Только что максимально приблизил его к вашему — тот же результат, заражения кеша не происходит.