Kompromitacja kluczy CA eMudhra zmienia aktualizacje zaufania przeglądarek w kontrolę floty IT

Co zostało skompromitowane, a co nie

17 października incydent eMudhra przestał być wyłącznie problemem związanym z zarządzaniem certyfikatami i stał się szerszą decyzją dotyczącą zaufania. Śledczy ustalili, że można było odzyskać klucze prywatne ośmiu podrzędnych urzędów certyfikacji eMudhra, ponieważ wygenerowano je z niewystarczającą losowością kryptograficzną. To istotny szczegół: przejęty klucz prywatny CA może pozwolić atakującemu tworzyć certyfikaty wyglądające tak, jakby prowadziły łańcuchem do zaufanego urzędu. Dlatego reakcja nie może ograniczać się do pytania, czy odwiedzono konkretną stronę. Trzeba dokładnie ustalić, które urzędy wydające zostały dotknięte problemem, i oddzielić potwierdzone narażenie od założeń dotyczących pozostałej części hierarchii eMudhra.

Osiem objętych problemem podrzędnych CA dzieli się na dwie wyraźne grupy. Sześć to pośrednie urzędy TLS, używane w łańcuchach certyfikatów dla szyfrowanych połączeń sieciowych. Dwa pozostałe to pośrednie urzędy podpisywania kodu, służące do obsługi podpisów oprogramowania lub innych podpisanych treści. Traktowanie tych kategorii jako wymiennych zacierałoby dwie różne kwestie walidacji. Przeglądarka lub system operacyjny może oceniać łańcuch TLS podczas łączenia się z usługą, natomiast weryfikator podpisu kodu sprawdza podpis i jego łańcuch certyfikatów, gdy decyduje, czy oprogramowaniu można zaufać. Oba przypadki opierają się na infrastrukturze certyfikatów, ale dotknięte nimi zastosowania oraz systemy buforujące lub wymuszające zaufanie nie są identyczne.

Komunikaty Google i Mozilli opisują kompromitację jako dotyczącą tych ośmiu pośrednich CA eMudhra. Ich wytyczne wyznaczają też ważną granicę wobec tego, czego nie ustalono: w cytowanych komunikatach nie ma wskazania, że skompromitowany został każdy główny certyfikat eMudhra ani każdy inny pośredni certyfikat eMudhra. Nie oznacza to, że wszystkie certyfikaty eMudhra należy pozostawić bez zmian, ale nie stanowi też podstawy do uznania całego urzędu certyfikacji za jednakowo niebezpieczny. Praktyczne i bardziej użyteczne pytanie brzmi węziej: czy system polega na jednym ze zidentyfikowanych pośrednich CA albo na łańcuchu prowadzącym przez główny certyfikat lub ścieżkę współpodpisywania, które dostawcy wycofują z zaufania?

To rozróżnienie wyjaśnia, dlaczego reakcja jest wdrażana za pomocą ukierunkowanych działań wycofujących zaufanie, a nie poprzez ogólne stwierdzenie, że każdy certyfikat wydany przez eMudhra jest nieważny. Mechanizmy dostawców mogą blokować certyfikaty powiązane z objętym problemem materiałem klucza publicznego albo usuwać określone ścieżki zaufania, ale administratorzy nadal muszą ustalić, czy ich własne certyfikaty, infrastruktura inspekcji, procesy weryfikacji oprogramowania lub wbudowane magazyny zaufania zależą od tych ścieżek. Innymi słowy, potwierdzona kompromitacja wskazuje zbiór kluczy, które trzeba traktować jako ujawnione; sama w sobie nie odpowiada jednak na pytanie, które usługi w organizacji przestaną działać po zaostrzeniu zaufania.

Równie istotna jest przyczyna techniczna. Możliwość odzyskania kluczy prywatnych przypisano niewystarczającej losowości podczas generowania kluczy kryptograficznych. To coś innego niż dowody na odgadnięcie hasła przez atakującego lub pozyskanie klucza prywatnego podczas zwykłego włamania na serwer. Gdy jednak można odtworzyć podstawowy materiał klucza, konsekwencja operacyjna dla stron ufających jest podobna: certyfikatów wydanych przez objęte problemem podrzędne CA nie można już uznawać za wiarygodne tylko dlatego, że noszą znaną nazwę eMudhra lub prowadzą łańcuchem do rozpoznawalnego głównego certyfikatu. Walidacja musi uwzględniać konkretny skompromitowany urząd wydający oraz mechanizmy zastosowane obecnie do wycofania mu zaufania.

