Analiza incydentu eMudhra CA: Kluczowe ustalenia i wpływ

Podsumowanie

Indyjski Urząd Certyfikacji eMudhra nieumyślnie wydał osiem certyfikatów pośrednich powiązanych z niezabezpieczonymi kluczami prywatnymi. To naruszenie mogło pozwolić atakującym na generowanie ważnych certyfikatów TLS i do podpisywania kodu dla dowolnych nazw hostów w internecie. Problem stanowi znaczne ryzyko dla klientów podłączonych do sieci, szczególnie dla systemów wbudowanych i urządzeń, które nie otrzymały aktualnych aktualizacji bezpieczeństwa.

Śledztwo

Śledztwo ustaliło, że incydent pochodził z niezabezpieczonych kluczy prywatnych powiązanych z certyfikatami pośrednimi eMudhra. Analiza koncentruje się na identyfikowaniu tych certyfikatów w ruchu sieciowym za pomocą Zeeka poprzez dopasowanie ich skrótów Subject Public Key Info (SPKI). To podejście jest bardziej niezawodne niż dopasowywanie odcisków palców certyfikatów, ponieważ uwzględnia również certyfikaty krzyżowo podpisane i potencjalną elastyczność podpisów.

Mitygacja

Główni dostawcy przeglądarek i systemów operacyjnych dodali dotknięte certyfikaty do mechanizmów niedowierzania, takich jak CRLSet Chrome’a i OneCRL Mozilli. Użytkownicy powinni upewnić się, że ich urządzenia są w pełni zaktualizowane, aby otrzymać te zmiany dotyczące niedowierzania. Do monitorowania sieci wdrożenie pakietu Zeek emudhra-weak-keys umożliwia wykrywanie dotkniętych certyfikatów podczas uścisków dłoni TLS.

Reakcja

Kiedy Compromised_Intermediate_Cert pojawiają się powiadomienia w logach Zeeka, zespoły ds. bezpieczeństwa powinny zbadać zarówno hosta docelowego, jak i łączącego się klienta. A Compromised_Intermediate_Cert_Established alarm wskazuje, że klient pomyślnie zaakceptował potencjalnie fałszywy certyfikat. Organizacje powinny również sprawdzić status poprawek wbudowanych, przestarzałych i potencjalnie nieaktualnych urządzeń w całym swoim środowisku.

Wykonanie symulacji

• Narracja ataku i polecenia: Przeciwnik uzyskał certyfikat od skompromitowanego pośredniego CA eMudhra. Aby ominąć standardowe zabezpieczenia, skonfigurowali złośliwy nasłuch, który przedstawia ten certyfikat podczas uścisku dłoni TLS. Celem jest nawiązanie kanału C2, który wydaje się korzystać z ważnego, aczkolwiek skompromitowanego, łańcucha zaufania. Zasymulujemy to, używając openssl do hostowania lokalnego serwera internetowego z użyciem certyfikatu, który imituje metadane/odcisk palca skompromitowanego certyfikatu eMudhra, zmuszając sensor Zeek do wywołania „notatki” w oparciu o jego logikę identyfikacji.

• Skrypt testu regresji:

  # 1. Wygeneruj przykładowy certyfikat, który imituje podpis skompromitowanej eMudhra
  # W rzeczywistej sytuacji atakujący używa faktycznie skompromitowanego certyfikatu.
  openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes -subj "/C=IN/ST=State/L=City/O=eMudhra/CN=Compromised_Test_CA"
  
  # 2. Uruchom lokalny serwer internetowy z wykorzystaniem tego certyfikatu
  # Używamy procesu w tle do hostowania serwera
  openssl s_server -accept 4443 -cert cert.pem -key key.pem -quiet &
  SERVER_PID=$!
  
  # 3. Czekaj na inicjalizację serwera
  sleep 2
  
  # 4. Wyzwól uścisk dłoni TLS (To generuje ruch Zeeka)
  # Uwaga: W prawdziwym laboratorium sensor Zeek musi być skonfigurowany ze specyficznym
  # skryptem/pluginem, który identyfikuje ten certyfikat jako 'Compromised_Intermediate_Cert'
  curl -k https://localhost:4443
  
  # 5. Sprzątanie (obsługiwane w sekcji sprzątania)
  kill $SERVER_PID

• Komendy sprzątające:

  # Usuń wygenerowane pliki przykładowe certyfikatów i zatrzymaj serwer
  rm -f key.pem cert.pem
  # Jeśli proces serwera nadal działa:
  pkill -f "openssl s_server"