Analyse des eMudhra-CA-Vorfalls: Wichtige Erkenntnisse und Auswirkungen

Zusammenfassung

Die indische Zertifizierungsstelle eMudhra hat versehentlich acht Zwischenzertifikate ausgestellt, die mit unsicheren privaten Schlüsseln verbunden sind. Diese Kompromittierung könnte Angreifern ermöglichen, gültige TLS- und Code-Signing-Zertifikate für beliebige Hostnamen im Internet zu erstellen. Das Problem stellt ein erhebliches Risiko für netzwerkverbundene Clients dar, insbesondere für eingebettete Systeme und Geräte, die keine aktuellen Sicherheitsupdates erhalten haben.

Untersuchung

Die Untersuchung ergab, dass der Vorfall aus unsicheren privaten Schlüsseln resultierte, die mit den eMudhra-Zwischenzertifikaten verbunden sind. Die Analyse konzentriert sich darauf, diese Zertifikate im Netzwerkverkehr mit Zeek durch Abgleich ihrer Subject Public Key Info (SPKI)-Hashes zu identifizieren. Dieser Ansatz ist zuverlässiger als das Abgleichen der Zertifikats-Fingerabdrücke, da er auch für cross-signierte Zertifikate und potenzielle Signaturmanipulationen berücksichtigt wird.

Minderung

Große Browser- und Betriebssystemanbieter haben die betroffenen Zertifikate zu den Misstrauensmechanismen wie Chromes CRLSet und Mozillas OneCRL hinzugefügt. Benutzer sollten sicherstellen, dass ihre Geräte vollständig aktualisiert sind, um diese Misstrauensänderungen zu erhalten. Für die Netzwerküberwachung kann das Zeek-Paket emudhra-weak-keys eingesetzt werden, um betroffene Zertifikate während der TLS-Handshakes zu erkennen.

Reaktion

Wenn Kompromittierte_Zwischenzertifikate Hinweise in Zeek-Protokollen erscheinen, sollten Sicherheitsteams sowohl den Ziel-Host als auch den verbindenden Client untersuchen. Ein Kompromittiertes_Zwischenzertifikat_Etabliert Alarm zeigt an, dass der Client ein potenziell betrügerisches Zertifikat erfolgreich akzeptiert hat. Organisationen sollten auch den Patch-Status von eingebetteten, veralteten und anderen potenziell überholten Geräten in ihren Umgebungen überprüfen.

Ausführung der Simulation

• Angriffserzählung & Befehle: Der Angreifer hat ein Zertifikat von der kompromittierten eMudhra Zwischen-CA erhalten. Um herkömmliche Sicherheitskontrollen zu umgehen, richten sie einen bösartigen Listener ein, der dieses Zertifikat während des TLS-Handshakes präsentiert. Das Ziel ist es, einen C2-Kanal zu etablieren, der scheinbar eine gültige, wenn auch kompromittierte Vertrauenskette verwendet. Wir werden dies simulieren, indem wir openssl verwenden, um einen lokalen Webserver mit einem Zertifikat zu hosten, das die Metadaten/Fingerabdruck des kompromittierten eMudhra-Zertifikats imitiert und den Zeek-Sensor zwingt, basierend auf seiner Identifikationslogik eine „notice“ auszulösen.

• Regressions-Testskript:

  # 1. Generiere ein Mock-Zertifikat, das die kompromittierte eMudhra-Signatur nachahmt
  # In einem echten Szenario verwendet der Angreifer das tatsächlich kompromittierte Zertifikat.
  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. Starte einen lokalen Webserver mit diesem Zertifikat
  # Wir verwenden einen Hintergrundprozess, um den Server zu hosten
  openssl s_server -accept 4443 -cert cert.pem -key key.pem -quiet &
  SERVER_PID=$!
  
  # 3. Warten, bis der Server initialisiert ist
  sleep 2
  
  # 4. TLS-Handshake auslösen (Dies erzeugt den Zeek-Verkehr)
  # Hinweis: In einem echten Labor muss der Zeek-Sensor mit dem spezifischen
  # Skript/Plugin konfiguriert werden, das dieses Zertifikat als 'Kompromittierte_Zwischenzertifikate' identifiziert
  curl -k https://localhost:4443
  
  # 5. Aufräumen (im Aufräumabschnitt behandelt)
  kill $SERVER_PID

• Aufräumbefehle:

  # Entfernen der generierten Mock-Zertifikatsdateien und Beenden des Servers
  rm -f key.pem cert.pem
  # Falls der Serverprozess noch läuft:
  pkill -f "openssl s_server"