Dla zespołów IT pierwszą granicą inwentaryzacji powinien być zatem łańcuch certyfikatów, a nie marka wyświetlana w przeglądarce certyfikatów. Należy odnotować, czy certyfikaty kończą się na jednym z sześciu objętych problemem pośrednich CA TLS, czy podpisane oprogramowanie opiera się na którymś z dwóch pośrednich CA podpisywania kodu oraz czy łańcuch prowadzi do objętego problemem głównego certyfikatu lub ścieżki współpodpisywania, której usunięcie zaplanował dostawca. Trzeba też zachować widoczne ustalenie negatywne: na podstawie cytowanych tu komunikatów nie wykazano automatycznie kompromitacji systemów korzystających z niezwiązanych głównych lub pośrednich certyfikatów eMudhra. Takie rozdzielenie pozwala później precyzyjniej przeprowadzić działania naprawcze, zachować możliwy do obrony zapis wykonanych kontroli i uniknąć zastąpienia ukierunkowanej aktualizacji magazynu zaufania niepotrzebnie szeroką awarią.

Dlaczego użytkownicy przeglądarek zostali ochronieni szybciej niż użytkownicy innych programów

Pierwsza warstwa ochrony trafiła do popularnych przeglądarek, ponieważ ich dostawcy mogą rozpowszechniać decyzje o braku zaufania za pośrednictwem centralnie zarządzanych mechanizmów aktualizacji. Chrome wykorzystał blokadę CRLSet opartą na SPKI, aby odrzucać certyfikaty powiązane ze skompromitowanymi kluczami pośrednimi eMudhra. Istotne jest to, że działanie obejmuje tożsamość klucza publicznego urzędu certyfikacji, a nie tylko numer seryjny pojedynczego certyfikatu. Dzięki temu przeglądarka może zatrzymać dotknięte problemem łańcuchy także wtedy, gdy przedstawiany certyfikat jest nowy, został zastąpiony albo nie został osobno wymieniony na liście. Na Androidzie Google użyło również Google Play Services, rozszerzając ochronę poza samą przeglądarkę. Odpowiednia reakcja na brak zaufania może dzięki temu dotrzeć do obsługiwanych urządzeń za pośrednictwem usługi platformowej, bez czekania, aż każda aplikacja wdroży własną logikę obsługi certyfikatów.

Firefox realizował podobny cel za pomocą OneCRL, mechanizmu Mozilli służącego do rozsyłania klientom Firefoksa decyzji o unieważnieniu certyfikatów. Mozilla opisała także zmiany w magazynie certyfikatów głównych, działające na szerszej granicy zaufania. Zamiast odrzucać wyłącznie certyfikaty wydane pod konkretnym certyfikatem pośrednim, klient może całkowicie przestać ufać certyfikatowi głównemu lub powiązanej ścieżce. Taki zakres jest przydatny, gdy do tego samego ekosystemu można dotrzeć przez różne układy certyfikatów pośrednich lub cross-signingu, ale wyjaśnia też, dlaczego zmiany zaufania trzeba oceniać ostrożnie. Aktualizacja przeglądarki może zamknąć lukę podczas zwykłych sesji internetowych, pozostawiając inne programy z odmiennym obrazem tego samego łańcucha certyfikatów.

Certificate Transparency pomogło ograniczyć czas ekspozycji w przypadku klientów, które egzekwują ten mechanizm, ponieważ oczekuje się, że publicznie zaufane certyfikaty TLS pozostawią możliwy do skontrolowania ślad w publicznych logach. Dla klienta egzekwującego te zasady taki zapis może wspierać wykrywanie oraz decyzje dotyczące certyfikatów, które nie powinny zostać wydane ani uznane za zaufane. Nie sprawia jednak, że każdy odbiorca TLS zaczyna egzekwować Certificate Transparency. Kontrole Certificate Transparency, mechanizmy unieważniania i aktualizacje magazynów zaufania to odrębne zabezpieczenia. Aplikacja może wdrażać część z nich, nie wdrażać żadnego albo stosować wewnętrzną odmianę, działającą inaczej niż aktualna przeglądarka.

