Взлом инфраструктуры зон .gh, .sl и .as позволил выпустить чужие TLS-сертификаты

Злоумышленники скомпрометировали инфраструктуру национальных доменных зон .gh, .sl и .as, изменили DNS-записи и получили несанкционированные HTTPS-сертификаты для чужих доменов, в том числе доменов Google. Как пишет Хабр 7 октября 2026 года, системы самой Google не были взломаны: атака затронула инфраструктуру доменных зон.

Что произошло с DNS и сертификатами

Атаки затронули зоны Ганы, Сьерра-Леоне и Американского Самоа. Злоумышленники меняли авторитетные DNS-записи, после чего получили сертификаты для ряда доменов Google и других организаций. Источник не уточняет, как именно проходила проверка контроля над доменами в этих случаях. Важнее другое: под угрозой оказались домены в затронутых зонах, хотя владельцам каждого отдельного сайта не обязательно было терять контроль над своим хостингом.

Google не видит оснований считать, что центры сертификации нарушили правила. Это не история о взломе центра сертификации: проблема возникла на уровне инфраструктуры, от которой зависит управление доменными именами. Наличие сертификата само по себе не означает, что его запросил законный владелец домена.

Анализ открытых журналов Certificate Transparency (CT) выявил сертификаты, связанные и с другими организациями, включая крупные бренды и популярные онлайн-сервисы. Их затронутость Google оценивает как предположительную; делать из этих записей вывод о последствиях для каждого сервиса без дополнительной проверки нельзя.

Для ресурсов Google использование несанкционированных сертификатов заблокировали в Chrome через CRLSets. Компания также взаимодействовала с центрами сертификации для их отзыва и превентивно заблокировала в Chrome соответствующие сертификаты для других организаций. По заявлению Google, пользователям Chrome ничего дополнительно делать не нужно. Для владельцев доменов браузерная блокировка не заменяет проверки собственных записей и выпущенных сертификатов.

Что проверить владельцам сайтов

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

Владельцам доменов в .gh, .sl и .as Google советует отдельно просмотреть недавние записи CT и поискать неожиданные сертификаты. Это способ обнаружить уже состоявшийся выпуск, а не предотвратить изменение DNS. Если доменов много, смысл мониторинга теряется там, где часть портфеля осталась за пределами списка.

Другая мера — ограничительные записи CAA в DNS. Они задают, каким центрам сертификации разрешено выпускать сертификаты для домена; Google отдельно рекомендует привязывать ограничения к учётным записям ACME. Здесь есть предел защиты: при активном захвате DNS такая запись не остановит выпуск сертификата. Зато после восстановления контроля над DNS строгая политика CAA помогает помешать повторному выпуску.

Дело в том, что центры сертификации могут сохранять результат проверки контроля над доменом (DCV) и использовать его позже. Если ограничить в CAA допустимые учётные записи и методы проверки, злоумышленник не сможет опереться на ранее полученный результат после прекращения перехвата. По оценке Google, CAA также способна полностью предотвратить некоторые атаки, связанные с маршрутизацией или HTTP. Это не универсальная замена защите DNS, а мера с конкретной областью действия.

Google планирует работать над сокращением срока действия сертификатов и ограничением повторного использования результатов DCV; сроков этих изменений материал не называет. Отдельно Cloudflare объявила о намерении стать публичным центром сертификации и выпускать бесплатные TLS-сертификаты через ACME с обязательной поддержкой ACME Renewal Information. Это план об организации выпуска и продления сертификатов, а не мера против описанного захвата доменных зон.

Моё мнение: проверять нужно не только сервер

Я бы не сводил вывод к совету включить мониторинг CT и успокоиться. Журналы помогают заметить выпуск, CAA ограничивает определённые сценарии, Chrome блокирует известные ему сертификаты. Но ни одна из этих мер не делает скомпрометированную инфраструктуру DNS надёжной. Когда предлагают очередную «защиту сертификатов», я бы сначала спрашивал, на каком этапе атаки она вообще работает.

Для меня здесь неприятнее всего зависимость за пределами приложения и хостинга. Можно аккуратно защищать сервис, но не видеть, что происходит с его доменным именем. Я бы начал с полного перечня доменов, в том числе припаркованных, а затем настроил наблюдение за CT и ограничения CAA. Иначе получится тщательная проверка одного адреса при слепой зоне на остальных.

Источники

Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.

1. Хакеры научились получать поддельные сертификаты TLS для Google и других крупных сервисов habr.com

Об авторе

Гио Беридзе

опытный backend-разработчик

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

Все публикации автора