[Информационная безопасность, Криптография, Администрирование доменных имен, DNS] Как я угнал национальный домен Демократической Республики Конго (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Примечание: проблема решена. Сейчас национальный домен .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. К счастью, в этом случае всё обошлось.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Фредрик Альмрот
===========Похожие новости:
- [Информационная безопасность, Реверс-инжиниринг] Распаковка исполняемых файлов
- [Информационная безопасность, Разработка игр, Игры и игровые приставки, IT-компании] Инцидент с вирусом-криптовымогателем в CD Projekt Red подорвал работу над обновлениями Cyberpunk 2077
- [Информационная безопасность, Системное администрирование, Программирование, API] Подтверждение номеров телефона без SMS
- [Настройка Linux, Информационная безопасность, Разработка под Linux, Софт, IT-компании] Google начала спонсировать двух разработчиков ядра Linux
- [Анализ и проектирование систем] Удобное шифрование с удостоверяющим центром
- [Информационная безопасность, Разработка под Linux, Софт] Релиз дистрибутива Kali Linux 2021.1
- [Информационная безопасность, Системное администрирование, Сетевые технологии, Сетевое оборудование] Fortinet Single Sign-On. Описание технологии
- [Информационная безопасность, Open source, Браузеры, Медийная реклама] На что соглашается человек, когда разрешает все куки
- [Информационная безопасность] Состоялся Kali Linux 2021.1
- [Настройка Linux, Информационная безопасность, Системное администрирование] AD + Freeradius + Google Autheticator. Установка с нуля для Cisco Anyconnect и не только
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_kriptografija (Криптография), #_administrirovanie_domennyh_imen (Администрирование доменных имен), #_dns, #_itsumma, #_domen (домен), #_kongo (Конго), #_dns, #_dns_hijacking, #_botnet (ботнет), #_fast_flux, #_ssl, #_tls, #_shifrovanie (шифрование), #_mitm, #_wpad, #_blog_kompanii_itsumma (
Блог компании ITSumma
), #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_kriptografija (
Криптография
), #_administrirovanie_domennyh_imen (
Администрирование доменных имен
), #_dns
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:33
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Примечание: проблема решена. Сейчас национальный домен .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 на фишинговый сайт — одна из очевидных возможностей для злоупотреблений, но есть и другие:
Например, я мог написать эксплоит для захвата конкретного домена в зоне .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. К счастью, в этом случае всё обошлось. =========== Источник: habr.com =========== =========== Автор оригинала: Фредрик Альмрот ===========Похожие новости:
Блог компании ITSumma ), #_informatsionnaja_bezopasnost ( Информационная безопасность ), #_kriptografija ( Криптография ), #_administrirovanie_domennyh_imen ( Администрирование доменных имен ), #_dns |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:33
Часовой пояс: UTC + 5