Как стать автором
Обновить
94.96
ITSumma
Эксперты в производительности

Как я угнал национальный домен Демократической Республики Конго

Время на прочтение5 мин
Количество просмотров18K
Автор оригинала: Фредрик Альмрот
Примечание: проблема решена. Сейчас национальный домен .cd уже не делегирует полномочия скомпрометированному нейм-серверу

TL;DR Представьте, что может произойти, если национальный домен верхнего уровня (ccTLD) суверенного государства попадет в чужие руки. Однако я (@Almroot) купил доменное имя, которое указано для делегирования NS в национальном домене Демократической Республики Конго (.cd), и временно принял более 50% всего DNS-трафика для этой TLD. На моём месте мог оказаться злоумышленник, который использовал бы эту возможность для MITM или других злоупотреблений.



Вступление


За неделю до Рождества я решил провести анализ всех записей NS для всех TLD в мире. И моё внимание привлекло одно обстоятельство. У домена scpt-network.com был указан код статуса EPP “redemptionPeriod”. Это означает, что владелец не перечислил деньги за продление домена. Если владелец продолжит игнорировать оплату, то у него отберут собственность — и домен поступит в свободную продажу.

Довольно проблематичная ситуация, поскольку он входит в список NS-серверов, управляющих зоной .cd:

almroot@x:~$ dig NS +trace cd | grep "cd."
cd.			172800	IN	NS	ns-root-5.scpt-network.com.
cd.			172800	IN	NS	igubu.saix.net.
cd.			172800	IN	NS	sangoma.saix.net.
cd.			172800	IN	NS	ns-root-2.scpt-network.com.
cd.			172800	IN	NS	sabela.saix.net.
cd.			172800	IN	NS	ns-root-1.scpt-network.com.

Я решил на всякий случай написать bash-скрипт, который уведомит меня при любом изменении EPP-статуса.

К моему удивлению, примерно через неделю пришло уведомление, что домен перешёл в статус “pendingDelete”.

Я осознавал всю серьёзность ситуации. Доменное имя вскоре выставят на продажу для всех желающих, то есть любой человек может элементарно завладеть нейм-сервером .cd.

Я изменил скрипт — и начал поминутно пинговать регистратора на предмет дальнейших изменений статуса.

Вечером 30 декабря пришло уведомление. Я открыл ноутбук и купил доменное имя, чтобы оно не попало в чужие руки.



Поскольку оставались ещё три записи делегирования на SAIX (South African Internet eXchange, Южноафриканская точка обмена трафиком), национальный домен сохранил работоспособность (хотя скорость резолвинга любых доменов немного уменьшилась).

Завладев scpt-network.com, я мог настроить любой поддомен на своё усмотрение. Например, если создать новый поддомен ns-root-1 с A-записью, которая указывает на IP-адрес 1.3.3.7, то на этот адрес 1.3.3.7 пойдут DNS-запросы для зоны .cd. Любой DNS-ответ на эти запросы будет принят как легитимный.



Если не ответить на запрос, то абонент словит таймаут с кодом состояния SERVFAIL. Это хорошо, потому что при получении такого кода он попытается связаться с любым другим сервером имён (NS record) для этой зоны. Так он в конечном итоге попадёт в одну из нормальных записей SAIX и будет соответствующим образом перенаправлен в нужное место назначения.

Потенциальное влияние


Захват национального домена верхнего уровня суверенного государства имеет серьёзные негативные последствия, особенно если этот домен попадёт в руки киберпреступников или иностранного противника. Демократическая Республика Конго (ДРК) — немаленькая страна. Это примерно 90 миллионов человек, не говоря о многочисленных международных компаниях и организациях, работающих в этой доменной зоне.

Угон DNS-записи TLD целой страны — явление редкое, но не новое. Например, десять лет назад киберпреступники захватили домен бывшего Советского Союза (.su), а в 2015 году вьетнамские сайты Lenovo и Google (.vn) также стали жертвами угона DNS. Перенаправление DNS-трафика с легальных сайтов .cd на фишинговый сайт — одна из очевидных возможностей для злоупотреблений, но есть и другие:

  • Пассивный перехват DNS-трафика
    – для слежки или эксфильтрации данных
  • Создание новых доменных имён «из воздуха»
    – представьте себе возможности для быстрой генерации новых доменных имён с переключением ботнета на новые командные серверы каждые несколько минут, так что их никто не успевает заблокировать (техника fast flux)
  • Атаки с удалённым выполнением кода (RCE) в локальных сетях
    – жертвами станут компании, которые используют протокол WPAD (протокол автоматической настройки прокси)
  • Поддельные DNS-ответы на законные DNS-запросы
    – полный захват корневых доменов в зоне .cd или проведение DDoS-атаки.