Dlatego stwierdzenia „użytkownicy przeglądarek zostali ochronieni” nie należy rozumieć jako „ochronę uzyskały wszystkie systemy korzystające z TLS”. Przeglądarka zazwyczaj otrzymuje zarządzane przez dostawcę zasady i aktualizacje magazynu zaufania, ale organizacja może polegać także na pakietach certyfikatów systemu operacyjnego, magazynach wbudowanych w aplikacje, pakietach środowiska Java lub innych środowisk uruchomieniowych, urządzeniach sieciowych, systemach inspekcji TLS, obrazach kontenerów i samodzielnych bibliotekach. Komponenty te mogą odświeżać się według różnych harmonogramów albo wymagać bezpośredniej wymiany pakietu przez administratora. Niektóre aplikacje wykonują własne kontrole unieważnienia, inne korzystają z systemu operacyjnego hosta. Usługa, która nie odwołuje się do zaktualizowanego magazynu, może nadal budować łańcuch odrzucany przez aktualną przeglądarkę.

Mechanizm awarii może działać również w przeciwnym kierunku. Klient może mieć funkcję sprawdzania unieważnienia, ale uznawać brak odpowiedzi za dopuszczalny albo przechodzić w tryb fail-open, gdy nie jest w stanie zakończyć kontroli. W takiej sytuacji sam sygnał unieważnienia nie gwarantuje egzekwowania decyzji. Znaczenie mają lokalne zasady, dostępność sieci, zapisane w pamięci podręcznej decyzje i zachowanie aplikacji. To samo dotyczy urządzeń, które kończą połączenia TLS lub poddają je inspekcji: przeglądarka na urządzeniu końcowym może być aktualna, podczas gdy pośrednie urządzenie nadal ma starszy zestaw zaufania i zgodnie z własną konfiguracją wciąż akceptuje lub generuje łańcuchy.

Dla zespołów IT praktyczne rozróżnienie przebiega więc między ochroną przeglądarek kontrolowaną przez dostawcę a decyzjami dotyczącymi zaufania kontrolowanymi lokalnie. Odpowiedź CRLSet w Chrome, zabezpieczenia Google Play Services, działanie OneCRL w Firefoksie oraz zmiany w magazynie certyfikatów głównych zmniejszają ryzyko w przypadku klientów, które je otrzymują i egzekwują. Nie dowodzą jednak, że każdy komponent floty korzystający z certyfikatów ma taki sam zakres ochrony. Pytanie nie brzmi już tylko, czy użytkownicy mają zaktualizowane przeglądarki, lecz także czy organizacja wskazała programy i urządzenia, które utrzymują osobne magazyny zaufania, wykonują niezależne kontrole unieważnienia albo nadal działają, gdy te kontrole kończą się niepowodzeniem.

Operacyjne skutki, na które zespoły IT muszą się przygotować

Usunięcie zaufania do zaatakowanego urzędu certyfikacji jest konieczne w przypadku klientów, które potrafią wyegzekwować tę zmianę, ale nie pozostaje obojętne operacyjnie. Wytyczne Google ostrzegają, że usunięcie emSign ECC Root CA - G3 może unieważnić działanie prawidłowych certyfikatów, które nadal zależą od tego certyfikatu głównego albo powiązanego łańcucha. Ocena Mozilli również wskazuje kilka dotkniętych ścieżek certyfikatów głównych i cross-signingu. Dla zespołów IT praktyczne pytanie nie brzmi więc wyłącznie, czy przeglądarka uznaje certyfikat za zaufany. Trzeba ustalić, czy jakakolwiek usługa biznesowa, urządzenie inspekcyjne, pakiet oprogramowania lub proces walidacji nadal korzysta ze ścieżki, która wkrótce przestanie być zaufana.

Witryny należy traktować jako jedną kategorię inwentaryzacji, a nie jako przybliżenie całej floty. Usługa dostępna publicznie może prezentować certyfikat przez łańcuch, który przeglądarki szybko zaktualizują, podczas gdy usługa wewnętrzna, starszy punkt końcowy albo klient niebędący przeglądarką nadal będzie budować ten łańcuch inaczej. To samo rozróżnienie dotyczy serwerów: serwer może być prawidłowo skonfigurowany dla połączeń przychodzących, a jednocześnie nadal korzystać z zagrożonego certyfikatu przy wykonywaniu połączeń wychodzących. Wykrywanie certyfikatów powinno zatem obejmować zarówno certyfikaty prezentowane przez należące do organizacji usługi, jak i certyfikaty zaufane przez systemy, które je obsługują.

Inspekcja TLS wprowadza kolejny scenariusz awarii. Urządzenia sieciowe i firmowe proxy często kończą połączenie, poddają je inspekcji, a następnie nawiązują w imieniu użytkownika drugie połączenie. Jeśli urządzenie ma własny magazyn zaufania, wbudowany pakiet certyfikatów albo zarządzaną przez dostawcę logikę walidacji, aktualizacja przeglądarki na punkcie końcowym może nie zmienić sposobu, w jaki urządzenie ocenia zagrożony łańcuch. Z drugiej strony wymiana lub usunięcie certyfikatu używanego przez system inspekcyjny może jednocześnie przerwać ruch wielu użytkownikom. Bramki inspekcyjne, moduły równoważenia obciążenia i inne elementy pośredniczące należy sprawdzać jako niezależnych konsumentów zaufania, a ich konfigurację i mechanizmy aktualizacji rejestrować osobno od przeglądarek na punktach końcowych.

Obrazy kontenerów i środowiska aplikacyjne tworzą podobny podział między systemem operacyjnym a obciążeniem roboczym. Obraz może zawierać pakietowy pakiet CA, który pozostanie niezmieniony po otrzymaniu aktualizacji przez hosta. Wdrożenia Javy i inne aplikacje korzystające z własnych pakietów certyfikatów również mogą nadal używać wbudowanego magazynu zaufania zamiast magazynu platformy. Oznacza to, że obraz, środowisko uruchomieniowe i pakiet aplikacji trzeba traktować jako osobne pytania inwentaryzacyjne. Zespoły powinny ustalić, które usługi dziedziczą zaufanie po hoście, które kopiują certyfikaty do obrazu, a które utrzymują prywatny pakiet wymagający aktualizacji w ramach własnego procesu wydawniczego aplikacji.

Walidację podpisów kodu trzeba sprawdzić niezależnie od HTTPS. Wśród zaatakowanych certyfikatów pośrednich eMudhra znajdują się zarówno certyfikaty pośrednie do podpisywania kodu, jak i certyfikaty pośrednie TLS, dlatego reakcja skoncentrowana na przeglądarkach nie oznacza, że ścieżki walidacji oprogramowania zostały przeanalizowane. Systemy budowania, narzędzia bezpieczeństwa punktów końcowych, menedżery pakietów i inne systemy weryfikujące podpisy mogą korzystać z innych certyfikatów głównych, pośrednich lub mechanizmów unieważniania. Mogą też stosować zasady w innym momencie niż przeglądarka albo magazyn zaufania systemu operacyjnego. Istotne pytanie nie brzmi więc, czy stacja robocza otrzymała aktualizację przeglądarki, lecz czy każdy system akceptujący podpisane oprogramowanie ocenił zagrożone ścieżki podpisywania.

Ryzyko awarii jest największe tam, gdzie zaufanie jest powielone, wbudowane lub obsługiwane przez urządzenia pośredniczące. Szerokie usunięcie zaufania może zamknąć zaatakowaną ścieżkę klientom, które respektują nową politykę, ale ta sama zmiana może uniemożliwić działanie prawidłowej usługi, jeśli jej łańcuch certyfikatów nie został jeszcze wymieniony. Wąska reakcja może zachować dostępność, pozostawiając jednocześnie niezarządzanych klientów narażonych na zagrożenie. Dlatego przed wprowadzeniem zmian w całej flocie warto zmapować zależności: zarejestrować certyfikat, łańcuch, magazyn zaufania, komponent przeprowadzający walidację oraz powiązaną usługę biznesową, a następnie przetestować wynik w środowisku, które faktycznie wykonuje walidację.

