Содержание статьи
Общая информация о BIND
BIND (Berkeley Internet Name Domain) — это опенсорсная реализация протокола DNS и DNS-сервера. Разработку поддерживает организация ISC (Internet Systems Consortium), цель которой — создавать эталонные решения в области ПО, нужного для функционирования интернета. Это один из наиболее распространенных DNS-серверов в интернете: «Википедия» гласит, что «10 из 13 корневых серверов DNS работают на BIND».
В состав BIND, помимо самого сервера DNS, входят библиотека DNS-резолвера и разные утилиты для управления сервером. Текущая, девятая ветка дистрибутива была релизнута аж в 2000 году. За это время было найдено огромное количество багов, и один из них мы сегодня разберем. Ему присвоены два бюллетеня с номерами CVE-2017-3142 и CVE-2017-3143.
Протокол TSIG
TSIG (Transaction SIGnature) — это протокол, который обеспечивает идентификацию и целостность данных. Для этого в нем реализована технология подписи транзакций. Для всех запросов, ответов и прочих сообщений к DNS при помощи механизма проверки целостности информации (HMAC) высчитывается сигнатура на основе общего секретного ключа (shared key).
При правильно работающем механизме TSIG и сервер, и клиент добавляют TSIG в раздел дополнительных данных пакета с запросом к DNS. Тем самым они подтверждают, что обладают верным секретным ключом, что сообщение не изменилось по пути и ему можно доверять.
Протокол TSIG поддерживают все популярные серверы DNS, такие как NSD, PowerDNS, Knot и, разумеется, BIND.
WARNING
Вся информация носит только ознакомительный характер. Ни автор, ни редакция не несут ответственности за ее ненадлежащее использование.
Информация об уязвимости
В начале июня 2017 года исследователи безопасности из компании Synacktiv обнаружили брешь в реализации протокола TSIG в BIND. Уязвимость позволяет атакующему, который знает название ключа TSIG, обойти проверку протокола и вычислять легитимную сигнатуру для произвольных сообщений к DNS-серверу.
Проблема заключается в том, что, когда клиент отправляет пакет, который содержит TSIG-дайджест заведомо неверной длины, в ответ сервер все равно вернет валидно подписанный пакет, используя переданный дайджест в качестве префикса. Это позволяет атакующему узнать сигнатуру валидного запроса и тем самым пройти проверки легитимности.
Сама уязвимость была протестирована в версиях BIND 9.9.10, 9.10.5 и 9.11.1. Однако ISC в бюллетене безопасности указывает, что уязвимы следующие версии продуктов:
- от 9.4.0 до 9.8.8;
- от 9.9.0 до 9.9.10P1;
- от 9.10.0 до 9.10.5P1;
- от 9.11.0 до 9.11.1P1;
- от 9.9.3S1 до 9.9.10S2;
- от 9.10.5S1 до 9.10.5S2.
Так что если ты счастливый обладатель одной из них, то скорее обновляйся.
Тестовый стенд
Чтобы в полной мере насладиться изучением проблемы, нужно эмулировать идеальные условия ее возникновения. Для этого по старинке возьмем Docker.
В интернете ты можешь найти массу способов установки и настройки BIND, а здесь я пробегусь по ключевым моментам, которые позволят воссоздать ситуацию, когда атака возможна.
Первое, что нужно сделать после установки BIND, — это сконфигурировать новую зону в DNS-сервере. В этом нам поможет файл /etc/bind/named.conf.local.
Создаем TSIG-ключ, даем ему произвольное имя и указываем алгоритм, который будет использоваться для генерации сигнатур при общении клиента с сервером DNS (и наоборот).
/etc/bind/named.conf.local
1: key "guess_tsig_key" {
2: algorithm hmac-sha256;
3: secret "dmVyeXNlY3JldG1lZ2FrZXk=";
4: };Для успешной эксплуатации уязвимости атакующему нужно угадать ключ и алгоритм хеширования.
Далее настраиваем саму зону (я задал bind.visualhack) и определяем, для каких запросов нужно использовать валидацию через протокол TSIG и соответствующий ключ.
06: zone "bind.visualhack" {
07: type master;
08: file "/etc/bind/zones/bind.visualhack.db";
09: allow-transfer {key guess_tsig_key;};
10: allow-update {key guess_tsig_key;};
11: };Помимо прочего, нам понадобится какой-нибудь сниффер, например tcpdump.
Если не хочешь со всем этим возиться, то просто скачивай готовый файл Docker из моего репозитория. В нем используется уязвимая версия BIND 9.10.5. Запускай скрипт run.sh, он сделает все необходимое, тебе останется только запустить сам сервер командой named -g.
Go-go-go!
Общие детали
Для начала посмотрим, как выглядит легитимный запрос на zone transfer. Это делается утилитой dig, но сначала поставим tcpdump в режим мониторинга трафика DNS. Чтобы включить TSIG в запросах, нужно указать ключ с помощью опции -y. Формат такой: -y algorithm:keyname:keyvalue.
tcpdump -lvi any -w dns.pcap
dig -t axfr @127.0.0.1 bind.visualhack -y 'hmac-sha256:guess_tsig_key:dmVyeXNlY3JldG1lZ2FrZXk='
Поймалось несколько пакетов, давай посмотрим на них.
На скрине видно TSIG, который сгенерировал сервер на основе нашего ключа. Формат ответа описан в RFC 2845. Согласно спецификации все запросы при общении должны быть подписаны. Сама подпись генерируется на основе следующих компонентов:
- размер MAC (Message authentication code, дайджест) запроса. Под него выделяется два байта;
- MAC-запрос;
- DNS-сообщение ответа;
- ключ TSIG-ответа.
Далее в этой же RFC в параграфе 4.3 указано, что если запрос вызвал ошибку и эта ошибка не имеет отношения непосредственно к TSIG, то в ответ должен улететь пакет с подписью, которая будет сгенерирована в соответствии с указанными выше параметрами.
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Вариант 2. Открой один материал
Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.
Я уже участник «Xakep.ru»
