Kłódka była prawdziwa, strona fałszywa: przejęcia rejestrów .gh, .sl i .as wyjaśnione

6 października 2026 roku zespół bezpieczeństwa Chrome w Google opublikował krótki wpis o suchym tytule i alarmującej treści: napastnicy przejęli kontrolę nad trzema rejestrami domen krajowych, ghańskim .gh, .sl Sierra Leone i .as Samoa Amerykańskiego, zmienili autorytatywne rekordy DNS i uzyskali ważne certyfikaty HTTPS dla domen Google oraz dla “kilku czołowych globalnych marek”, których nie wymienił. Każdy, kto trafiłby na jedną z fałszywych stron, zobaczyłby w przeglądarce kłódkę, z którą wszystko było w porządku.

Ten incydent warto zrozumieć porządnie, bo trafia dokładnie w punkt, w którym model mentalny bezpieczeństwa sieci większości ludzi jest błędny. Kłódka nie znaczy “to jest prawdziwa strona”. Znaczy coś znacznie węższego, a pod koniec września różnica między tymi dwoma znaczeniami stała się działającym atakiem.

Jedna definicja niesie całą tę stronę: certyfikat z walidacją domeny dowodzi tylko jednego, że w chwili wydania wnioskodawca kontrolował DNS domeny. Kiedy rejestr ponad DNS-em zostaje skradziony, złodziej jest, dla każdej automatycznej kontroli na świecie, właścicielem.

Co się stało z .gh, .sl i .as?

Rejestr domeny krajowej to organizacja prowadząca nadrzędną bazę danych wszystkiego pod swoją dwuliterową domeną: .gh obsługuje Network Computer Systems z Akry, .sl telekom Sierratel, a .as AS Domain Registry. Skompromituj tę bazę, a nie musisz włamywać się na żadną pojedynczą stronę, bo możesz przedelegować dowolną nazwę pod TLD na serwery, które kontrolujesz.

Tak właśnie się stało, rejestr po rejestrze. Certyfikaty pojawiły się w publicznych logach dla nazw .gh 22 września, .sl 25 września i .as 27 września, co czyta się jak ekipę odhaczającą listę. Google mówi, że napastnicy “zmodyfikowali autorytatywne rekordy DNS i uzyskali nieautoryzowane certyfikaty HTTPS obejmujące kilka domen Google, a także domeny należące do innych organizacji”, oraz że jego własne systemy nie zostały tknięte.

Zaskakująco wiele pozostaje nieujawnione: jak włamano się do rejestrów, kto to zrobił, czy jakikolwiek certyfikat został użyty przeciwko prawdziwym użytkownikom i pełna lista ofiar. Żaden z trzech operatorów rejestrów nie opublikował oświadczenia do chwili pisania tego tekstu. Piszemy “nie ujawniono” tam, gdzie taki jest stan rzeczy, i tak samo powinna robić każda relacja, którą czytacie.

Jak napastnicy zdobyli ważne certyfikaty dla domen Google?

Grzecznie prosząc. The Hacker News, pracując na publicznym rejestrze Certificate Transparency, doliczył się co najmniej 12 certyfikatów obejmujących 7 domen Google i YouTube, wśród nich google.com.gh, google.sl, google.as i warianty: 11 wydał Let’s Encrypt, 1 ZeroSSL, wszystkie z walidacją domeny. Pracownik Let’s Encrypt potwierdził wydanie i unieważnienia na forum projektu.

A oto niewygodna część: urzędy certyfikacji przestrzegały swoich reguł. Sam Google napisał, że “nie ma powodu sądzić, by urzędy certyfikacji (CA), które wydały dotknięte certyfikaty, zrobiły cokolwiek złego”. Walidacja domeny prosi wnioskodawcę o dowód kontroli nad DNS-em domeny, zwykle przez opublikowanie rekordu. Napastnicy byli DNS-em. Każdą automatyczną kontrolę, z którą się zetknęli, przeszli uczciwie, w tym wąskim sensie, w jakim maszyny rozumieją uczciwość.

Jeden szczegół pokazuje, jak wygląda czujność na tej warstwie: w przejrzanych zapisach logów, sięgających co najmniej 10 września, każdy inny certyfikat dla google.com.gh, google.sl i google.as pochodził od Google Trust Services, własnego CA Google. Dwanaście certyfikatów od dwóch niepowiązanych urzędów było samo w sobie anomalią, siedzącą w publicznym logu i czekającą, aż ktoś spojrzy.

Kto to wykrył i jak to zatrzymano?

Trzy mechanizmy, w kolejności szybkości.

