Замочек был настоящим, сайт был поддельным: разбор захвата реестров .gh, .sl и .as

6 октября 2026 года команда безопасности Chrome в Google опубликовала короткий пост с сухим заголовком и тревожным содержанием: злоумышленники взяли под контроль три реестра национальных доменов, ганский .gh, сьерра-леонский .sl и .as Американского Самоа, изменили авторитативные DNS-записи и получили действительные HTTPS-сертификаты для доменов Google и для «нескольких ведущих мировых брендов», которые компания не назвала. Любой, кто попал бы на один из поддельных сайтов, увидел бы в браузере замочек, с которым всё было бы в полном порядке.

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

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

Что случилось с .gh, .sl и .as?

Реестр национального домена представляет собой организацию, которая ведёт главную базу данных всего, что находится под её двухбуквенным доменом: .gh управляется Network Computer Systems в Аккре, .sl оператором связи Sierratel, .as организацией AS Domain Registry. Скомпрометируйте эту базу, и вам не нужно взламывать ни один отдельный сайт, потому что любое имя под TLD можно переделегировать на подконтрольные вам серверы.

Именно это и произошло, по одному реестру за раз. Сертификаты появлялись в публичных логах для имён в .gh 22 сентября, в .sl 25 сентября и в .as 27 сентября, что читается как работа команды, идущей по списку. Google говорит, что злоумышленники «изменили авторитативные DNS-записи и получили несанкционированные HTTPS-сертификаты, покрывающие несколько доменов Google, а также домены, принадлежащие другим организациям», и что собственные системы компании затронуты не были.

Поразительно многое остаётся нераскрытым: как именно были взломаны реестры, кто это сделал, применялся ли хоть один сертификат против реальных пользователей и каков полный список жертв. Ни один из трёх операторов реестров на момент написания не опубликовал заявления. Мы пишем «не раскрыто» там, где дела обстоят именно так, и так же должен поступать каждый материал, который вы читаете.

Как злоумышленники получили действительные сертификаты для доменов Google?

Вежливо попросив. The Hacker News, работая с публичным реестром Certificate Transparency, насчитал не менее 12 сертификатов, покрывающих 7 доменов Google и YouTube, среди них google.com.gh, google.sl, google.as и варианты: 11 выданы Let’s Encrypt и 1 ZeroSSL, все с проверкой домена. Сотрудник Let’s Encrypt подтвердил выдачу и отзыв сертификатов на форуме проекта.

А вот неудобная часть: удостоверяющие центры следовали своим правилам. Google сам написал, что у него «нет оснований полагать, что удостоверяющие центры (CA), выдавшие затронутые сертификаты, сделали что-то не так». Проверка домена просит заявителя доказать контроль над DNS домена, обычно публикацией записи. Злоумышленники и были этим DNS. Каждую автоматическую проверку на своём пути они прошли честно, в том узком смысле, в каком честность понимают машины.

Одна деталь показывает, как выглядит бдительность на этом уровне: в просмотренных записях логов, как минимум с 10 сентября, каждый другой сертификат для google.com.gh, google.sl и google.as приходил от Google Trust Services, собственного удостоверяющего центра Google. Двенадцать сертификатов от двух посторонних CA сами по себе были аномалией, лежащей в публичном логе и ждущей, пока кто-нибудь посмотрит.

Кто это заметил и как это остановили?

Три механизма, в порядке скорости.

Во-первых, Certificate Transparency вообще сделала сертификаты видимыми. С 30 апреля 2018 года Chrome отвергает любой сертификат, не раскрытый в публичных CT-логах, поэтому злоумышленник, которому нужен сертификат, работающий в самом популярном браузере мира, должен заодно вручить миру подписанное признание в его существовании. Публичный счётчик экосистемы перевалил за 2,5 миллиарда записанных сертификатов, а один только Let’s Encrypt пересёк отметку в десять миллионов сертификатов, выданных за один день, в конце сентября 2025 года; найти в этом стоге сена 12 плохих и есть то, ради чего инфраструктура логов существует.

Во-вторых, Chrome заблокировал сертификаты через CRLSets, свой аварийный блок-лист, который доставляется через компонентный апдейтер браузера и вступает в силу без обновления и перезапуска. Команда безопасности Chrome годами доказывает, что онлайн-проверки отзыва отказывают ровно тогда, когда нужны, ведь атакующий посередине может заблокировать саму проверку; блок-лист же путешествует вместе с браузером. Затем Google прочесал данные CT в поисках других жертв, заблокировал и те сертификаты и говорит, что связался с затронутыми организациями, где это было возможно.

В-третьих, медленный путь, который покрывает всех остальных: удостоверяющие центры отозвали все 12 сертификатов, два сертификата .gh и единственный сертификат ZeroSSL 26 сентября, остальные девять 1 октября. Самое короткое окно между появлением сертификата в логе и его смертью составило около полутора суток; самое долгое почти неделю. Собственная оговорка честности Google заслуживает цитаты: «мы не можем гарантировать, что наш анализ выявил каждый затронутый домен, а вмешательства Chrome не защищают надёжно пользователей других браузеров».

Предотвратили бы это DNSSEC или записи CAA?

За последние годы не было более чистой демонстрации того, что эти две аббревиатуры дают и чего не дают.

Сначала DNSSEC. Сверяемся с опубликованной корневой зоной: .gh и .sl не подписаны вовсе, что ставит их в ряд многих ccTLD, так и не внедривших DNSSEC, технологию с 99 процентами внедрения среди реестров Европы, но 65 процентами в Африке. А .as подписан, и его всё равно захватили. DNSSEC позволяет резолверу проверить, что ответ совпадает с тем, что опубликовал реестр. Когда враждебен сам реестр, он публикует данные злоумышленника, вместе с ключами. Подпись под ложью остаётся действительной подписью.

