Jak przejęcie kodów krajów złamało łańcuch zaufania w internecie

Pamiętam, jak w 2011 roku siedziałem w pozbawionym okien centrum danych, gdy dotarły do nas wieści o DigiNotar. Wtedy pojedynczy skompromitowany urząd certyfikacji w Holandii pozwolił napastnikom na sfabrykowanie fałszywych poświadczeń dla Google. Wyglądało to na fundamentalną zdradę matematyki, która dba o bezpieczeństwo sieci. Przenosimy się do końca 2026 roku, a branża mierzy się z wersją tego samego koszmaru, choć punkt wejścia uległ zmianie. Wielomiliardowy aparat bezpieczeństwa został pokonany przez cyfrowy odpowiednik ślusarza kradnącego klucze uniwersalne z małomiasteczkowego sklepu z narzędziami.

Google niedawno potwierdziło, że napastnicy przejęli trzy domeny najwyższego poziomu z kodem kraju (ccTLD): .gh (Ghana), .sl (Sierra Leone) oraz .as (Samoa Amerykańskie). Zyskując kontrolę nad tymi przestrzeniami nazw, podmioty te zmodyfikowały autorytatywne rekordy DNS dla konkretnych celów o wysokiej wartości. Kontrola ta pozwoliła im obejść automatyczne kontrole walidacji, których urzędy certyfikacji używają do weryfikacji własności. Rezultatem było wystawienie nieautoryzowanych certyfikatów TLS dla kilku domen Google oraz innych dużych globalnych marek. Oto architektoniczny paradoks nowoczesnego bezpieczeństwa: firma może wydawać miliony na model zero trust i sprzętowe klucze bezpieczeństwa, a mimo to jej cyfrowa tożsamość pozostaje uwiązana do administracyjnego bezpieczeństwa odległego rejestru.

Mechanika obejścia kontroli domeny

Aby zrozumieć, dlaczego tak się stało, musimy przyjrzeć się temu, jak strona internetowa udowadnia swoją tożsamość. Gdy organizacja prosi o certyfikat TLS, wystawiający go urząd certyfikacji (CA) musi zweryfikować, czy wnioskodawca rzeczywiście kontroluje domenę. Standardem branżowym w tym zakresie jest walidacja kontroli domeny (Domain Control Validation – DCV). Urząd certyfikacji prosi wnioskodawcę o wykonanie określonego zadania, takiego jak umieszczenie unikalnego pliku pod konkretnym adresem URL lub, co częstsze, utworzenie specyficznego rekordu DNS. Jeśli urząd certyfikacji zobaczy poprawny rekord na autorytatywnych serwerach nazw, wystawia certyfikat.

W tym incydencie napastnicy nie musieli włamywać się do Google. Włamali się do samej infrastruktury TLD. Gdy przejęli kontrolę nad serwerami nazw dla .gh, .sl i .as, skierowali rekordy DNS dla docelowych subdomen na własne serwery. Kiedy urząd certyfikacji przeprowadził automatyczną kontrolę, serwer napastników dostarczył poprawną odpowiedź. Urząd certyfikacji postąpił zgodnie z protokołem, ale rozmawiał z oszustem. System jest cyfrowym skarbcem, który działa tylko wtedy, gdy bramkarz przy drzwiach faktycznie wie, jak wygląda prawdziwy właściciel.

Dlaczego blokady w przeglądarkach to rozwiązanie tymczasowe

Google natychmiast zaktualizowało przeglądarkę Chrome, aby blokować te nieautoryzowane certyfikaty. Jest to środek reaktywny, który chroni miliony użytkowników, ale podkreśla systemową słabość. Proces unieważniania certyfikatu jest notorycznie powolny. Tradycyjne metody, takie jak listy unieważnionych certyfikatów (CRL) lub protokół OCSP (Online Certificate Status Protocol), często zawodzą z powodu obaw o prywatność lub opóźnień sieciowych. W rezultacie twórcy przeglądarek skłaniają się ku wpisanym na sztywno listom blokad, aby zapewnić natychmiastową ochronę.

Z perspektywy ryzyka, ta interwencja jest tylko plastrem. Google przyznało, że interwencje w Chrome nie chronią użytkowników innych przeglądarek, a firma nie może mieć pewności, że zidentyfikowała każdą dotkniętą domenę. Jeśli napastnik posiada poprawnie podpisany certyfikat, którego przeglądarka jeszcze nie zablokowała, może przeprowadzić atak man-in-the-middle. Może przechwytywać ruch, odszyfrowywać wrażliwe dane i prezentować ofierze ikonę „bezpiecznej” kłódki. Integralność połączenia znika, a użytkownik nie ma możliwości zauważenia różnicy.

Ciemna materia sieci korporacyjnej

DNS jest często ciemną materią bezpieczeństwa przedsiębiorstwa. Jest niewidoczny, wszechobecny i często pomijany, dopóki coś się nie zepsuje. Wiele organizacji traktuje swoje relacje z rejestrami TLD jako prostą kwestię rozliczeniową, a nie krytyczną zależność w zakresie bezpieczeństwa. Rejestrując domenę w ccTLD danego kraju, pokładasz ufność w bezpieczeństwie rejestru tego narodu, stabilności jego rządu i jego odporności technicznej.

Patrząc na krajobraz zagrożeń, incydent ten pokazuje, że napastnicy przenoszą się w górę łańcucha dostaw. Zamiast atakować utwardzony obwód, celują w zdecentralizowane komponenty rdzennej infrastruktury internetu. Naruszenie na poziomie TLD jest dyskretne, ponieważ nie uruchamia wewnętrznych alarmów. Serwery organizacji działają poprawnie, pracownicy nie klikają w linki phishingowe, a zapora sieciowa milczy. Mimo to tożsamość marki jest fałszowana gdzie indziej.

