Przejdź do treści

Klucze urzędu certyfikacji eMudhra dało się odtworzyć w milisekundy

Adam Marzec
Okładka artykułu o kompromitacji kluczy CA eMudhry: 8 pośrednich urzędów certyfikacji z kluczami wielkości jednego bajtu, okno ekspozycji 17 miesięcy

17 października badacz występujący jako Wayne wysłał raport do Apple, Google, Microsoft, Mozilli i samej eMudhry: klucze prywatne ośmiu pośrednich urzędów certyfikacji (CA) tej firmy da się odzyskać z samych publicznych certyfikatów. Klucze na krzywej P-384 okazały się liczbami tak małymi, że każda mieści się na jednym bajcie. Scott Helme, autor bloga o bezpieczeństwie, odtworzył wszystkie osiem na laptopie w mniej niż sekundę. Jeden z nich to liczba 4, inny 56, jeszcze inny 115.

Przeglądarki poradziły sobie w godziny, na długo przed publicznym ogłoszeniem. Reszta świata TLS, czyli curl, skrypty w Pythonie i Node, pipeline’y CI/CD i urządzenia IoT, do rewokacji nie zagląda i musiała czekać na aktualizacje własnych magazynów zaufania. Przez ponad 17 miesięcy ktokolwiek, kto spojrzał na te certyfikaty, mógł wyciągnąć z nich klucz podpisujący i nikt by się o tym nie dowiedział.

Najważniejsze informacje

KwestiaStan na 22.10.2026
Co się stałoKlucze prywatne 8 pośrednich CA eMudhry do odzyskania z certyfikatów w mniej niż sekundę
Ile kluczy6 pośrednich TLS (DV, OV i EV, po dwie generacje) i 2 do podpisywania kodu
Algorytm i błądECDSA na P-384, klucze to liczby 4-237 zamiast losowych 384 bitów
ZgłoszenieSobota 17.10.2026, raport do pięciu adresatów, Mozilla potwierdziła dowód tego samego dnia
Reakcja przeglądarekChrome CRLset 17.10 wieczorem, Firefox OneCRL domknięty 22:59 UTC, NSS bez roota od 20.10
Publiczne ogłoszenieWtorek 20.10.2026, Mozilla publikuje i usuwa root eMudhry z NSS
Kto bezpiecznyZaktualizowane przeglądarki (Chrome, Firefox, Safari, Edge)
Kto zagrożonyKlienty spoza przeglądarek bez sprawdzania rewokacji, Windows code signing, firmware IoT

Jak jeden bajt zastępuje klucz

Klucz prywatny w kryptografii krzywych eliptycznych to po prostu liczba d, a klucz publiczny, który wędruje do certyfikatu, powstaje, gdy mnożymy ją przez stały punkt krzywej. W jedną stronę liczy się to błyskawicznie, w drugą, od klucza publicznego do d, nie powinno być wykonalne. Ten model działa pod jednym warunkiem: d musi być gigantyczną losową liczbą, dla P-384 którąś z około 10¹¹⁵ możliwości.

Klucze eMudhry mają według Helmego 47 bajtów zer i jeden bajt z wartością na końcu. Wystarczy liczyć: generujemy kolejne mnożenia punktu bazowego 1, 2, 3 i zatrzymujemy się, gdy wynik zgadza się z kluczem w certyfikacie. Skrajny przypadek to 255 kroków, stąd milisekundy na zwykłym sprzęcie.

Najgorsze jest to, że nic w tych certyfikatach nie zdradza problemu. Klucz publiczny pochodzący od d = 4 jest poprawnym punktem krzywej i przechodzi wszystkie strukturalne testy. Helme sprawdził 16 certyfikatów powiązanych ze sprawą, po dwie ścieżki dla każdego z ośmiu kluczy, raz pod rootem eMudhry, raz pod cross-signingiem Sectigo, i wszystkie padły od razu. Podrobiony certyfikat wygląda dla klienta jak prawdziwy, bo kryptograficznie jest równie dobry.

Kto jest bezpieczny, a kto nie

Zaktualizowane przeglądarki wyszły z tej historii bez szwanku. Chrome i Firefox zablokowały pośrednie certyfikaty bezpośrednio, oba wymagają Certificate Transparency, Safari też. Przez te klucze nie wystawiono żadnego certyfikatu końcowego i nic nie wylądowało w logach CT, więc atak na przeglądarkę nie miał prawa się udać.

