Comments 22

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

Да-да!
Недавно столкнулся с интересным поведением домена (у клиента).
На него невозможно было навесить сертификат letsencrypt
Скрипт упорно возвращал ошибку «сервер не найден». Ошибка приходила от сервиса letsencrypt.
Но хост у меня нормально грузился и ресолвился. И в ступор меня ставило то что nslookup на мой DNS работал, на яндекса работал, а на гугл 8.8.8.8 возвращал ошибку: «хост не найден». dig-ом раскопал что в домене кто-то начал настраивать DNSSEC но не закончил. Была прописана только запись DS. Запись удалили — и гугл вернул адрес!
Вывод — гугл и letsencrypt поступают значительно логичнее чем все остальные: Если в домене есть какие-то упоминания о DNSSEC но полная верификация невозможна то нужно вернуть ошибку, а не пытаться ресолвнуть без DNSSEC!
Можно и без DNSSEC. Достаточно проверять, что данные, возвращаемые в поле Additional, имеют отношение к запрошенному имени. То есть, ответу на запрос для имени test.b позволяется вернуть записи для, максимум, домена b — но никак, не записи для домена victim.com или, тем более, com.
Мезанизм атаки, описанный в статье, известен уже давно. И, к примеру, в DNS сервере из состава MS Windows такие левые ответы блокируются включеной по умолчанию настройкой «Secure cache against pollution». В bind аналогичная опция тоже должна быть.
Понятно, что 100% внедрение dnssec в каком-то очень далеком будущем может спасти. Но в текущей реальности — можно ли научить того же bind, как самый распространенный кэширующий сервер, не принимать то, что приходит в additional options? Если да — то как?

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

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

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

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

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

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

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

Потом уже атаковать DNS-сервер провайдера/клиента чтобы встроится посередине с сертификатом Let's encrypt. Тогда и клиент увидит валидный сертификат и браузер паниковать не будет и трафик будет прослушан.
Заражение кеша через Additional Section исправили во всех популярных DNS-серверах и резолверах году так в 1997.
Тестили на BIND 9.4. Только и всего… По части комментария ValdikSS ничего не могу сказать. Дополнительные секции предназначены ведь для передаче в ответе «запасных» IP для «заказанных» в запросе доменов. Насколько это можно исправить, если у них назначение — добавлять записи как запасные, в том числе в кэш… Спорить не буду, просто не в курсе.
Сделал тестовый 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 значением домена.
Так вы не то «резолвили». Попробуйте у вашего кеширующего bind'a запросить ns1.yandex.ru
Ммм, вы знаете, было бы правильней показать дамп сетевых пакетов DNS-запросов и DNS-ответов. Дело в том, что настройки BIND`а это одно, а то, как он формирует пакеты — несколько иное. Подобные настройки, указанные вами в рамках эксперимента тестировались, однако, как ни странно, BIND «отвечал» совсем не так, как указанно в настройках, добавляя справа к домену «дописки». Именно поэтому в эксперименте, описанном в данном материале, использовался для формирования DNS-ответов и полей Additional не BIND, а самописный скрипт.

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

Данная уязвимость была исправлена в 1997, если не раньше. Если бы она работала, ей бы пользовались все злоумышленники, чего не происходит. Пожалуйста, выложите все необходимые действия и настройки для осуществления атаки и получения такого результата, какой описан в статье. На данный момент статья не соответствует действительности.
Не вижу дампов, вы о визуальном представлении? Визуально мой пакет выглядит примерно так же. Только что максимально приблизил его к вашему — тот же результат, заражения кеша не происходит.
Only those users with full accounts are able to leave comments. Log in, please.