Ing. Calogero Bono
Cloudflare opublikowała analizę uzupełniającą dotyczącą ośmiu słabych kluczy kryptograficznych indyjskiego urzędu certyfikacji eMudhra, wykrytych 19 października 2026 roku. Według firmy najbardziej krytyczne systemy są już zabezpieczone i nie wykryto przechwytywania jej połączeń. Fałszywe certyfikaty pojawiły się jednak w ciągu kilku godzin, a wiele przeglądarek, botów i wbudowanych aplikacji nadal akceptuje skompromitowany łańcuch. Dla tych, którzy prowadzą strony i usługi online, ryzyko nie jest teoretyczne.
Kilka pojęć, zanim przejdziemy do faktów. CA (certificate authority) to urząd, który wydaje certyfikaty, na których opiera się kłódka HTTPS. Klucz pośredni to klucz, którym CA podpisuje certyfikaty stron. CRL to lista unieważnionych certyfikatów. Certificate Transparency to publiczny rejestr wydanych certyfikatów, a SCT to ich potwierdzenia. SAN i SNI oznaczają nazwy domen zawarte w certyfikacie i nazwę żądaną przez klienta.
Co stało się z kluczami eMudhra?
Według Cloudflare, eMudhra miała wybrać 115-cyfrową liczbę do ochrony swoich kluczy, ale użyła liczby 4. Pozostałe siedem kluczy było równie słabych, z wartościami takimi jak 56, 66, 115, 155, 156, 230 i 237.
Cloudflare wyjaśnia, że klucze pośrednie można niemal od razu odtworzyć przez każdego, na podstawie publicznych certyfikatów. Każdy może więc tworzyć certyfikaty dla dowolnej domeny, które zaakceptowałby nieaktualny klient bez kontroli Certificate Transparency.
Według firmy przypadek jest bez precedensu. Incydenty takie jak DigiNotar, TÜRKTRUST i TrustWave dawały możliwość wydawania fałszywych certyfikatów tylko nielicznym podmiotom.
Jak zareagowała Cloudflare?
19 października ruszyły poprawki w systemach o wysokim wpływie, począwszy od proxy Pingora kierowanych do serwerów klientów, które obsługują większość połączeń wychodzących. W ciągu kilku godzin zaczęły odrzucać podatne klucze.
Równolegle analiza kodu wspomagana sztuczną inteligencją w cztery godziny wskazała pozostałe systemy ufające tym kluczom. Dla każdego otwarto zgłoszenie. Pilne interwencje musiały zostać wykonane od razu, pozostałe do końca poprzedniego tygodnia. W chwili publikacji pozostaje do zamknięcia kilka zgłoszeń o niskim wpływie.
Czy klucze zostały już użyte do fałszowania certyfikatów?
Tak, według Cloudflare. Od 21 października log w Pingora rejestruje certyfikaty podpisane słabymi kluczami. W ciągu około tygodnia naliczył około 22 000 prób handshake. Dwie trzecie dotyczyło stron testowych, prawie reszta serwerów, które wydają się same wygenerować certyfikat ze słabym kluczem pośrednim. Każdy handshake z aktywną weryfikacją został odrzucony.
Około 160 przypadków było anomalnych, z nazwami domen innych organizacji, niektóre powiązane z konsumenckimi urządzeniami IoT. Niektóre certyfikaty były ważne ponad dwa lata, dłużej niż mógłby wydać publiczny urząd CA. Jeden pochodzi z 20 października o 18:19 UTC, niecałą godzinę po opublikowaniu zgłoszenia przez Mozillę.
Według Cloudflare wygląda to jednak na domyślne certyfikaty serwerów, a nie próby przechwycenia. Przypadek jest podobny do innych, w których podatność jest natychmiast sondowana, jak w przypadku Oracle E-Business Suite.
Ilu odwiedzających jest nadal narażonych?
Cloudflare nie może bezpośrednio testować odwiedzających bez przerywania połączeń. Dodała więc dwie sondy do stron weryfikacyjnych, jedną z certyfikatem eMudhra i jedną kontrolną. W ciągu tygodnia zebrała 50 milionów sond.
Obraz, który przedstawia, wygląda następująco.
- Nowoczesne i zaktualizowane przeglądarki są w większości chronione.
- Boty i stare przeglądarki nie są.
- Aplikacje z wbudowaną przeglądarką, jak Android WebView, nadal akceptują łańcuch w 30-40% przypadków.
- W dużych sieciach ponad połowa sond akceptuje skompromitowany łańcuch.
Po pewnym postępie w pierwszy weekend trend jest płaski. Ruch jest jednak zniekształcony przez niepotwierdzone boty, a sondy wysyłają tylko klienci wykonujący JavaScript.
Ograniczenia, o których warto wiedzieć
eMudhra twierdzi, że w skrypcie generowania kluczy wystąpił błąd, ale jeszcze go nie udostępniła. Pozostaje do wyjaśnienia rola audytorów i cross-signerów oraz to, dlaczego CRL został najpierw podpisany prawdopodobnie poprawnym kluczem, a potem słabym. Cloudflare wyklucza przechwytywanie wyłącznie na podstawie pośrednich sygnałów. Ukierunkowanego przechwycenia nie można wykluczyć. Dane o odwiedzających są ponadto zniekształcone przez boty.
Co się zmienia dla osób pracujących w cyfrowym świecie
Jeśli prowadzisz strony, aplikacje lub systemy zarządzania, sprawdź, czy serwery, biblioteki i klienci odrzucają klucze eMudhra. Ważne są też oprogramowania łączące się z zewnętrznymi usługami, jak aplikacje mobilne z WebView i skrypty automatyczne, bo często zostają w tyle. Kto tworzy oprogramowanie na macOS, powinien uważnie śledzić instrukcje podane przez Cloudflare. Jeśli masz hosting z zarządzanymi aktualizacjami bezpieczeństwa, zapytaj dostawcę o stan poprawki. Temat dotyczy także osób korzystających z certyfikatów do podpisu cyfrowego.
Nasza opinia
Najbardziej niepokojący jest nie sam błąd, lecz powolność aktualizacji. Klucz, który może odtworzyć każdy, to ogromny błąd, a fakt, że ponad połowa sond nadal akceptuje łańcuch, pokazuje szerszy problem – oprogramowanie, którego nikt nie aktualizuje. Ten przypadek przypomina, jak ważne są klucze kryptograficzne, jak w przypadku malware KeyDrift w Cisco SD-WAN. Pozostaje też wątpliwość co do systemu kontroli, bo audyty i cross-signing niczego nie powstrzymały.
Najczęstsze pytania
Czym są słabe klucze eMudhra?
To osiem kluczy pośrednich CA, wygenerowanych z małych liczb, takich jak 4 czy 56. Dlatego każdy może je odtworzyć z publicznych certyfikatów i podpisywać fałszywe certyfikaty.
Czy Cloudflare została skompromitowana?
Według Cloudflare nie ma dowodów na przechwytywanie jej połączeń. Systemy o wysokim priorytecie zostały zaktualizowane, a pozostaje kilka zgłoszeń o niskim wpływie.
Jakie jest ryzyko dla strony lub aplikacji?
Zależy od klienta. Klient nieaktualny i bez kontroli Certificate Transparency może zaakceptować fałszywe certyfikaty dla dowolnej domeny, co umożliwia potencjalne przechwycenie ruchu.
Które oprogramowanie jest najbardziej narażone?
Boty, stare przeglądarki i wbudowane przeglądarki, jak Android WebView. Według Cloudflare w tych ostatnich 30-40% nadal akceptuje skompromitowany łańcuch.
Co mam zrobić teraz?
Zaktualizuj systemy i postępuj zgodnie z instrukcjami na stronie prowadzonej przez Dennisa Jacksona, cytowanej przez Cloudflare. Jeśli tworzysz oprogramowanie na macOS, nadaj tym wskazówkom priorytet.
Na co zwracać uwagę w najbliższych tygodniach w sprawie eMudhra
Sprawa toczy się na dwóch frontach – wyjaśnieniach eMudhra i tempie aktualizacji. Warto śledzić oba.
- Sprawdzaj, czy eMudhra publikuje skrypt generowania kluczy i wnioski z audytów oraz cross-signerów.
- Śledź aktualizacje przeglądarek i środowisk uruchomieniowych używanych przez Twoje aplikacje, zwłaszcza WebView.
- Sprawdzaj w logach swoich serwerów certyfikaty z nazwami domen niezgodnymi z żądanymi.