Например, я мог написать эксплоит для захвата конкретного домена в зоне .cd. Представьте, что для любых NS-запросов к google.cd я всегда возвращаю ответы ns-root-1.scpt-network.com (вместо этих четырёх: [ns1,ns2,n3,ns4].google.com). Абонент получит такой ответ, и отправит любые последующие DNS-запросы к ns-root-1.scpt-network.com.

Это также заставило меня задуматься: а что, если отвечать на все NS-запросы ссылкой на себя. Тогда для любого запроса, на который ответит 1.3.3.7, все поиски домена в конечном итоге пойдут по этой ссылке. И весь последующий сетевой трафик будет перенаправлен на 1.3.3.7, что может привести к DDoS-атаке.

На самом деле это также повлияет на доступность всей TLD, ведь 50% DNS-ответов станут неправильными. Силу (обеих) DoS-атак можно увеличить путём установки высокого TTL в ответах DNS.

Сделаем ещё один шаг вперёд. Скажем, я конкретно подделываю TXT-записи для сервера google.cd. С помощью поддельных текстовых файлов я обманываю
систему проверки DNS-01 у регистратора Let’s Encrypt — и получаю действительный сертификат для google.cd, после чего эффективно взламываю зашифрованный канал SSL/TLS.

Поскольку я могу контролировать делегирование NS-серверов для любого домена .cd и получить валидные сертификаты, то могу провести MITM-атаку даже если жертва использует SSL/TLS.

Примечание переводчика. Некоторые описанные методы доступны государственным службам, которые контролируют национальные домены в своих странах.

В то время как Google применяет различные контрмеры против таких злоупотреблений, можно с уверенностью сказать, что это не относится ко всем корневым доменам в зоне .cd. Дополнительную информацию о том, как удостоверяющие центры проверяют право собственности на домены, см. в BR 1.7.3.

И последнее, но не менее важное: имея привилегированный доступ на вышестоящий хост с контролем DNS, я могу проникнуть в локальные сети компаний (пример на скриншоте ниже), которые отправляют DNS-запросы для WPAD — можно отслеживать их запросы, подделать ответы и перенаправить жертву для загрузки и выполнения вредоносной конфигурации прокси-сервера на JS. У протокола WPAD своя куча проблем, включая уязвимости RCE, как рассказывали хакеры из команды Project Zero в Google.



Исправление проблемы


7 января 2021 года я связался с административными и техническими контактами, указанными для зоны .cd на странице IANA. Первоначально я хотел передать домен оператору .cd.

Хотя один из контактов ответил и направил меня к коллеге, на момент написания этой статьи я не получил письменного подтверждения, что они устранили проблему. Но вскоре DNS-трафик перенаправили на scpt-network.net.

8 января я также отправил отчёт по программе Internet Bug Bounty в HackerOne, которая предлагает вознаграждение за ответственный взлом инфраструктуры интернета.

Заключение


Угон DNS-сервера несёт крайне негативные последствия, особенно если у злоумышленника плохие намерения. Эта уязвимость затрагивает не только один сайт, поддомен или один корневой домен. Жертвой фишинга, MITM или DDoS может стать абсолютно любой сайт .cd, включая сайты крупных международных компаний, финансовых учреждений и других организаций. А это вторая по численности страна Африки и популярная доменная зона.

На момент написания этой статьи я всё ещё владею доменным именем scpt-network.com хотя делегирование NS-запросов из зоны .cd прекратились примерно 8 января 2021 года после того, как я с ними связался. Эту операцию я провёл для того, чтобы предотвратить захват злоумышленниками доменной зоны Демократической Республики Конго, когда любой желающий мог угнать доменное имя одного из серверов, управляющих ccTLD. К счастью, в этом случае всё обошлось.
Теги:
Хабы:
Всего голосов 42: ↑40 и ↓2+49
Комментарии8

Публикации

Информация

Сайт
www.itsumma.ru
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия
Представитель
ITSumma