У записей CAA, которые позволяют владельцу домена объявить, какие CA вправе выдавать для него сертификаты, форма тоньше. Во время захвата они бесполезны, потому что запись CAA живёт в том самом DNS, который контролирует атакующий; сам стандарт CAA признаёт, что злоумышленник, способный править DNS, может эту запись удалить. После захвата они значат очень много, потому что по нынешним правилам CA/Browser Forum удостоверяющий центр может повторно использовать завершённую проверку до 200 дней, окно, которое сократится до 100 дней в марте 2027 года и до 10 дней в 2029 году, так что злоумышленник, уже потерявший DNS, мог бы по-прежнему чеканить свежие сертификаты из закэшированных проверок. К 7 октября все семь известных пострадавших доменов Google несли записи CAA, называющие только собственный CA Google. Это замок, который навешивают после именно такого ограбления, и замок настоящий.

Случалось ли такое раньше?

Атаки на реестры и DNS-инфраструктуру давно сложились в жанр, это не новинка. Датированная летопись:

Среди примерно 1,400 доменов корневой зоны есть 316 национальных TLD, каждый привязан к стране или территории, у каждого свои бюджет, управление и уровень безопасности, а некоторыми управляют частные операторы. Собственный уставный доменный орган Ганы годами ведёт публичный спор о том, кто вообще должен управлять .gh. Модель доверия веба отчасти держится на том, что у наименее финансируемой из этих организаций окажется хорошая команда безопасности.

Что бы вы увидели и что на самом деле вас защищает?

Если бы в это окно вас перенаправили на один из поддельных сайтов, вы не увидели бы ничего. Действительный сертификат, обычный замочек, ни одного предупреждения; как сформулировала Ars Technica, обладание такими сертификатами «позволяет злоумышленникам криптографически выдавать себя за затронутую инфраструктуру». Перенаправили ли туда кого-нибудь на самом деле, один из нераскрытых фактов.

Пользователей защитило не что-то, что сделали они сами. Обязательный бумажный след CT выставил сертификаты на свет, CRLSets убили их в Chrome без каких-либо действий со стороны пользователя, а отзыв покрыл остальное. Ещё один слой заслуживает упоминания: нативные приложения с пиннингом ключей. В тоголезском случае 2017 года пиннинг Chrome отверг бы мошеннический сертификат google.tg в любом случае, и приложения самого Google, как и многие банковские, используют пиннинг до сих пор. Эшелонированная оборона здесь не лозунг, а конкретный стек, и в конце сентября несущим был каждый его слой.

Защищает ли от этого VPN?

Честная страница о безопасности отвечает на этот вопрос точно, поэтому вот точный ответ: нет для этого класса атак, да для его более частых родственников, и знать, где какой, в этом и состоит вся игра.

VPN не участвует в TLS. Ваш браузер проверяет сертификаты по своему хранилищу доверия одинаково в любой сети, а эти сертификаты были действительными. Хуже того для любого инструмента ниже DNS по течению: злоумышленники отравили авторитативные записи в самом реестре, поэтому каждый честный резолвер на планете, включая резолверы VPN-провайдера, отдавал ответы злоумышленника. Никакой VPN, наш включительно, этого бы не заблокировал. Остановил это конвейер CT, CRLSet и отзыва, описанный выше.

Что VPN действительно защищает, так это вашу сторону соединения. Во враждебной локальной сети, на мошеннической точке доступа или у вмешивающегося в трафик интернет-провайдера атакующий сидит между вашим устройством и интернетом, подбрасывая DNS-ответы или перенаправляя трафик. VPN переносит разрешение DNS и путь вашего трафика внутрь зашифрованного туннеля, как формулирует гид EFF, скрывая ваш трафик от «вашего интернет-провайдера и владельца локальной сети (например, кафе или отеля)». Это и есть обычная, повседневная поверхность атаки, которую мы разбираем в наших гидах по шифрованию VPN и безопасности публичного Wi-Fi, и это ровно тот слой, которого атакующим реестры даже не пришлось касаться. Эти две защиты дополняют друг друга, а не взаимозаменяемы, поэтому мы и держим отдельную честную страницу о том, что сайты всё ещё видят при включённом VPN.

Что теперь делать владельцам доменов?

Совет Google организациям состоит из двух шагов и подходит компании с тремя доменами так же, как компании с тремя тысячами. Отслеживайте логи Certificate Transparency по каждому принадлежащему вам домену, включая припаркованные и региональные; 12 мошеннических сертификатов лежали в публичных логах днями, видимые любому, кто смотрел. И публикуйте ограничительные записи CAA с именем вашего CA, в идеале с привязкой аккаунта ACME, чтобы даже ваш собственный CA выдавал сертификаты только вашему аккаунту. Свод правил удостоверяющих центров добавляет третий шаг: если появился незапрошенный сертификат, подайте Certificate Problem Report, который отраслевые Baseline Requirements обязывают CA расследовать и отчитаться о первых выводах в течение 24 часов.

Для всех остальных выводы скромнее, но реальны. Держите браузер обновлённым, потому что блок-лист, спасший пользователей Chrome, путешествует вместе с ним. Воспринимайте замочек как то, чем он является, как утверждение о шифровании в пути, а не о том, кто на другом конце. И ставьте каждый инструмент на его собственный слой: система сертификатов аутентифицирует сайты, VPN защищает путь, которым идёт ваш трафик, а сентябрьскому инциденту было нужно, чтобы первая отказала безопасно, тогда как второй в этой игре вообще не участвовал.