Злам інфраструктури зон .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

Про автора

Гіо Берідзе

досвідчений бекенд-розробник

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

Усі публікації автора