W przypadku zróżnicowanych flot „zaktualizowany” powinno więc oznaczać coś więcej niż tylko aktualną wersję przeglądarki. Należy uwzględnić odpowiednie łańcuchy witryn, konfiguracje serwerów, urządzenia inspekcji, magazyny zaufania kontenerów i Javy, pakiety aplikacji oraz mechanizmy weryfikacji podpisu kodu. Jeśli zmiana magazynu głównego może wpłynąć na prawidłowe certyfikaty, zespoły powinny wdrażać ją etapami i utrzymywać plan wycofania powiązany z przetestowanymi zależnościami usług. Celem jest kontrolowane odrzucenie zaufania: usunięcie zależności od skompromitowanych ścieżek przy zachowaniu jasnej, opartej na dowodach drogi do przywrócenia usługi, gdy przeoczono prawidłowy łańcuch.

Możliwy do obrony plan reagowania dla zróżnicowanych flot

Najbezpieczniej potraktować zdarzenie związane z eMudhra jako ćwiczenie obejmujące magazyny zaufania i inwentaryzację certyfikatów, a nie jako zadanie polegające na załataniu przeglądarki. Zacznij od ustalenia, gdzie w całej flocie zaufane są objęte problemem certyfikaty pośrednie eMudhra oraz ich nadrzędne certyfikaty główne: na zarządzanych stacjach roboczych, serwerach, w kontenerach, magazynach Javy i aplikacji, urządzeniach sieciowych, urządzeniach inspekcji TLS, urządzeniach mobilnych oraz systemach budowania lub podpisywania. Kluczowe pytanie nie brzmi po prostu, czy przeglądarka jest aktualna. Chodzi o to, czy połączenie krytyczne dla działalności, biblioteka walidacyjna, urządzenie albo proces związany z podpisanym oprogramowaniem może nadal zaakceptować łańcuch, któremu nie powinno się już ufać.

Wytyczne dostawców powinny być pierwszym punktem kontroli. Zastosuj odpowiednie aktualizacje Chrome, Firefoksa, Androida, Ubuntu i innych pakietów w ramach zwykłego procesu zarządzania zmianami, a następnie sprawdź na reprezentatywnych systemach, czy oczekiwana zmiana w magazynie zaufania lub mechanizmie unieważniania jest obecna. Aktualizacja Ubuntu ca-certificates ma szczególne znaczenie dla systemów korzystających z magazynu zaufania dystrybucji, natomiast przeglądarki i aplikacje posiadające własne magazyny trzeba sprawdzać niezależnie. Dla każdej obsługiwanej platformy zapisz wersję pakietu lub przeglądarki, stan aktualizacji i stan magazynu zaufania, aby określenie „załatane” miało weryfikowalne znaczenie, zamiast wynikać wyłącznie z ostatniego zgłoszenia urządzenia.

Następnie zmapuj certyfikaty i ścieżki walidacji. Przeszukaj rejestry certyfikatów, konfiguracje modułów równoważenia obciążenia, konfiguracje serwerów WWW, siatki usług, obrazy kontenerów, magazyny kluczy Javy, pakiety aplikacji, profile inspekcji oraz zasady urządzeń pod kątem objętych problemem certyfikatów pośrednich eMudhra i powiązanych certyfikatów głównych. W przypadku certyfikatów używanych przez usługi skierowane do klientów ustal kompletny łańcuch faktycznie serwowany przez każdy punkt końcowy; certyfikat może być prawidłowy w przeglądarce, podczas gdy inny klient, serwer proxy lub biblioteka po stronie serwera wybierze inną ścieżkę. W przypadku ruchu wewnętrznie wystawianego lub poddawanego inspekcji sprawdź obie strony połączenia: konfigurację zaufania urządzenia inspekcyjnego oraz magazyn zaufania klienta, który otrzymuje ponownie podpisany certyfikat. Walidację podpisu kodu analizuj osobno od TLS, ponieważ certyfikat podpisujący może wpływać na dystrybucję i uruchamianie oprogramowania nawet wtedy, gdy nie jest używana żadna przeglądarka internetowa.

