Замочок був справжнім, сайт був підробленим: розбір захоплення реєстрів .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 захищає шлях, яким іде ваш трафік, а вересневому інциденту було потрібно, щоб перша відмовила безпечно, тоді як другий у цій грі взагалі не брав участі.