Przejęcia rejestrów ccTLD zagroziły domenom Google i zaufaniu do HTTPS

securitybeztabu.pl 11 godzin temu

Wprowadzenie do problemu / definicja

Przejęcie domeny na poziomie rejestru ccTLD należy do najpoważniejszych incydentów związanych z infrastrukturą DNS. W takim scenariuszu napastnik nie atakuje pojedynczej organizacji, ale uzyskuje możliwość wpływania na autorytatywne rekordy całej krajowej domeny najwyższego poziomu. Oznacza to, iż zagrożone mogą być wszystkie podmioty korzystające z danego rozszerzenia, w tym duże marki technologiczne, instytucje i operatorzy usług internetowych.

W ostatnim incydencie problem objął strefy .gh, .sl oraz .as. Skutkiem było nie tylko przekierowanie zaufania w warstwie DNS, ale również możliwość uzyskania nieautoryzowanych certyfikatów HTTPS dla części domen działających w tych przestrzeniach nazw.

W skrócie

Atakujący przejęli kontrolę nad wybranymi elementami infrastruktury ccTLD i zmodyfikowali autorytatywne odpowiedzi DNS. Dzięki temu mogli przejść proces walidacji kontroli nad domeną i uzyskać certyfikaty TLS wyglądające na w pełni legalne.

Wśród podmiotów dotkniętych incydentem znalazły się również wybrane domeny Google. Firma podkreśliła, iż problem nie wynikał z włamania do jej własnej infrastruktury ani z oczywistego błędu po stronie urzędów certyfikacji, ale z naruszenia zaufania do warstwy DNS, na której opiera się standardowy proces walidacji domen.

Kontekst / historia

Model bezpieczeństwa HTTPS od lat bazuje między innymi na potwierdzeniu, iż podmiot wnioskujący o certyfikat faktycznie kontroluje daną domenę. W praktyce odbywa się to zwykle przez mechanizmy Domain Control Validation, które wykorzystują odpowiedzi DNS, pliki HTTP lub inne metody technicznego potwierdzenia kontroli.

Jeżeli jednak napastnik przejmie kontrolę nad autorytatywnym DNS albo nad ścieżką, przez którą przebiega walidacja, może doprowadzić do wystawienia certyfikatu bez udziału prawowitego właściciela domeny. Ryzyko rośnie szczególnie wtedy, gdy incydent nie dotyczy pojedynczego operatora, ale całej strefy krajowej.

Dodatkowy kontekst stanowi zmiana podejścia Google do domen krajowych. Choć firma od pewnego czasu ogranicza ich znaczenie i przekierowuje część ruchu do google.com, niektóre regionalne domeny przez cały czas funkcjonują i pozostają częścią powierzchni ataku.

Analiza techniczna

Techniczny rdzeń incydentu sprowadzał się do modyfikacji autorytatywnych rekordów DNS w przejętych strefach ccTLD. Taki stan pozwala atakującemu odpowiedzieć na zapytania walidacyjne w sposób korzystny dla siebie, a następnie wykazać przed urzędem certyfikacji pozorną kontrolę nad domeną.

To ważne rozróżnienie: urząd certyfikacji może działać zgodnie z procedurą, a mimo to wydać certyfikat nieuprawnionemu podmiotowi, jeżeli źródło prawdy o własności domeny zostało wcześniej naruszone. W tym przypadku problemem nie była kryptografia TLS, ale zależność pomiędzy DNS a procesem wydawania certyfikatów.

Istotną rolę odegrały logi Certificate Transparency, które umożliwiły wykrycie nietypowych emisji certyfikatów. Publiczna widoczność takich wpisów pozwala zespołom bezpieczeństwa szybciej identyfikować nadużycia i oceniać skalę problemu, choćby jeżeli samo wystawienie certyfikatu formalnie przeszło standardową walidację.

Dodatkowe ryzyko wiąże się z czasowym cache’owaniem wyników walidacji przez niektóre podmioty w ekosystemie certyfikatów. jeżeli wcześniejsze potwierdzenie kontroli nad domeną może zostać wykorzystane ponownie, napastnik może próbować uzyskać kolejne certyfikaty choćby po częściowym opanowaniu sytuacji przez właściciela domeny.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją takiego incydentu jest możliwość prowadzenia wiarygodnych ataków man-in-the-middle z użyciem poprawnie wyglądających certyfikatów HTTPS. Dla użytkownika końcowego połączenie może przez cały czas wyglądać na szyfrowane i bezpieczne, mimo iż ruch trafia do infrastruktury kontrolowanej przez napastnika.

Ryzyko obejmuje między innymi kradzież danych logowania, przejęcie sesji, podszywanie się pod usługi korporacyjne, przechwycenie ruchu API oraz nadużycia wobec systemów zależnych od zaufania do TLS. Skutki mogą objąć nie tylko przeglądarki, ale też aplikacje mobilne, biblioteki programistyczne, integracje B2B i procesy automatyczne.

Warto również podkreślić, iż reakcja jednego dostawcy systemu nie eliminuje zagrożenia globalnie. Blokada podejrzanych certyfikatów po stronie przeglądarki ogranicza ekspozycję części użytkowników, ale nie chroni całego ekosystemu klientów i usług.

Rekomendacje

Organizacje korzystające z domen w strefach ccTLD powinny traktować monitoring DNS i Certificate Transparency jako stały element programu bezpieczeństwa. Szczególnie ważne jest objęcie nadzorem także domen regionalnych, zaparkowanych i rzadziej używanych, ponieważ to właśnie one bywają najsłabiej monitorowane.

wdrożyć ciągłe monitorowanie logów Certificate Transparency dla wszystkich domen organizacji,
publikować restrykcyjne rekordy CAA ograniczające wystawianie certyfikatów do zatwierdzonych CA,
zweryfikować historię wydanych certyfikatów i anomalii walidacyjnych,
przeprowadzić przegląd integralności delegacji DNS i konfiguracji stref,
uruchomić alertowanie dla zmian DNS oraz nowych wpisów CT,
przygotować procedury szybkiego unieważniania certyfikatów,
uwzględnić scenariusz przejęcia operatora DNS lub rejestru ccTLD w planach reagowania na incydenty.

Dobrym kierunkiem jest również centralizacja zarządzania certyfikatami oraz ograniczanie zależności od domen, które nie są krytyczne biznesowo, ale zwiększają złożoność krajobrazu bezpieczeństwa.

Podsumowanie

Incydent związany z przejęciem stref .gh, .sl i .as pokazuje, iż bezpieczeństwo HTTPS nie zależy wyłącznie od siły szyfrowania ani od poprawności działania urzędów certyfikacji. Jednym z kluczowych ogniw pozostaje kontrola nad DNS oraz integralność procesu walidacji domen.

Dla zespołów bezpieczeństwa to wyraźny sygnał, iż monitoring CT, restrykcyjne rekordy CAA i ścisły nadzór nad domenami ccTLD powinny być traktowane jako podstawowe mechanizmy obronne. W przeciwnym razie legalnie wyglądające certyfikaty mogą zostać użyte jako narzędzie skutecznego podszywania się pod zaufane usługi.