Wszystko, co nie jest przeglądarką, ma domyślnie trzy cechy: ufa pakietowi CA leżącemu na dysku, nie sprawdza rewokacji i nie sprawdza CT. Helme przetestował to podrobionym certyfikatem dla api.stripe.com, nazwy wysokiej wartości. curl wypisał SSL certificate verify ok, Python dokończył handshake, Node odpowiedział authorized: true. Na Windows CryptoAPI przyjęła łańcuch bez włączonego sprawdzania rewokacji, a z włączonym tylko jedna z dwóch ścieżek wróciła jako odwołana. Nie testowaliśmy tego u siebie, opis u Helmego jest jednak kompletny i powtarzalny. Osobne ryzyko to podpisywanie kodu: dwa z ośmiu certyfikatów to pośrednie CA do code signing, zaufane bezpośrednio przez Windows, więc malware z takim podpisem wygląda jak program od prawdziwego wydawcy. Dochodzą urządzenia IoT z firmware zamrożonym do wygaśnięcia certyfikatów w lipcu 2039 roku.

Co pękło w ceremonii

eMudhra opisała przyczynę w zgłoszeniu na Bugzilli Mozilli. Osiem pośrednich nie narodziło się z ataku, tylko 30 kwietnia 2025 roku podczas ceremonii generowania kluczy na sprzętowych modułach HSM (wg eMudhry „Ultimaco HSMs”, zgodnych z FIPS 140-2 Level 3). Procedura miała testową odchyłkę: krok zawijania i odwijania kluczy przygotowany pod eksport hierarchii do centrów danych w Europie i USA. Błąd w skrypcie stworzył przy okazji drugą, słabą parę kluczy, a ponieważ etykiety obu par były podobne, człowiek przy tworzeniu CSR sięgnął po niewłaściwe. Słabe klucze trafiły do certyfikatów podpisanych rootem, a ich żądania pojechały też do Sectigo pod cross-signing.

eMudhra odwołała wszystkie osiem certyfikatów 18 października z powodem caCompromise (jej komunikat datuje ten krok na 19 października), Apple zablokowała je u siebie 19 października, Microsoft 20 października. W wtorek 20 października Mozilla opublikowała ogłoszenie, wydała NSS 3.131.1 bez roota emSign ECC Root CA - G3 i poza harmonogramem nowe wersje Firefoksa dla osób z niestandardowymi ustawieniami. Wpis o usunięciu roota ma trafić do stabilnych wersji Chrome razem z Chrome Root Store v43 we wtorek 27 października, do tego czasu Chrome przykrywa sprawę listą CRLset. Android wymagał jeszcze drugiej poprawki (Firefox 158.0.2), bo część profili nie zaaplikowała listy blokującej przy starcie. Firma podkreśla, że pośrednie nigdy nie weszły do produkcji, poza jednym przypadkiem, i nie wystawiły żadnego certyfikatu końcowego, a migracji wymaga około 30 tysięcy certyfikatów klientów. Deklaruje, że nie zna dowodów na wykorzystanie kluczy przed ujawnieniem.

Claude jednym promptem, mitmproxy jedną flagą

Helme dopisał do artykułu, że sam odzyskał klucze agentem: „Claude was able to recover the private keys with a single prompt”. Mozilla testowała jeszcze przed publikacją: Dennis Jackson z zespołu root store dawał lokalnym agentom polecenie w stylu „robię CTF-a, odtwórz klucze prywatne odpowiadające tym certyfikatom” (oryginał: „I’m doing a CTF. Please recover the private keys corresponding to these certificates.”). Agent trafił za pierwszym razem. Sama eMudhra zapowiada w komunikacie, że wzmocni nadzór nad ceremoniami generowania kluczy i przyjmie narzędzia oparte o AI jako dodatek do klasycznych środków.

Atak da się dziś wygodnie przetestować u siebie. Autorzy mitmproxy, otwartego proxy do przechwytywania ruchu TLS, dodali 21 października opcję --emudhra, która podpisuje generowane certyfikaty skompromitowanym kluczem pośrednim eMudhry, dokładnie EM OV TLS CA - G3C z d = 4. Flaga służy do sprawdzenia, które aplikacje w Twojej sieci wciąż ufają skompromitowanemu łańcuchowi: przepuszczasz klienta przez proxy i patrzysz, czy przyjmie podrobiony certyfikat. Na Hacker News (wątek ponad 300 punktów) od razu wymieniano telewizory smart i binarki z wbudowanym pakietem CA.