Wdrażanie autoryzacji urzędu certyfikacji

Google doradza właścicielom domen publikowanie rekordów DNS Certification Authority Authorization (CAA) jako środka zaradczego. Rekord CAA to oświadczenie o polityce, które informuje świat, które konkretne urzędy certyfikacji są uprawnione do wystawiania certyfikatów dla danej domeny. Jeśli nieuczciwy podmiot spróbuje uzyskać certyfikat od urzędu „A”, ale rekord CAA wymienia tylko urząd „B”, wniosek powinien zostać odrzucony.

Jednak rekordy CAA są skuteczne tylko wtedy, gdy są restrykcyjne i gdy urzędy certyfikacji ich przestrzegają. Co ważniejsze, jeśli napastnik przejmie DNS, może po prostu usunąć lub zmodyfikować rekord CAA przed złożeniem wniosku o fałszywy certyfikat. Google sugeruje, że rekordy te mogą zapobiegać ponownemu wykorzystaniu przez napastników zbuforowanych danych walidacyjnych, ale nie są one cudownym środkiem. Są precyzyjnym narzędziem, które dodaje warstwę trudności dla napastnika, ale nadal polegają na integralności samego systemu DNS.

Znaczenie logów Certificate Transparency

Za kulisami najskuteczniejszym sposobem na wykrycie tego rodzaju aktywności są logi Certificate Transparency (CT). CT to system publicznych, dopisywanych logów, które rejestrują każdy certyfikat TLS wystawiony przez uczestniczące urzędy certyfikacji. Za każdym razem, gdy dla Twojej domeny zostanie sfabrykowany certyfikat, pojawia się on w tych logach.

Mówiąc proaktywnie, każdy zespół ds. bezpieczeństwa powinien monitorować te logi dla swoich domen. Jeśli pojawi się certyfikat z urzędu certyfikacji, którego nie używasz, lub w czasie, w którym o niego nie wnioskowałeś, prawdopodobnie masz do czynienia z trwającym przejęciem. Używam kilku zautomatyzowanych narzędzi, które powiadamiają mnie przez Signal w momencie wystawienia nowego certyfikatu dla dowolnej zarządzanej przeze mnie własności. Ta widoczność kryminalistyczna jest jedynym sposobem na wykrycie przejęcia na poziomie TLD, zanim doprowadzi ono do masowego wycieku danych.

Lekcje z ery DigiNotar

Ten incydent przypomina, że system certyfikatów ma wady systemowe. W 2011 roku włamanie do DigiNotar było cyfrową sytuacją zakładniczą dla mieszkańców Iranu, których ruch był przechwytywany przez ich rząd przy użyciu sfałszowanych certyfikatów. Choć obecne przejęcie TLD wydaje się skupiać na markach i usługach, techniczna podatność jest identyczna. Wciąż używamy scentralizowanego modelu zaufania w zdecentralizowanym świecie.

Szyfrowanie jest niezniszczalnym cyfrowym skarbcem tylko wtedy, gdy klucze są obsługiwane z absolutną integralnością. Gdy infrastruktura walidująca te klucze zostaje naruszona, drzwi skarbca zostają otwarte na oścież. Napastnicy w tym przypadku pokazali, że nie trzeba łamać szyfrowania, aby wygrać. Wystarczy przekonać system, że jest się prawowitym właścicielem skarbca.

Praktyczne wnioski dla liderów bezpieczeństwa

Bezpieczeństwo często polega na zarządzaniu zależnościami, których nie kontrolujesz. Choć nie możesz zabezpieczyć infrastruktury zagranicznego rejestru TLD, możesz kontrolować sposób, w jaki Twoja organizacja reaguje na te zagrożenia.

• Przeprowadź audyt swojego portfela domen i zidentyfikuj, które domeny są zarejestrowane w ccTLD o mniej rygorystycznych protokołach bezpieczeństwa.
• Opublikuj rekordy CAA dla wszystkich domen o krytycznym znaczeniu, aby ograniczyć liczbę urzędów mogących wystawiać poświadczenia.
• Skonfiguruj monitorowanie logów Certificate Transparency w czasie rzeczywistym, aby wyłapać nieautoryzowane wystawienie certyfikatu w ciągu kilku minut.
• Włącz rozszerzenia bezpieczeństwa DNS (DNSSEC) tam, gdzie to możliwe, aby dodać podpisy kryptograficzne do danych DNS, utrudniając przejęcia.
• Zrewiduj swój plan reagowania na incydenty, aby uwzględnić protokół szybkiego unieważniania certyfikatów i koordynacji z dostawcami przeglądarek.

Jako środki zaradcze, kroki te zapewniają, że nawet jeśli rejestr TLD zawiedzie, Twój zespół będzie miał wgląd pozwalający na reakcję, zanim szkody staną się systemowe. Celem jest przejście z postawy reaktywnej na odporną. Bezpieczeństwo nie jest stanem, który się osiąga, lecz procesem, który się utrzymuje.

Źródła:

• Google Security Blog: Tracking Recent TLD Hijacks and Unauthorized Certificates
• NIST Special Publication 800-15: Minimum Interoperability Requirements for PKI Components
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates
• RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record
• MITRE ATT&CK Framework: T1584.001 (Compromise Infrastructure: Domains)

Zastrzeżenie: Niniejszy artykuł służy wyłącznie celom informacyjnym i edukacyjnym i nie zastępuje profesjonalnego audytu cyberbezpieczeństwa ani usługi reagowania na incydenty.