Firefox 158.0.1 po kompromitacji kluczy eMudhra: co zrobić

Mozilla poinformowała o kompromitacji kluczy prywatnych powiązanych z ośmioma certyfikatami pośrednimi eMudhra. Takie klucze mogłyby posłużyć do wystawienia fałszywego certyfikatu HTTPS dla domeny, której atakujący nie kontroluje. Jeżeli przestępca potrafiłby jednocześnie przechwycić połączenie, mógłby podszyć się pod stronę oraz odczytywać lub zmieniać ruch.

Dla większości użytkowników Firefoksa ochrona została dostarczona automatycznie przez OneCRL w niecałe trzy godziny od zgłoszenia. Mozilla wydała jednak również Firefox 158.0.1 dla komputerów i Androida oraz Firefox ESR 115.43.1 i 153.5.1, aby objąć mniejszość instalacji, w których niestandardowe ustawienia mogły zablokować aktualizację listy unieważnień.

Wniosek Breachroad: to poważny incydent w łańcuchu zaufania, ale nie jest to komunikat, że każda osoba korzystająca z Firefoksa została zaatakowana. Najważniejsze działania to aktualizacja przeglądarki, kontrola niestandardowych polityk i sprawdzenie aplikacji korzystających z magazynu zaufania Mozilli.

Co właściwie zostało przejęte

HTTPS opiera się na łańcuchu zaufania. Przeglądarka ufa certyfikatowi głównemu, ten może podpisywać certyfikaty pośrednie, a dopiero nimi wystawia się certyfikaty dla konkretnych stron. Certyfikat pośredni ogranicza codzienne użycie najważniejszego klucza głównego, ale jego własny klucz prywatny nadal ma dużą moc.

Mozilla podała, że w sobotę 17 października o 20:06 UTC otrzymała informację o przejęciu kluczy ośmiu certyfikatów pośrednich eMudhra. Z takim kluczem możliwe byłoby podpisanie fałszywego certyfikatu. Sam certyfikat nie daje jednak automatycznie dostępu do urządzenia ani konta. Aby podszyć się pod stronę w realnej sesji, atakujący musiałby jeszcze skierować ruch ofiary do własnego serwera lub znaleźć się na jego drodze, na przykład przez kompromitację DNS, sieci albo urządzenia pośredniczącego.

Oficjalny komunikat opisuje możliwość wystawiania fałszywych certyfikatów, lecz nie podaje dowodu, że użyto ich do masowego przechwytywania połączeń. Tego rozróżnienia nie wolno zgubić: kompromitacja klucza jest faktem, a wykorzystanie go przeciw konkretnej organizacji wymaga osobnego potwierdzenia.

Jak zareagował Firefox

Mozilla dodała dotknięte certyfikaty do OneCRL, centralnej listy blokad dystrybuowanej do Firefoksa. Według producenta aktualizacja dotarła do wszystkich standardowo skonfigurowanych instalacji do 22:59 UTC 17 października, czyli mniej niż trzy godziny po otrzymaniu zgłoszenia. Nie wymagała aktualizacji programu ani restartu.

Wydanie 158.0.1 i nowe wersje ESR stanowią dodatkową warstwę ochrony dla instalacji, które nie pobrały OneCRL z powodu zmian w ustawieniach. Mozilla aktualizuje też listę zaufanych certyfikatów w NSS 3.131.1, usuwając certyfikat główny, który podpisał dotknięte certyfikaty pośrednie. To ważne również dla innych aplikacji korzystających z magazynu Mozilli, ale nieodbierających zmian OneCRL.

Ta reakcja pokazuje, dlaczego unieważnienie certyfikatu nie może zależeć wyłącznie od okresowej aktualizacji przeglądarki. Kanał zdalnej listy blokad skrócił czas ekspozycji standardowych instalacji, a wydanie programu domyka wyjątki i środowiska zarządzane w nietypowy sposób.

Co powinien zrobić zwykły użytkownik

1. Zaktualizuj Firefoksa. Otwórz informacje o programie i pozwól przeglądarce pobrać bieżące wydanie. Na komputerze wersją zawierającą dodatkową ochronę jest 158.0.1, a w kanałach ESR 115.43.1 lub 153.5.1.
2. Uruchom ponownie przeglądarkę po aktualizacji. OneCRL nie wymagał restartu, lecz instalacja nowej wersji już może go potrzebować.
3. Nie ignoruj ostrzeżeń certyfikatu. Nie klikaj opcji pozwalającej wejść na stronę mimo błędu, szczególnie podczas logowania, bankowości i pracy z pocztą.
4. Nie zmieniaj wszystkich haseł wyłącznie z powodu komunikatu. Mozilla nie stwierdziła, że wszystkie sesje zostały przechwycone. Zmiana hasła ma sens, jeśli pojawiło się ostrzeżenie, nietypowe logowanie, podejrzana sesja albo potwierdzenie dotyczące używanej usługi.
5. Sprawdź inne przeglądarki i system. Każdy producent zarządza zaufaniem i unieważnieniami własnym procesem. Aktualny Firefox nie aktualizuje automatycznie innych aplikacji.