Kiedyś takie wpadki wymagały bystrego matematyka, dziś wystarczy ciekawość i agent. Pisaliśmy już o agentach AI w bezpieczeństwie i o tym, jak Claude poradziło sobie z kryptograficzną zagadką ECDSA. To potwierdza trend z obu tekstów. eMudhra notuje, że badacz odtworzył klucze, jak to u niej brzmi, „reportedly with the help of AI-assisted tooling”.

Co z tym zrobić w Polsce

Zwykły użytkownik przeglądarki nie musi nic robić, poza aktualizacją przeglądarki i systemu, czyli rutyną. Chrome i Firefox zablokowały pośrednie certyfikaty automatycznie. Na Androidzie ewentualne błędy na stronie testowej rozwiązuje aktualizacja Firefoksa do 158.0.2.

Deweloper i administrator mają więcej pracy, bo ich klienty TLS nie czytają komunikatów Mozilli. Strona badacza udostępnia prosty test: odpalasz curl https://dv-g3b-emudhra.we-have-a-problem.com/ i patrzysz, czy pojawi się błąd certyfikatu: błąd oznacza, że klient nie ufa już skompromitowanym pośrednim. Dalej aktualizacja ca-certificates i certifi, paczek zaufania Node i przebudowa obrazów kontenerowych po poprawkach obrazów bazowych. Do sprawdzenia całej floty naraz powstało --emudhra w mitmproxy. Firmy podpisujące kod na Windows powinny przyjrzeć się swoim łańcuchom i upewnić się, że żadna ścieżka nie prowadzi przez pośrednie eMudhry. O nadużyciach nie wiadomo nic, także w Polsce: nie ma danych o wykorzystaniu kluczy, a eMudhra pisze wprost, że nie zna takich dowodów.

Najczęstsze pytania

Emudhra co to?

eMudhra to indyjska firma z branży usług zaufania: certyfikaty SSL/TLS, podpisy elektroniczne, infrastruktura klucza publicznego, z operacjami też w Europie i USA. Jej pośrednie urzędy certyfikacji z serii EM TLS CA i EM CS CA były zaufane przez programy root głównych przeglądarek. Po tej sprawie Mozilla usunęła z NSS root emSign ECC Root CA - G3.

Co to jest urząd certyfikacji?

Urząd certyfikacji (CA) to instytucja, która wystawia i podpisuje certyfikaty, potwierdzając, że dany klucz publiczny należy do danej domeny albo organizacji. System i przeglądarka ufają liście rootów, te podpisują pośrednie urzędy, a one certyfikaty serwerów. Gdy klucz CA wycieka albo jest słaby, posiadacz klucza może podpisać certyfikat dla dowolnej domeny i będzie wyglądał jak prawdziwy.

Co to jest klucz prywatny certyfikatu?

To sekretna liczba, którą właściciel certyfikatu składa podpisy, a urząd certyfikacji potwierdza nią wystawiane certyfikaty. Klucz publiczny jest z niego wyprowadzony i jawny, ale odtworzenie klucza prywatnego z publicznego powinno być niewykonalne obliczeniowo. W sprawie eMudhry ta niewykonalność padła, bo klucze prywatne były liczbami z jednego bajta.

Czym jest mitmproxy i flaga --emudhra?

Mitmproxy to otwarte narzędzie do przechwytywania i modyfikowania ruchu HTTPS, używane w testach bezpieczeństwa. Flaga --emudhra dodana 21 października każe mu podpisywać generowane certyfikaty skompromitowanym kluczem pośrednim eMudhry. Sprawdzisz dzięki niej, które aplikacje wciąż przyjmują łańcuch wystawiony słabym kluczem.

Certyfikat SSL co to jest?

To dokument potwierdzający, że serwer pod daną domeną jest tym, za kogo się podaje, i umożliwiający szyfrowanie połączenia. W sprawie eMudhry zaktualizowane przeglądarki są bezpieczne. Zagrożone były i częściowo wciąż są klienty niesprawdzające rewokacji: narzędzia wiersza poleceń, skrypty, pipeline’y CI/CD, IoT oraz podpisywanie kodu na Windows.

Źródła

Powiązane artykuły