Po pierwsze, Certificate Transparency w ogóle uczyniło certyfikaty widocznymi. Od 30 kwietnia 2018 roku Chrome odrzuca każdy certyfikat nieujawniony w publicznych logach CT, więc napastnik, który chce certyfikatu działającego w najpopularniejszej przeglądarce świata, musi też wręczyć światu podpisane przyznanie, że ten certyfikat istnieje. Publiczny licznik ekosystemu przekracza 2,5 miliarda zapisanych certyfikatów, a sam Let’s Encrypt przekroczył dziesięć milionów certyfikatów wydanych jednego dnia pod koniec września 2025 roku; znalezienie 12 złych w tym stogu siana jest dokładnie tym, po co istnieje infrastruktura logów.

Po drugie, Chrome zablokował certyfikaty przez CRLSets, swoją awaryjną listę blokad, która dociera przez aktualizator komponentów przeglądarki i działa bez aktualizacji ani restartu. Zespół bezpieczeństwa Chrome od lat przekonuje, że kontrole unieważnień online zawodzą dokładnie wtedy, kiedy ich potrzebujesz, bo napastnik siedzący pośrodku może zablokować samą kontrolę; zamiast tego lista blokad podróżuje z przeglądarką. Google przeszukał potem dane CT w poszukiwaniu kolejnych ofiar, zablokował także tamte certyfikaty i mówi, że skontaktował się z dotkniętymi organizacjami tam, gdzie mógł.

Po trzecie, wolna ścieżka, która chroni całą resztę: urzędy unieważniły wszystkie 12 certyfikatów, dwa certyfikaty .gh i pojedynczy certyfikat ZeroSSL 26 września, pozostałe dziewięć 1 października. Najkrótsze okno między pojawieniem się certyfikatu w logu a jego śmiercią wyniosło około półtora dnia; najdłuższe prawie tydzień. Klauzula uczciwości Google zasługuje na cytat: “nie możemy zagwarantować, że nasza analiza zidentyfikowała każdą dotkniętą domenę, ani interwencje Chrome nie chronią niezawodnie użytkowników innych przeglądarek”.

Czy DNSSEC albo rekordy CAA by temu zapobiegły?

Ten incydent to najczystsza od lat demonstracja tego, co te dwa akronimy dają, a czego nie.

Najpierw DNSSEC. Sprawdzając opublikowaną strefę root: .gh i .sl nie są podpisane w ogóle, co stawia je wśród wielu ccTLD, które nigdy nie wdrożyły DNSSEC, technologii z 99 procentami adopcji wśród rejestrów w Europie, ale 65 procentami w Afryce. A .as jest podpisane i i tak zostało przejęte. DNSSEC pozwala resolverowi zweryfikować, że odpowiedź zgadza się z tym, co opublikował rejestr. Kiedy sam rejestr jest wrogi, publikuje dane napastnika, z kluczami włącznie. Podpis pod kłamstwem to nadal ważny podpis.

Rekordy CAA, którymi właściciel domeny deklaruje, które CA mogą dla niej wydawać certyfikaty, mają subtelniejszy kształt. Podczas przejęcia są bezużyteczne, bo rekord CAA żyje w tym samym DNS-ie, który kontroluje napastnik; sam standard CAA przyznaje, że napastnik mogący edytować DNS może rekord usunąć. Po przejęciu znaczą bardzo wiele, bo urzędy mogą ponownie używać ukończonej walidacji do 200 dni według obecnych reguł CA/Browser Forum, okna, które spada do 100 dni w marcu 2027 roku i do 10 dni w 2029, więc napastnik, który stracił DNS, mógłby nadal wybijać świeże certyfikaty z zapamiętanych kontroli. Do 7 października wszystkie siedem znanych domen-ofiar Google nosiło rekordy CAA wskazujące wyłącznie własny CA Google. To zamek, który montuje się po tym konkretnym włamaniu, i to prawdziwy.

Czy to już się kiedyś zdarzyło?

Ataki na rejestry i infrastrukturę DNS to gatunek, nie nowość. Datowany zapis:

Wśród około 1400 domen w strefie root jest 316 krajowych TLD, każda przypisana do kraju lub terytorium, każda z własnym budżetem, zarządzaniem i poziomem bezpieczeństwa, a niektóre prowadzone przez prywatnych operatorów. Ghański ustawowy organ ds. domeny spędził lata w publicznym sporze o to, kto w ogóle powinien operować .gh. Model zaufania sieci opiera się, po części, na tym, że najsłabiej finansowana z tych organizacji ma dobry zespół bezpieczeństwa.

Co byś zobaczył i co naprawdę cię chroni?