Jeśli urządzenie jest służbowe, nie próbuj samodzielnie usuwać certyfikatów z magazynu. Zgłoś problem zespołowi IT, ponieważ firma może używać własnego urzędu certyfikacji do kontroli ruchu, a przypadkowe usunięcie właściwego wpisu przerwie dostęp do usług.

Plan dla firm i administratorów

Najpierw ustal skalę, zamiast wysyłać ogólną wiadomość „zaktualizujcie przeglądarki”. Inwentaryzacja powinna objąć standardowe instalacje, kanały ESR, urządzenia mobilne, wersje przenośne, kioski, obrazy VDI i urządzenia niełączące się regularnie z internetem.

Następnie:

• potwierdź wdrożenie co najmniej Firefox 158.0.1 albo właściwego wydania ESR;
• sprawdź polityki, które blokują Remote Settings, telemetrię lub pobieranie list unieważnień — nie zakładaj, że jedna blokada prywatności wpływa na wszystkie usługi tak samo;
• zweryfikuj wersje NSS w aplikacjach i produktach, które osadzają magazyn zaufania Mozilli, korzystając z biuletynu ich własnego dostawcy;
• przejrzyj centralne logi proxy, DNS i EDR pod kątem nieoczekiwanych przekierowań, błędów TLS oraz instalacji nowych certyfikatów głównych;
• udokumentuj wyjątki, urządzenia offline i termin ich aktualizacji;
• przygotuj krótką informację dla pracowników: aktualizacja jest potrzebna, ale sam komunikat nie dowodzi kradzieży ich haseł.

W środowisku z inspekcją TLS trzeba dodatkowo oddzielić certyfikaty publiczne od prywatnego firmowego CA. Proxy deszyfrujące ruch tworzy własny łańcuch zaufania na zarządzanych urządzeniach. Zespół powinien potwierdzić, że zmiana po stronie Mozilli nie została „naprawiona” przez wprowadzenie zbyt szerokich wyjątków lub wyłączenie walidacji.

Kiedy uruchomić analizę incydentu

Sama obecność starej wersji Firefoksa oznacza pilne zadanie aktualizacyjne, ale nie jest dowodem przejęcia urządzenia. Pełniejsza analiza jest uzasadniona, gdy w okresie od 17 października pojawiły się:

• ostrzeżenia o certyfikacie na znanej stronie;
• nietypowe rozstrzygnięcia DNS lub trasy sieciowe;
• nowy, niezatwierdzony certyfikat główny na urządzeniu;
• logowania z nowych lokalizacji bez wyjaśnienia;
• sesje do ważnych usług zbieżne z anomaliami proxy lub VPN.

Wtedy należy zachować logi i dane przeglądarki zgodnie z procedurą firmy, ustalić odwiedzane domeny oraz odtworzyć łańcuch certyfikatów widziany przez klienta. Reset haseł i sesji powinien objąć konta, dla których powstała wiarygodna hipoteza przechwycenia, nie całą organizację bez analizy.

Fakty źródłowe i wnioski Breachroad

Faktami podanymi przez Mozillę są: przejęcie kluczy ośmiu certyfikatów pośrednich, czas zgłoszenia, dystrybucja blokady przez OneCRL, wydania 158.0.1 oraz ESR i aktualizacja NSS 3.131.1. Mozilla opisała możliwe podszywanie się i odczyt lub modyfikację przechwyconego ruchu, ale w komunikacie nie potwierdziła masowego wykorzystania przeciw użytkownikom.

Rekomendacje dotyczące inwentaryzacji, przeglądu polityk, korelacji logów i komunikacji z pracownikami są wnioskami Breachroad. Firmy, które chcą ćwiczyć rozpoznawanie ostrzeżeń i bezpieczną eskalację takich zdarzeń, mogą wykorzystać szkolenia cyberbezpieczeństwa dla organizacji. Stan PKI, inspekcji TLS i zarządzania urządzeniami można ocenić podczas audytu bezpieczeństwa IT.

Źródło pierwotne: Mozilla Security Blog — Protecting Firefox users following the compromise of eMudhra intermediate certificates.