W systemie, który pomaga przeglądarkom rozpoznawać prawdziwe strony internetowe, wykryto poważną lukę. Osiem kluczy prywatnych indyjskiej firmy eMudhra — urzędu certyfikacji wystawiającego cyfrowe certyfikaty — można było odzyskać z publicznie dostępnych danych. W praktyce oznaczało to możliwość tworzenia fałszywych certyfikatów, które mogłyby wyglądać wiarygodnie.
Jak działają certyfikaty stron
Gdy użytkownik odwiedza witrynę, przeglądarka sprawdza jej certyfikat, by potwierdzić, że łączy się z właściwym serwisem. Certyfikaty wystawiają zaufane urzędy, takie jak eMudhra, a ich autentyczność potwierdzają klucze prywatne. Można je porównać do pieczęci: jeśli ktoś zdobędzie jej kopię, może próbować podszywać się pod strony uznawane za bezpieczne.
Według doniesień eMudhra wystawiła ponad 60 milionów certyfikatów. Skala działalności firmy sprawiła, że ujawnienie problemu wzbudziło niepokój, choć nie ma informacji o atakach przeprowadzonych z wykorzystaniem tych kluczy.
Klucze, które można było odgadnąć
Badacze wskazali, że część kluczy miała być oparta na bardzo małych liczbach, takich jak 4, 56 czy 115, zamiast na odpowiednio długich, losowych wartościach. Badacz bezpieczeństwa Scott Helme poinformował, że udało mu się odzyskać wszystkie osiem kluczy z publicznych certyfikatów w czasie krótszym niż sekunda. Według jego ustaleń problem mógł istnieć już od kwietnia 2025 roku.
O luce poinformowano producentów przeglądarek 17 października. Badacz o pseudonimie Wayne zademonstrował jej działanie, podpisując wiadomość ostrzegawczą przy użyciu zakwestionowanych kluczy. Z kolei Mozilla wskazała, że przy odpowiednich warunkach fałszywe certyfikaty mogłyby posłużyć do podszywania się pod zaufane witryny i przechwytywania lub modyfikowania danych użytkowników.
Przyczyna błędu nie została w pełni wyjaśniona. Z informacji przytoczonych przez badaczy wynika, że eMudhra miała wskazać na usterkę w skrypcie konfiguracyjnym używanym podczas generowania kluczy.
Ten incydent pokazuje, jak poważne konsekwencje może mieć błąd na etapie generowania kluczy. Nawet sprawdzone mechanizmy bezpieczeństwa nie pomogą, jeśli ich podstawowe elementy są przewidywalne. Dlatego ważne są zarówno szybkie aktualizacje, jak i regularna kontrola procedur związanych z zarządzaniem kluczami.
Przeglądarki zareagowały, ale problem nie kończy się na nich
Po zgłoszeniu producenci szybko zaczęli blokować wadliwe certyfikaty. Mozilla wprowadziła zabezpieczenie w ciągu kilku godzin, a Chrome zrobił to tego samego dnia. Apple i Microsoft zaktualizowały swoje zabezpieczenia w kolejnych dniach, a eMudhra unieważniła certyfikaty.
Największe ryzyko może dotyczyć jednak programów, które nie sprawdzają, czy certyfikat został unieważniony. Scott Helme poinformował, że w jego testach narzędzia i środowiska takie jak curl, Python, Node.js, Go i Java akceptowały spreparowany certyfikat dla API Stripe. W chwili publikacji dostępne były poprawki dla Go, pakietu certyfikatów certifi dla Pythona oraz webpki-roots dla Rusta; aktualizacja Node.js była jeszcze oczekiwana.
Przeczytaj także: Prywatne klucze, a nie smart kontrakty, odpowiadają za 40% strat w krypto – co się zmienia. Artykuł wyjaśnia, dlaczego ochrona kluczy ma kluczowe znaczenie dla bezpieczeństwa użytkowników.
Co to oznacza dla użytkowników kryptowalut?
Nie jest to problem związany wyłącznie z kryptowalutami. Jak wyjaśnił Mudit Gupta, dyrektor ds. technologii w Polygon Labs, luka może umożliwić atak typu „man-in-the-middle”, zwłaszcza wobec osób korzystających z przestarzałego lub niezałatanego oprogramowania.
Potencjalnie zagrożone mogą być również boty giełdowe, skrypty handlowe i zaplecza portfeli łączące się z API. W teorii osoba kontrolująca ruch w tej samej sieci mogłaby próbować przechwycić lub zmienić komunikację. Dotychczas nie odnotowano jednak ataków wymierzonych w użytkowników kryptowalut z użyciem tych kluczy.
Aktualizowanie przeglądarek, systemów i bibliotek ogranicza ryzyko. Incydent przypomina też, że bezpieczeństwo internetu zależy nie tylko od silnych algorytmów, lecz także od prawidłowego generowania i zarządzania kluczami.
Jeśli klucze faktycznie dało się odzyskać z publicznych certyfikatów w sekundę, to nie jest „słaby algorytm”, tylko katastrofalne generowanie kluczy. Przeglądarki zablokują certyfikaty, ale co ze starymi klientami i bibliotekami, które nie sprawdzają unieważnień?
Czy dobrze rozumiem, że aktualizacja samej przeglądarki nie wystarczy, jeśli skrypt łączy się np. przez bibliotekę w Pythonie albo Node? Mam kilka usług chodzących na starszym runtime i zastanawiam się, co konkretnie sprawdzić.
Niepokoi mnie, że przy firmie, która wystawiła dziesiątki milionów certyfikatów, błąd mógł siedzieć od miesięcy. Samo unieważnienie certyfikatów to jedno, ale chciałabym zobaczyć porządny audyt i wyjaśnienie, jak taki skrypt trafił na produkcję.
„Mniej niż sekunda” brzmi sensacyjnie, ale przy wartościach typu 4 czy 56 to chyba nie jest kwestia mocy obliczeniowej. Ciekawsze byłoby, czy wadliwe klucze powstały przez błąd w generatorze, czy ktoś jeszcze używał tego samego skryptu w innych miejscach.
Ludzie skupiają się na kryptowalutach, a problem jest znacznie bardziej przyziemny: każdy klient API, który ufa takiemu certyfikatowi, może być potencjalnie narażony. Sprawdziłam swoje biblioteki i część i tak była dawno nieaktualizowana, więc jest przy okazji trochę sprzątania.