Gdyby ktoś przekierował cię w tym oknie na jedną z fałszywych stron, nie zobaczyłbyś nic. Ważny certyfikat, normalna kłódka, żadnego ostrzeżenia; jak ujął to Ars Technica, posiadanie takich certyfikatów “pozwala napastnikom kryptograficznie podszywać się pod dotkniętą infrastrukturę”. Czy ktokolwiek faktycznie został tam przekierowany, to jeden z nieujawnionych faktów.

To, co ochroniło użytkowników, nie było niczym, co zrobił użytkownik. Obowiązkowy ślad papierowy CT ujawnił certyfikaty, CRLSets zabiły je w Chrome bez żadnego działania z twojej strony, a unieważnienie objęło resztę. Jedna warstwa więcej zasługuje na wzmiankę: aplikacje natywne, które przypinają swoje klucze. W sprawie Togo z 2017 roku pinning Chrome odrzuciłby fałszywy certyfikat google.tg niezależnie od wszystkiego, a własne aplikacje Google i wiele aplikacji bankowych przypina klucze do dziś. Obrona w głąb nie jest tu sloganem; to konkretny stos, a pod koniec września każda jego warstwa dźwigała ciężar.

Czy VPN chroni przed tym?

Uczciwa strona o bezpieczeństwie odpowiada na to pytanie precyzyjnie, więc oto precyzyjna odpowiedź: nie dla tej klasy ataku, tak dla jej częstszych kuzynów, a wiedza, który jest który, to cała gra.

VPN nie uczestniczy w TLS. Twoja przeglądarka waliduje certyfikaty wobec swojego magazynu zaufania identycznie w każdej sieci, a te certyfikaty były ważne. Gorzej dla każdego narzędzia poniżej DNS: napastnicy zatruli autorytatywne rekordy w rejestrze, więc każdy uczciwy resolver na świecie, łącznie z resolverami dostawcy VPN, serwował odpowiedzi napastnika. Żaden VPN, z naszym włącznie, by tego nie zablokował. Zatrzymał to opisany wyżej potok CT, CRLSet i unieważnień.

To, czego VPN broni, to twoja strona połączenia. We wrogiej sieci lokalnej, na fałszywym hotspocie lub u manipulującego ISP napastnik siedzi między twoim urządzeniem a internetem, wstrzykując odpowiedzi DNS lub przekierowując ruch. VPN przenosi twoje rozwiązywanie DNS i ścieżkę ruchu do zaszyfrowanego tunelu, jak ujmuje to przewodnik EFF, ukrywając twój ruch przed “twoim ISP i właścicielem sieci lokalnej (jak kawiarnia czy hotel)”. To jest powszechna, codzienna powierzchnia ataku, ta, którą omawiamy w naszych przewodnikach po szyfrowaniu VPN i bezpieczeństwie publicznego Wi-Fi, i to jest dokładnie ta warstwa, której napastnicy rejestrów nigdy nie musieli dotknąć. Te dwie ochrony są komplementarne, nie wymienne, i dlatego też prowadzimy osobną uczciwą stronę o tym, co strony wciąż widzą przy włączonym VPN.

Co powinni teraz zrobić właściciele domen?

Rada Google dla organizacji to dwa kroki i stosuje się tak samo do firmy z trzema domenami, jak do tej z trzema tysiącami. Monitorujcie logi Certificate Transparency dla każdej posiadanej domeny, łącznie z zaparkowanymi i regionalnymi; 12 fałszywych certyfikatów leżało w publicznych logach całymi dniami, widocznych dla każdego, kto patrzył. I publikujcie restrykcyjne rekordy CAA wskazujące wasz CA, najlepiej z powiązaniem konta ACME, by nawet wasz własny CA wydawał tylko na wasze konto. Regulamin CA dodaje trzeci krok: jeśli pojawi się niezamówiony certyfikat, złóżcie Certificate Problem Report, który branżowe Baseline Requirements każą urzędowi zbadać i zaraportować pierwsze ustalenia w ciągu 24 godzin.

Dla wszystkich pozostałych wnioski są mniejsze, ale realne. Aktualizujcie przeglądarkę, bo lista blokad, która uratowała użytkowników Chrome, podróżuje razem z nią. Traktujcie kłódkę jako to, czym jest, oświadczenie o szyfrowaniu w tranzycie, nie o tym, kto jest po drugiej stronie. I umieszczajcie każde narzędzie na jego własnej warstwie: system certyfikatów uwierzytelnia strony, VPN chroni ścieżkę, którą biegnie twój ruch, a wrześniowy incydent wymagał, by pierwszy zawiódł bezpiecznie, podczas gdy drugi w ogóle nie brał udziału w grze.