Хакеры получили несанкционированные HTTPS-сертификаты для нескольких доменов Google и перенаправляли домены в зонах .GH, .SL и .AS на подконтрольную инфраструктуру. Этот захват DNS-записей не затронул системы Google, но показал неприятную вещь: компрометации стороннего оператора национального домена достаточно, чтобы легитимный адрес начал отдавать чужой контент с формально действующим TLS-сертификатом.
Атаки затронули доменные зоны Ганы, Американского Самоа и Сьерра-Леоне, сообщает BleepingComputer. Помимо ресурсов Google, под удар, по данным компании, попали домены других организаций, включая известные глобальные бренды и широко используемые онлайн-сервисы. Точное число скомпрометированных доменов и личность атакующих не раскрываются.
Сценарий выглядел вполне буднично для инфраструктурной атаки. Злоумышленник получил доступ к авторитетным DNS-записям через внешних операторов реестров ccTLD и изменил их. После этого он мог направить трафик домена на собственные серверы и пройти проверку владения доменом у центра сертификации: например, разместив нужную TXT-запись для ACME-проверки.
В результате атакующий получает сертификат, который браузер обычно считает корректным, и может выдать себя за владельца сайта. Для посетителя это особенно опасно: адресная строка выглядит привычно, соединение защищено HTTPS, а за доменом может оказаться фишинговая страница, вредоносный скрипт или любая другая отдача. HTTPS защищает канал до указанного сервера, но не спасает, если DNS уже указал браузеру на сервер злоумышленника.
Google заблокировала обнаруженные сертификаты для Chrome через CRLSet — механизм экстренного отзыва недоверенных или скомпрометированных сертификатов. Компания также связалась с выпустившими их центрами сертификации, добилась отзыва и проверила журналы Certificate Transparency. По этим логам были найдены дополнительные сертификаты, предположительно связанные с той же кампанией; их тоже проактивно заблокировали в Chrome.
Это важная деталь для команд, которые привыкли считать сертификат в браузере окончательным признаком безопасности сайта. В данном случае центры сертификации, по оценке Google, не действовали неправильно: они увидели DNS-подтверждение, которое на тот момент контролировал атакующий. Слабым звеном оказался уровень выше — управление авторитетной зоной и доверие к подрядчику, который обслуживает национальный реестр.
Пользователям Chrome ничего дополнительно делать не нужно, однако защита не универсальна. Google прямо предупреждает, что могла обнаружить не все пострадавшие домены, а CRLSet распространяется на Chrome и не гарантирует защиты в других браузерах. Для корпоративной ИБ это повод не ограничиваться проверкой замочка в браузере и учитывать риск компрометации DNS-провайдера или оператора реестра в моделях угроз.
Владельцам доменов Google рекомендует мониторить Certificate Transparency-логи по всему портфелю, включая неиспользуемые и припаркованные домены, а также настроить ограничивающие CAA-записи. CAA не остановит выпуск сертификата во время активного захвата DNS-записей: атакующий уже управляет зоной. Но после восстановления контроля эта настройка может помешать получить новые сертификаты за счёт ранее закэшированной проверки домена, если разрешить только нужные центры сертификации, учётные записи ACME и способы валидации.
Инцидент с .GH, .SL и .AS напоминает, что цепочка доверия веба длиннее, чем домен, CDN и сертификат. Чем больше бизнес переносит в DNS — от верификации сервисов до маршрутизации и почтовых политик, — тем дороже становится ошибка или взлом на уровне реестра. После такого захвата DNS-записей вопрос уже не в том, есть ли у компании сертификат, а в том, кто способен незаметно доказать владение её доменом от её имени.