company_banner

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

Автор оригинала: Фредрик Альмрот
  • Перевод
Примечание: проблема решена. Сейчас национальный домен .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. К счастью, в этом случае всё обошлось.
ITSumma
Собираем безумных людей и вместе спасаем интернет

Комментарии 8

    +1
    Почему они не размещают корневые сервера в своей зоне (в данном случае .cd)? В любом случае пока их DNS находятся в зоне .com, у них нет никаких гарантий что кто то (например регистратор домена) не перенаправит их DNS-трафик на чужие сервера
      +2

      Аутсорсер настраивал, наверно. Сказал: "Потом поменяете".

        0
        Так русские корневые сервера тоже находятся под .net доменом
          +1
          Проблемы нет, если своевременно оплачивают продление этого домена. Либо своевременно убирают ссылки на удаляемые домены.
        +4

        Хотя в статье полно откровенной чуши и фантазии, что характерно для англоязычного сегмента, статья наполнена весьма неиллюзорными возможностями для взлома и дестабилизации интернета.
        Я только вот задумался как именно национальные домены делегируются на другие сервера по именам. Не все домены верхнего уровня обслуживаются на конревых DNS, а только ограниченный список?

          +1

          Отвечу сам себе. Разделение происходит не на top level domain а на вполне конкретных именах, которые таки резолвятся, а не делегируются корневыми серверами и им в помощь еще распространяются заготовленные кеш файлы Root zone file.

          0
          В свое время, когда msk.ru spb.ru поддерживались Релкомом и были бесплатными, поддерживались они из рук вон плохо. Для подтверждения переделегирования домена Релком направлял письмо-подтверждение на существующий e-mail из soa-записи. Если владелец домена не поддерживал зону, считалось, что он согласен с переводом. Так удалось заполучить парочку доменов (в оправдание скажу, что домены были забраны у киберсквоттеров и переданы более релевантному владельцу).
            +1
            Про домен su по ссылке наброс совсем пещерный.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое