Как захват национальных доменов верхнего уровня подорвал цепочку доверия в интернете

Я помню, как сидел в дата-центре без окон в 2011 году, когда появились новости о DigiNotar. Тогда компрометация одного центра сертификации в Нидерландах позволила злоумышленникам выпускать поддельные учетные данные для Google. Это казалось фундаментальным предательством математики, которая обеспечивает безопасность интернета. Перенесемся в конец 2026 года: индустрия сталкивается с версией того же кошмара, хотя точка входа сместилась. Многомиллиардный аппарат безопасности был побежден цифровым эквивалентом слесаря, укравшего мастер-ключи в хозяйственном магазине маленького городка.

Google недавно подтвердил, что злоумышленники захватили три национальных домена верхнего уровня (ccTLD): .gh (Гана), .sl (Сьерра-Леоне) и .as (Американское Самоа). Получив контроль над этими пространствами имен, субъекты изменили авторитетные записи DNS для конкретных высокоценных целей. Этот контроль позволил им обойти автоматизированные проверки валидации, которые центры сертификации используют для подтверждения владения. Результатом стала выдача несанкционированных TLS-сертификатов для нескольких доменов Google и других крупных мировых брендов. В этом заключается архитектурный парадокс современной безопасности: компания может тратить миллионы на Zero Trust и аппаратные ключи безопасности, однако ее цифровая идентичность остается привязанной к административной безопасности удаленного реестра.

Механика обхода контроля домена

Чтобы понять, почему это произошло, мы должны посмотреть на то, как веб-сайт доказывает свою подлинность. Когда организация запрашивает TLS-сертификат, выдающий его Центр Сертификации (CA) должен убедиться, что заявитель действительно контролирует домен. Индустриальным стандартом для этого является Domain Control Validation (DCV). CA просит заявителя выполнить определенную задачу, например, разместить уникальный файл по определенному URL-адресу или, что чаще, создать специальную DNS-запись. Если CA видит правильную запись на авторитетных серверах имен, он выдает сертификат.

В данном инциденте злоумышленникам не нужно было взламывать Google. Они взломали саму инфраструктуру TLD. Как только они получили контроль над серверами имен для .gh, .sl и .as, они направили DNS-записи целевых поддоменов на свои собственные серверы. Когда CA выполнял автоматическую проверку, сервер злоумышленников предоставлял правильный ответ. CA идеально следовал своему протоколу, но он разговаривал с самозванцем. Система представляет собой цифровое хранилище, которое работает только в том случае, если вышибала у двери действительно знает, как выглядит настоящий владелец.

Почему блокировки в браузерах — это временная мера

Google немедленно обновил Chrome, чтобы заблокировать эти несанкционированные сертификаты. Это реактивная мера, которая защищает миллионы пользователей, но она подчеркивает системную слабость. Процесс отзыва сертификата печально известен своей медлительностью. Традиционные методы, такие как списки отзыва сертификатов (CRL) или протокол онлайн-статуса сертификата (OCSP), часто терпят неудачу из-за проблем с конфиденциальностью или задержек в сети. В результате разработчики браузеров перешли к жестко закодированным черным спискам для обеспечения немедленной защиты.

С точки зрения рисков, это вмешательство — лишь пластырь. Google признал, что меры в Chrome не защищают пользователей других браузеров, и компания не может быть уверена, что выявила каждый затронутый домен. Если злоумышленник владеет валидно подписанным сертификатом, который браузер еще не заблокировал, он может провести атаку «человек посередине» (man-in-the-middle). Он может перехватывать трафик, расшифровывать конфиденциальные данные и показывать жертве значок «безопасного» замка. Целостность соединения утрачена, и у пользователя нет возможности заметить разницу.

Темная материя корпоративной сети

DNS часто называют темной материей корпоративной безопасности. Он невидим, вездесущ и часто игнорируется до тех пор, пока что-то не сломается. Многие организации относятся к своим отношениям с TLD как к простому вопросу оплаты счетов, а не как к критически важной зависимости безопасности. Когда вы регистрируете домен в национальном TLD, вы доверяете безопасности реестра этой страны, стабильности ее правительства и технической устойчивости.

Глядя на ландшафт угроз, этот инцидент демонстрирует, что злоумышленники продвигаются выше по цепочке поставок. Вместо того чтобы атаковать укрепленный периметр, они нацеливаются на децентрализованные компоненты основной инфраструктуры интернета. Взлом на уровне TLD скрытен, так как он не вызывает внутренних тревог. Серверы организации в порядке, сотрудники не кликают по фишинговым ссылкам, а брандмауэр молчит. Тем не менее, идентичность бренда подделывается в другом месте.

Внедрение авторизации центра сертификации (CAA)

Google советует владельцам доменов публиковать DNS-записи Certification Authority Authorization (CAA) в качестве контрмеры. Запись CAA — это заявление о политике, которое сообщает миру, каким именно центрам сертификации разрешено выдавать сертификаты для домена. Если злоумышленник попытается получить сертификат в CA «A», но в записи CAA указан только CA «B», запрос должен быть отклонен.

Однако записи CAA эффективны только в том случае, если они носят ограничительный характер и если центры сертификации их соблюдают. Что еще важнее, если злоумышленник захватывает DNS, он может просто удалить или изменить запись CAA перед запросом поддельного сертификата. Google предполагает, что эти записи могут помешать злоумышленникам повторно использовать кэшированные данные валидации, но они не являются панацеей. Это точечный инструмент, который добавляет уровень трения для злоумышленника, но он по-прежнему полагается на целостность самой системы DNS.

Важность логов прозрачности сертификатов (Certificate Transparency)

За кулисами самым эффективным способом обнаружения подобной активности являются логи Certificate Transparency (CT). CT — это система общедоступных логов, работающих только на добавление, которые фиксируют каждый TLS-сертификат, выпущенный участвующими центрами сертификации. Каждый раз, когда для вашего домена создается сертификат, он появляется в этих логах.

Говоря проактивно, каждая команда безопасности должна отслеживать эти логи для своих доменов. Если сертификат появляется от центра сертификации, который вы не используете, или в то время, когда вы его не запрашивали, скорее всего, вы наблюдаете процесс захвата домена. Я использую несколько автоматизированных инструментов, которые оповещают меня через Signal в тот момент, когда выпускается новый сертификат для любого управляемого мной ресурса. Эта криминалистическая видимость — единственный способ обнаружить захват на уровне TLD до того, как он приведет к масштабной утечке данных.

Уроки эпохи DigiNotar

Этот инцидент напоминает о том, что система сертификатов имеет системные недостатки. В 2011 году взлом DigiNotar стал ситуацией цифрового заложничества для жителей Ирана, чей трафик перехватывался их правительством с помощью поддельных сертификатов. Хотя текущий захват TLD, похоже, сосредоточен на брендах и сервисах, техническая уязвимость идентична. Мы все еще используем централизованную модель доверия в децентрализованном мире.

Шифрование — это неразрушимое цифровое хранилище только в том случае, если с ключами обращаются с абсолютной честностью. Когда инфраструктура, проверяющая эти ключи, скомпрометирована, дверь хранилища остается широко открытой. Злоумышленники в данном случае показали, что для победы не нужно взламывать шифрование. Нужно лишь убедить систему в том, что вы являетесь законным владельцем хранилища.

Практические выводы для руководителей по безопасности

Безопасность часто заключается в управлении зависимостями, которые вы не контролируете. Хотя вы не можете обезопасить инфраструктуру иностранного реестра TLD, вы можете контролировать то, как ваша организация реагирует на эти риски.

• Проведите аудит своего портфеля доменов и определите, какие из них зарегистрированы в ccTLD с менее строгими протоколами безопасности.
• Опубликуйте записи CAA для всех критически важных доменов, чтобы ограничить список центров, которые могут выдавать учетные данные.
• Настройте мониторинг логов Certificate Transparency в реальном времени, чтобы ловить несанкционированную выдачу в течение нескольких минут.
• Включите расширения безопасности DNS (DNSSEC), где это возможно, чтобы добавить криптографические подписи к вашим DNS-данным, что усложнит захват.
• Пересмотрите свой план реагирования на инциденты, включив в него протокол быстрого отзыва сертификатов и координации с разработчиками браузеров.

В качестве контрмеры эти шаги гарантируют, что даже если реестр TLD даст сбой, у вашей команды будет возможность среагировать до того, как ущерб станет системным. Цель состоит в том, чтобы перейти от реактивной позиции к устойчивой. Безопасность — это не состояние, которого вы достигаете, а процесс, который вы поддерживаете.

Источники:

• Google Security Blog: Tracking Recent TLD Hijacks and Unauthorized Certificates
• NIST Special Publication 800-15: Minimum Interoperability Requirements for PKI Components
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates
• RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record
• MITRE ATT&CK Framework: T1584.001 (Compromise Infrastructure: Domains)

Отказ от ответственности: Данная статья носит исключительно информационный и образовательный характер и не заменяет профессиональный аудит кибербезопасности или услуги по реагированию на инциденты.