Klucz certyfikatu eMudhra był liczbą 4, więc każdy mógł podrobić dowolną stronę

Tajnym kluczem jednego z certyfikatów potwierdzających tożsamość strony internetowej okazała się liczba cztery. Nie długi, losowy ciąg cyfr zaczynający się od czwórki, lecz po prostu 4. Siedem kolejnych kluczy tej samej indyjskiej firmy certyfikującej, eMudhra, było niewiele większych. Każdy, kto wszedł w ich posiadanie, mógł wystawić certyfikat dla dowolnej strony — od banku po pocztę elektroniczną — który oprogramowanie ufające eMudhra uznałoby za prawdziwy.

To właśnie te certyfikaty sprawdza kłódka widoczna w przeglądarce. Mając podrobiony certyfikat, napastnik, który przechwyci ruch między użytkownikiem a internetem — na przykład w kawiarni, przez zhakowany router albo w nieprzyjaznej sieci krajowej — może podszyć się pod prawdziwą stronę i odczytywać lub zmieniać przesyłane dane. Chrome, Firefox, Safari i platformy Microsoftu przestały już ufać ośmiu certyfikatom. Wiele innych programów na waszych urządzeniach nadal im ufa.

Standardowy klucz tego rodzaju to losowa liczba o długości około 384 bitów, co daje mniej więcej 10 do potęgi 115 możliwych wartości. Klucze eMudhra miały od 3 do 8 bitów: 4, 56, 66, 115, 155, 156, 230 i 237 — wyliczył Ars Technica. Badacz bezpieczeństwa Scott Helme napisał, że odzyskał wszystkie osiem z publicznie dostępnych certyfikatów na swoim laptopie, „a zajęło to mniej niż sekundę”. Dodał później, że Anthropic’s Claude zrobił to samo po otrzymaniu jednego polecenia.

Nikt nie musiał niczego kraść. Jak wynika z wyjaśnień przekazanych Mozilli przez eMudhra, o których napisał BleepingComputer, winny był błąd w skrypcie używanym podczas generowania kluczy: tworzył on drugi, słaby zestaw, a pracownicy omyłkowo wybrali właśnie te klucze, bo ich etykiety wyglądały podobnie. Firma, która twierdzi, że wydała ponad 60 milionów certyfikatów cyfrowych, poinformowała Mozillę, że większość wadliwych certyfikatów pośrednich nigdy nie trafiła do użytku i nie znalazła dowodów na to, by posłużyły do podpisania certyfikatów dla użytkowników końcowych. Unieważniła wszystkie osiem i wstrzymała wydawanie certyfikatów w ramach wadliwego certyfikatu głównego.

Przeglądarki to łatwiejsza część problemu. Chrome, Firefox i Safari po cichu przesyłają użytkownikom listy unieważnionych certyfikatów, a ponadto wymagają, by każdy certyfikat pojawił się w publicznych dziennikach Certificate Transparency. Żaden certyfikat strony internetowej powiązany z tymi kluczami nigdy się tam nie znalazł, więc aktualne przeglądarki nie były domyślnie narażone. Problem tkwi we wszystkim innym. Narzędzia wiersza poleceń, takie jak curl, języki programowania, na przykład Python, Node i Go, klienci VPN, kontenery Docker oraz urządzenia inteligentnego domu mają własne listy zaufanych urzędów certyfikacji. Rzadko sprawdzają unieważnienia i ignorują dzienniki przejrzystości. Helme stworzył fałszywy certyfikat dla interfejsu płatności Stripe i odkrył, że curl, Python i Node akceptowały go na każdym testowanym komputerze z Linuksem i macOS.

„To będzie gigantyczna akcja porządkowa, większa niż Heartbleed” — powiedział Ars Technica Filippo Valsorda, opiekun kodu kryptograficznego języka Go, nawiązując do luki w OpenSSL, której usuwanie trwało latami. Spodziewa się „bardzo, bardzo długiego ogona” urządzeń IoT, kontenerów Docker, zapomnianych komputerów z Linuksem i nieaktualizowanych narzędzi, które zawierają własne kopie zaufanych certyfikatów głównych. Wykorzystanie tych kluczy nadal wymaga napastnika mającego dostęp do trasy, którą przebiega ruch sieciowy, co oznacza, że w zasięgu są rządy, osoba kontrolująca przejętą sieć biurową albo operator publicznego hotspotu. Signal, WhatsApp i WireGuard, które nie opierają szyfrowania na tych certyfikatach, nie są zagrożone — zauważa Ars.

Klucze można było odzyskać od chwili utworzenia certyfikatów w kwietniu 2025 roku, a więc przez około 17 miesięcy. Nie da się ustalić, czy ktoś wykorzystał je przeciwko oprogramowaniu, które pomija kontrolę w dziennikach przejrzystości. W maju 2025 roku każdy certyfikat został też podpisany krzyżowo przez główny certyfikat AAA Certificate Services firmy Sectigo, co zwiększyło liczbę systemów, które mu ufały.

Większości użytkowników wystarczy zainstalować aktualizacje. Badacz zgłosił problem producentom przeglądarek 17 października. Tego samego dnia Mozilla zablokowała certyfikaty w Firefoxie w ciągu trzech godzin, a 20 października udostępniła Firefox 158.0.1, nowe wydania ESR oraz NSS 3.131.1, które usuwa główny certyfikat eMudhra. Apple dodało zabezpieczenia 19 października, a Microsoft 20 października — wynika z serwisu poświęconego incydentowi, prowadzonego przez inżyniera Mozilli Dennisa Jacksona. Ars zauważył jednak, że w chwili publikacji Edge na Windowsie 10 nadal łączył się z serwerami testowymi. Dostępne są już Go 1.27.3 i 1.26.10, pip 26.2.2, uv 0.13.4 oraz certifi 2026.10.19. Cloudflare zaktualizował aplikacje WARP i 1.1.1.1, a dystrybucje Linuksa wciąż udostępniają nowe pakiety ca-certificates. Wbudowany w macOS curl nadal ufa tym kluczom, dopóki plik z certyfikatami nie zostanie ręcznie zmodyfikowany.

Chrome potwierdził, że w wersji 43 usunie główny certyfikat eMudhra ze swojego Chrome Root Store. Dopóki wszystkie urządzenia nie zostaną zaktualizowane, osiem bitów dzieli mnóstwo codziennie używanego oprogramowania od przekonującej podróbki dowolnej strony.

Tagi: cyberbezpieczeństwo, Mozilla, Firefox, certyfikaty TLS, eMudhra, Google Chrome