yetiman Feb 3 2017 at 17:42

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

6 min

17K

Domain names administrating*Network technologies*Server Administration*DNS*

Comments 22

nikitasius Feb 3 2017 at 20:31

DNSSEC?

kolu4iy Feb 4 2017 at 10:04

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

younghacker Feb 6 2017 at 18:10

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

mvv-rus Feb 11 2017 at 08:57

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

Furriest Feb 4 2017 at 08:20

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

mayorovp Feb 4 2017 at 10:45

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

Furriest Feb 4 2017 at 14:36

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

mayorovp Feb 4 2017 at 15:39

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

yetiman Feb 4 2017 at 15:45

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

mayorovp Feb 4 2017 at 15:49

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

Furriest Feb 4 2017 at 16:05

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

rekby Feb 5 2017 at 12:13

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

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

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

ValdikSS Feb 5 2017 at 20:24

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

Chupaka Feb 6 2017 at 12:54

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

yetiman Feb 6 2017 at 12:57

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

ValdikSS Feb 6 2017 at 15:25

Сделал тестовый 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 Feb 6 2017 at 16:04

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

ValdikSS Feb 6 2017 at 17:56

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

yetiman Feb 6 2017 at 18:15

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

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

ValdikSS Feb 6 2017 at 18:37

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

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

yetiman Feb 6 2017 at 18:49

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

ValdikSS Feb 6 2017 at 18:54

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

Show the best of all time