Zastąpienie certyfikatów powinno nastąpić przed zaplanowaną na 27 października zmianą Chrome Root Store. Każdy certyfikat używany przez klientów, który zależy od objętej problemem ścieżki, należy ponownie wystawić lub zastąpić łańcuchem niezależnym od skompromitowanych certyfikatów pośrednich i od certyfikatu głównego zaplanowanego do odrzucenia zaufania, a następnie wdrożyć go w kontrolowanej kolejności. Celem operacyjnym jest usunięcie ryzykownej zależności, zanim klienci wymuszą nowy stan, a nie czekanie, aż awarie połączeń ujawnią pominiętą usługę. Wymiana certyfikatu powinna obejmować serwowany łańcuch, wdrożenie certyfikatu pośredniego, automatyzację odnowień oraz wszelkie przypięte lub jawnie skonfigurowane relacje zaufania, które mogłyby uniemożliwić zaakceptowanie nowego łańcucha.

Testy muszą obejmować ścieżki, których nie wykrywają zwykłe kontrole przeglądarki. Zbuduj niewielką, lecz reprezentatywną macierz obejmującą krytyczne dla działalności witryny, interfejsy API, integracje wychodzące, konsole administracyjne, trasy inspekcji, usługi skonteneryzowane, aplikacje Java, procesy mobilne oraz procesy podpisywania lub aktualizowania oprogramowania. Testuj z zarządzanych i niezarządzanych segmentów sieci, jeśli oba są objęte zakresem, oraz korzystaj ze zaktualizowanych magazynów zaufania i wersji przeglądarek, które otrzymają systemy produkcyjne. Pomyślne załadowanie strony to tylko jeden z wyników; rejestruj walidację łańcucha certyfikatów, zachowanie proxy, działanie bibliotek aplikacyjnych oraz możliwość instalowania lub weryfikowania podpisanego oprogramowania tam, gdzie te funkcje mają znaczenie.

Ponieważ usunięcie certyfikatu głównego może przerwać działanie prawidłowych certyfikatów, wycofywanie zaufania należy etapować, jeśli nie da się w pełni ocenić środowiska w jednym oknie serwisowym. Najpierw zinwentaryzuj zasoby i zidentyfikuj zależności, następnie zaktualizuj kontrolowaną grupę pilotażową, obserwuj awarie i rozszerzaj zakres dopiero po przejściu krytycznych ścieżek. Jeśli usługa korzysta z odrzucanego certyfikatu, preferowanym sposobem przywrócenia działania jest udokumentowana korekta certyfikatu lub łańcucha po stronie usługi. Gdy tymczasowy wyjątek zaufania jest nieunikniony, należy potraktować go jako jawną, ograniczoną czasowo decyzję dotyczącą ryzyka — z przypisanym właścicielem i datą usunięcia — zamiast po cichu przywracać szerokie zaufanie w całej flocie.

Na koniec zachowaj dowody potwierdzające zarówno podjęcie działań, jak i ich zakres: wykryte zasoby, których dotyczy problem, wymienione certyfikaty, zainstalowane aktualizacje dostawców, sprawdzone magazyny zaufania, zakończone przypadki testowe, zatwierdzone wyjątki oraz przypisane pozostałe luki. Taki rejestr pozwala odróżnić rzeczywisty brak narażenia od systemu, którego nie przetestowano, a także ułatwia dalsze działania, gdy kolejne pakiety, aplikacje lub urządzenia sieciowe opublikują własne zalecenia naprawcze. Dającym się obronić rezultatem nie jest samo stwierdzenie, że główne przeglądarki zmieniły swoje działanie, lecz możliwość wykazania, gdzie organizacja egzekwowała zaufanie, gdzie je usunęła, które usługi przetestowała oraz w jaki sposób zarządza pozostałą niepewnością.