В предыдущей статье мы обсуждали захват доменных расширений .na, .co.ao и .it.ao разными хитростями с DNS. Сейчас рассмотрим угрозу компрометации домена верхнего уровня (TLD) и как нужно действовать злоумышленнику, чтобы достичь поставленной цели. Одним из довольно простых методов видится регистрация доменного имени одного из авторитативных серверов имён этой TLD. Поскольку в TLD авторитативные серверы могут размещаться на произвольных доменах, то есть вероятность зарегистрировать такой домен, воспользовавшись ошибкой из-за неправильной конфигурации, истечения срока действия или других ошибок. Затем этот сервер можно использовать для выдачи новых DNS-записей в целой доменной зоне.

Приведу здесь соответствующую цитату из предыдущей статьи:

Такой вариант казался верной дорогой к победе, так что я потратил много времени на разработку инструментария для проверки ошибок этого типа. По сути, этот процесс состоит в записи всех хостов серверов имён для данного домена — и проверке, когда истечёт срок регистрации какого-нибудь из корневых доменов и он станет доступен для регистрации. Основная проблема в том, что многие регистраторы не говорят, что домен полностью свободен, пока вы реально не попробуете его купить. Кроме того, было несколько случаев, когда у сервера заканчивался срок регистрации, но по какой-то причине домен был недоступен для регистрации, хотя не был помечен как зарезервированный. В результате такого сканирования удалось зафиксировать много перехватов доменов в закрытых зонах (.gov, .edu, .int и др.), но не самих TLD.

Как выяснилось, такой способ не только подходит для атаки TLD, но в реальности привёл к крупнейшему захвату TLD на сегодняшний день.

Аномалия .io

В пятницу вечером, составляя график путей делегирования DNS для различных TLD, мой скрипт выдал неожиданный результат для зоны .io:



Одна из функций этого скрипта (который называется TrustTrees) заключается в том, что ему можно передать ключ Gandi API — а он проверит, есть ли в цепочке делегирования серверы имён со свободными для регистрации доменными именами. Скрипт показал, что в зоне .io многие домены серверов имён доступны для покупки! Впрочем, это не означает, что их в самом деле можно купить. Раньше я неоднократно сталкивался с тем, что свободное доменное имя нельзя зарегистрировать, потому что оно «зарезервировано». Я решил пойти на сайт регистратора NIC.IO и проверить. Быстренько поискав доменное имя ns-a1.io, с удивлением обнаружил, что оно выставлено на продажу по цене $90,00. Поскольку было около полуночи (наверное, автор считает это «детским» временем — прим.пер.), я решил продолжить и реально попытаться купить этот домен. Вскоре пришло письмо с подтверждением, что регистрация доменного имени «обрабатывается»:



Не совсем понятно, почему письмо пришло от компании 101Domain. Вероятно, она занимается регистрацией доменов в зоне .io (возможно, и управляет всем реестром?). В этот время уже далеко за полночь я пожал плечами и пошёл спать, и забыл об этом случае, пока в среду утром не пришло такое письмо, когда я уже собирался уходить на работу:



Тут я вспомнил о своём пятничном расследовании и всех подробностях регистрации. Пришлось вернуться за компьютер: интересно, неужели я действительно получил контроль над серверами имён доменной зоны .io? Я быстренько запустил команду dig для домена — и убедился, что мои тестовые серверы имён DNS (ns1/ns2.networkobservatory.com ) действительно записаны на ns-a1.io:

bash-3.2$ dig NS ns-a1.io

; <<>> DiG 9.8.3-P1 <<>> NS ns-a1.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8052
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns-a1.io.          IN  NS

;; ANSWER SECTION:
ns-a1.io.       86399   IN  NS  ns2.networkobservatory.com.
ns-a1.io.       86399   IN  NS  ns1.networkobservatory.com.

