Przejęcie rejestrów .gh, .sl i .as umożliwiło wystawienie fałszywych certyfikatów dla domen Google

Wprowadzenie do problemu / definicja

Incydent związany z przejęciem kontroli nad rejestrami domen krajowych najwyższego poziomu .gh, .sl i .as pokazuje, że bezpieczeństwo HTTPS nie zależy wyłącznie od właścicieli domen i urzędów certyfikacji. Kluczową rolę odgrywają również operatorzy rejestrów oraz integralność infrastruktury DNS, która stanowi podstawę procesu potwierdzania kontroli nad domeną.

W analizowanym przypadku atakujący uzyskali możliwość ingerencji w autorytatywne dane dla wybranych przestrzeni nazw, a następnie wykorzystali ten dostęp do pozyskania nieautoryzowanych certyfikatów TLS dla domen powiązanych z Google i YouTube. Taki scenariusz tworzy realne ryzyko podszywania się pod legalne usługi w ramach pozornie bezpiecznego połączenia szyfrowanego.

W skrócie

Atak objął trzy rejestry ccTLD: .gh, .sl oraz .as.
Wystawiono co najmniej 12 nieautoryzowanych certyfikatów dla siedmiu domen związanych z Google i YouTube.
Certyfikaty pojawiły się w logach Certificate Transparency między 22 a 27 września 2026 roku.
Większość certyfikatów wystawiło Let’s Encrypt, a jeden ZeroSSL.
Google poinformowało, że nie doszło do włamania do jego systemów wewnętrznych.
Chrome zablokował wykryte certyfikaty przy użyciu mechanizmu CRLSet, a wystawcy rozpoczęli ich unieważnianie.

Kontekst / historia

Model wydawania certyfikatów domenowo walidowanych opiera się na założeniu, że podmiot wnioskujący o certyfikat jest w stanie udowodnić kontrolę nad domeną. W praktyce odbywa się to najczęściej przez mechanizmy DNS, HTTP lub TLS-ALPN. Jeśli jednak napastnik przejmie kontrolę nad autorytatywnymi rekordami DNS lub uzyska wpływ na infrastrukturę rejestru, może tymczasowo spełnić wymagania walidacyjne i doprowadzić do wydania ważnego certyfikatu przez zaufany urząd certyfikacji.

W tym incydencie zdarzenia rozwijały się etapami. Najpierw odnotowano certyfikaty dla przestrzeni .gh, następnie dla .sl, a później dla .as. Publiczne logi CT wskazują, że incydent objął między innymi nazwy google.com.gh, google.sl, google.as, youtube.com.gh, youtube.sl i youtube.as. To pokazuje, że przejęcie zewnętrznego elementu łańcucha zaufania może zostać wykorzystane do ataku na globalnie rozpoznawalne marki bez bezpośredniego naruszenia ich własnych systemów.

Zdarzenie wpisuje się w szerszą debatę na temat ograniczeń modelu Web PKI. Nawet poprawnie działający urząd certyfikacji może wystawić certyfikat nieuprawnionemu podmiotowi, jeśli proces walidacji został oparty na chwilowo przejętej kontroli nad DNS. Z tego powodu branża od lat rozwija monitoring logów CT, polityki CAA oraz ograniczenia dotyczące okresów ważności i ponownego wykorzystania danych walidacyjnych.

Analiza techniczna

Techniczny przebieg ataku najprawdopodobniej polegał na przejęciu możliwości zarządzania rekordami autorytatywnymi dla określonych stref ccTLD. Po uzyskaniu takiego dostępu napastnik mógł modyfikować odpowiedzi DNS dla wybranych domen, co pozwoliło przejść proces Domain Control Validation wymagany przez urząd certyfikacji. Oznacza to, że sam urząd certyfikacji nie musiał zostać bezpośrednio skompromitowany, ponieważ walidacja mogła wyglądać poprawnie z punktu widzenia standardowych procedur.

W logach Certificate Transparency odnotowano co najmniej 12 certyfikatów wystawionych dla siedmiu nazw domenowych. Jedenaście z nich wydało Let’s Encrypt, a jeden ZeroSSL. Wszystkie były certyfikatami domenowo walidowanymi, a część obejmowała wpisy typu wildcard, co zwiększa potencjalny zakres nadużycia i umożliwia objęcie większej liczby subdomen.

Istotnym elementem reakcji była szybka odpowiedź po stronie Google i ekosystemu Chrome. Wykryte certyfikaty zostały zablokowane za pomocą CRLSet, co ograniczyło możliwość ich wykorzystania wobec użytkowników tej przeglądarki. Równolegle rozpoczęto procedury unieważnienia u wystawców, aby zmniejszyć ryzyko także dla innych przeglądarek, aplikacji i klientów TLS.

Warto zaznaczyć, że logi CT nie muszą odzwierciedlać pełnej skali zdarzenia. Jeśli monitoring obejmował jedynie wybrane domeny lub ograniczony zestaw nazw, rzeczywista liczba wystawionych certyfikatów mogła być większa. To szczególnie ważne dla organizacji utrzymujących domeny regionalne, pomocnicze, zaparkowane lub rzadko używane.

Z perspektywy architektury zaufania istotne jest także ryzyko ponownego wykorzystania wcześniejszej walidacji domeny przez urząd certyfikacji. Jeżeli atakujący skutecznie przeszedł walidację w czasie aktywnego przejęcia DNS, w niektórych modelach operacyjnych może powstać czasowe okno umożliwiające uzyskanie kolejnego certyfikatu bez pełnej ponownej walidacji. To jeden z powodów, dla których coraz większe znaczenie mają restrykcyjne rekordy CAA i skracanie okresów reuse.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem takiego incydentu jest możliwość przeprowadzenia ataku man-in-the-middle z użyciem formalnie poprawnego certyfikatu TLS. Użytkownik końcowy może widzieć aktywne szyfrowanie HTTPS i brak ostrzeżeń przeglądarki, mimo że połączenie jest zestawiane z infrastrukturą kontrolowaną przez atakującego.

W praktyce otwiera to drogę do przechwytywania danych, sesji, tokenów uwierzytelniających, a także do modyfikowania treści przesyłanych do ofiary. Skala ryzyka rośnie dodatkowo wtedy, gdy wystawione certyfikaty obejmują wildcardy, ponieważ mogą one posłużyć do podszywania się pod wiele usług działających w ramach jednej domeny.

Ryzyko nie dotyczy wyłącznie użytkowników Chrome. Inne przeglądarki i aplikacje, które nie otrzymały jeszcze informacji o unieważnieniu albo nie stosują porównywalnych mechanizmów blokowania, mogły pozostawać bardziej narażone. Incydent pokazuje również problem systemowy dla organizacji działających w mniej popularnych domenach krajowych, gdzie bezpieczeństwo zależy od całego łańcucha dostaw obejmującego rejestry, rejestratorów i dostawców DNS.

Rekomendacje

Organizacje powinny wdrożyć stały monitoring logów Certificate Transparency dla wszystkich posiadanych domen, w tym regionalnych, technicznych i nieaktywnych. Każdy alert dotyczący nowego certyfikatu dla nieoczekiwanej nazwy powinien uruchamiać formalną procedurę reagowania.

Niezbędne jest również stosowanie restrykcyjnych rekordów CAA, które ograniczają listę uprawnionych urzędów certyfikacji do absolutnego minimum. Jeśli urząd wspiera przypisanie certyfikacji do konkretnego konta klienta, warto wykorzystywać także ten mechanizm jako dodatkową barierę przeciwko nadużyciom.

Zespoły bezpieczeństwa powinny traktować DNS jako zasób krytyczny. Obejmuje to silne uwierzytelnianie administratorów, segmentację dostępu, monitoring zmian stref, ochronę kont rejestratorów oraz regularny przegląd zależności związanych z zarządzaniem domenami. Tam, gdzie to możliwe, warto wdrożyć procedury out-of-band dla zatwierdzania zmian w konfiguracji stref.

W przypadku wykrycia nieautoryzowanego certyfikatu konieczne jest natychmiastowe zgłoszenie problemu do właściwego CA, analiza logów DNS i CT, weryfikacja integralności rekordów autorytatywnych oraz ocena potencjalnego wpływu na użytkowników. Reakcja powinna objąć także ustalenie, czy certyfikat został wykorzystany operacyjnie, czy jedynie pozyskany.

Długofalowo organizacje powinny przygotować się na dalsze zmiany w politykach Web PKI, w tym skracanie okresów ważności certyfikatów i okresów ponownego wykorzystania danych walidacyjnych. To zwiększa znaczenie automatyzacji zarządzania certyfikatami oraz szybkiego wykrywania anomalii w obszarze DNS i TLS.

Podsumowanie

Przejęcie rejestrów .gh, .sl i .as pokazuje, że naruszenie zewnętrznego elementu infrastruktury internetowej może wystarczyć do uzyskania zaufanych certyfikatów dla domen powiązanych z dużą globalną marką. W tym przypadku nie doszło do kompromitacji systemów Google, lecz do nadużycia modelu zaufania opartego na potwierdzaniu kontroli nad domeną.

Dla obrońców najważniejsze wnioski są jednoznaczne: monitoring Certificate Transparency, rygorystyczne polityki CAA, ochrona dostępu do DNS oraz szybkie procedury reagowania pozostają kluczowe dla ograniczania skutków podobnych incydentów. Atak ten przypomina, że bezpieczeństwo domeny trzeba analizować nie tylko lokalnie, ale również w kontekście całego łańcucha zależności.