;; Query time: 4 msec
;; SERVER: 2604:5500:16:32f9:6238:e0ff:feb2:e7f8#53(2604:5500:16:32f9:6238:e0ff:feb2:e7f8)
;; WHEN: Wed Jul  5 08:46:44 2017
;; MSG SIZE  rcvd: 84

bash-3.2$

Запросил один из корневых серверов DNS и снова убедился, что этот домен указан в качестве авторитативного сервера имён для доменной зоны первого уровня .io:

bash-3.2$ dig NS io. @k.root-servers.net.

; <<>> DiG 9.8.3-P1 <<>> NS io. @k.root-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19611
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 12
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;io.                IN  NS

;; AUTHORITY SECTION:
io.         172800  IN  NS  ns-a1.io.
io.         172800  IN  NS  ns-a2.io.
io.         172800  IN  NS  ns-a3.io.
io.         172800  IN  NS  ns-a4.io.
io.         172800  IN  NS  a0.nic.io.
io.         172800  IN  NS  b0.nic.io.
io.         172800  IN  NS  c0.nic.io.

;; ADDITIONAL SECTION:
ns-a1.io.       172800  IN  AAAA    2001:678:4::1
ns-a2.io.       172800  IN  AAAA    2001:678:5::1
a0.nic.io.      172800  IN  AAAA    2a01:8840:9e::17
b0.nic.io.      172800  IN  AAAA    2a01:8840:9f::17
c0.nic.io.      172800  IN  AAAA    2a01:8840:a0::17
ns-a1.io.       172800  IN  A   194.0.1.1
ns-a2.io.       172800  IN  A   194.0.2.1
ns-a3.io.       172800  IN  A   74.116.178.1
ns-a4.io.       172800  IN  A   74.116.179.1
a0.nic.io.      172800  IN  A   65.22.160.17
b0.nic.io.      172800  IN  A   65.22.161.17
c0.nic.io.      172800  IN  A   65.22.162.17

;; Query time: 70 msec
;; SERVER: 2001:7fd::1#53(2001:7fd::1)
;; WHEN: Wed Jul  5 08:46:14 2017
;; MSG SIZE  rcvd: 407

Ничего себе! Я сразу же соединился по SSH со своим тестовым сервером DNS, к которому теперь был привязан этот домен, и быстренько убил работающий BIND-сервер. Если ко мне повалит DNS-трафик, то я определённо не хочу возвращать плохие ответы людям, которые имеют законный доступ ко своим доменам .io. Поскольку BIND-сервер больше не обрабатывает запросы на порт 53, то все DNS-запросы автоматически перенаправятся на другие сервера имён этой TLD и не слишком повлияют на трафик (кроме небольшой задержки при резолвинге, пока DNS-клиенты достучаться до работающего сервера имён). Чтобы посмотреть, действительно ли ко мне пошли DNS-запросы, я быстренько запустил запись дампа tcpdump всего DNS-трафика в файл — и тут же на экран хлынули сотни запросов со случайных IP со всех уголков интернета. Похоже, я действительно обрабатывал трафике для всей доменной зоны. А ещё хуже: вероятно, это было только начало, потому что многие DNS-клиенты ещё руководствовались кешированными старыми DNS-записями, которые скоро обновятся.

Сообщение об проблеме безопасности в TLD

Поскольку мой сервер больше не отвечал на DNS-запросы, я думал только о том, как побыстрее исправить ситуацию. Больше всего меня беспокоило, что в продаже осталось ещё много доменов для серверов имён, которые может зарегистрировать кто угодно, у кого есть деньги и знания, что нужно делать. Я поискал контакты администраторов .io TLD в корневой базе данных IANA:



Затем составил описание проблемы и отправил письма на оба адреса, отметив необходимость срочного решения. Указал, что домены для других серверов имён TLD по-прежнему доступны для регистрации и что если проблему не решат в течение нескольких часов, я зарегистрирую их, чтобы защитить зону. Немедленно после отправки письма я получил отлуп от почтового сервера с указанием, что адрес adminstrator@nic.io не существует:



Это явно не прибавляло уверенности, что кто-то прочитает моё письмо. Так что я решил потратить немного денег и купить остальные домены серверов имён, чтобы никто не хакнул TLD. Как и в первом случае, я явно настроил DNS-сервер не принимать входящие запросы, так что не вмешивался в обычный трафик .io. Эти заказы на покупку оформили достаточно быстро:



Фух! По крайней мере, их не взломает какой-нибудь случайный хакер, а я могу с чистым сердцем идти на работу.

Позже в этот день я позвонил по телефону в поддержку NIC.IO и спросил действующий адрес электронной почты кого-нибудь из сотрудников отдела безопасности для TLD. Агент заверил меня, что подходящим адресом для такого запроса будет abuse@101domain.com (я дважды переспросил его на этот счёт для уверенности). Хотя такой адрес не выглядит подходящим, но я переправил туда отчёт с описанием проблемы и надеялся, что его хотя бы перешлют компетентному специалисту. Поскольку не было возможности узнать другие адреса, я ждал ответа.

«Упс» — исправление путём аннулирования регистрации доменов

Около полудня следующего дня пришла серия уведомлений от 101Domains о том, что регистрации доменов отменяются, деньги возвращаются на карточку, а мой «тикет в суппорте» отвечен и закрыт:



Удивительно, но похоже на то, что адрес abuse@ действительно оказался правильным адресом для решения проблемы. Зайдя в свой аккаунт 101Domain, я обнаружил такое письмо из юридического отдела 101Domain:



Всё было сделано довольно быстро и правильно (хотя обычно я получаю просто письмо с уведомлением вместо ответа юридического отдела). Убедившись, что указанные домены боле недоступны для регистрации, можно было сделать вывод, что ситуация полностью исправлена.

Возможные последствия

Учитывая, что мы зарегистрировали четыре из семи авторитативных серверов имён для доменной зоны .io, мы могли бы изменить/перенаправить записи DNS для всех зарегистрированных доменов .io. Более того, поскольку мы контролировали более половины серверов имён, то DNS-запросы с большей вероятностью шли бы к нам без всяких дополнительных трюков вроде долгих TTL ответов и других, которые ещё больше увеличивают наши шансы. Даже при условии немедленной реакции на такого рода атаку потребуется некоторое время, пока кешированные записи полностью сотрутся из всех мировых DNS-резолверов.

Для исправления ситуации помогло бы то, что в доменной зоне .io поддерживается технология DNSSEC. Это значит, что если ваш резолвер тоже поддерживает эту технологию, то можно защититься от подобных атак с подделкой записей DNS. Но как я говорил в прошлой статье, почти никто не использует DNSSEC. Я редко вижу хоть какую-либо поддержку этой технологии, если только сам специально не настраиваю резолвер.

*Одно замечание, не имеющее отношения к теме: важно не забыть остановить tcpdump после запуска. Если этого не сделать, то у вас хорошие шансы забить всё место на диске VPS данными DNS. Обратите внимание на то, что все записанные для отладочных целей данные DNS очищены от конфиденциальной информации о пользователях.

Защита и безопасность TLD

Я довольно подробно писал, как TLD могут избежать некоторых из этих проблем (для дополнительной информации см. «Выводы и последние мысли» в статье «Маршрут взлома национальной TLD — скрытые риски расширений доменных имён». В будущем я собираюсь составить более обширное руководство, как TLD и операторам расширений доменных имён отслеживать и предотвращать такие ситуации.

Приветы

Я обещал своему другу, что передам ему хакерский приветик в следующем посте в блоге, так что должен выполнить обещание :). Особая благодарность этим ребятам за моральную и «аморальную» поддержку (как говорил единственный и неповторимый HackerBadger).

Привет, HackerBadger, EngSec (вы знаете, кто вы), Hacke the planet, the gibson и всё такое.