Analisi dell’Incidente eMudhra CA: Risultati Chiave e Impatto

Sommario

L’Autorità di Certificazione indiana eMudhra ha inavvertitamente rilasciato otto certificati intermedi legati a chiavi private non sicure. Questo compromesso potrebbe consentire agli attaccanti di generare certificati TLS e di firma del codice validi per nomi host arbitrari su Internet. Il problema rappresenta un rischio significativo per i client connessi alla rete, in particolare i sistemi embedded e i dispositivi che non hanno ricevuto aggiornamenti di sicurezza correnti.

Investigazione

L’indagine ha determinato che l’incidente è originato da chiavi private non sicure associate ai certificati intermedi di eMudhra. L’analisi si concentra sull’identificazione dei certificati nel traffico di rete con Zeek, confrontando gli hash delle loro Subject Public Key Info (SPKI). Questo approccio è più affidabile rispetto al confronto delle impronte digitali dei certificati poiché tiene conto anche dei certificati cross-signati e della potenziale malleabilità della firma.

Mitigazione

I principali fornitori di browser e sistemi operativi hanno aggiunto i certificati interessati ai meccanismi di sfiducia come CRLSet di Chrome e OneCRL di Mozilla. Gli utenti devono assicurarsi che i loro dispositivi siano completamente aggiornati per ricevere questi cambiamenti di sfiducia. Per il monitoraggio della rete, l’implementazione del pacchetto Zeek emudhra-weak-keys consente di rilevare i certificati interessati durante le strette di mano TLS.

Risposta

Quando Compromised_Intermediate_Cert le segnalazioni appaiono nei registri di Zeek, i team di sicurezza dovrebbero esaminare sia l’host di destinazione che il client in connessione. Un Compromised_Intermediate_Cert_Established avviso indica che il client ha accettato con successo un certificato potenzialmente fraudolento. Le organizzazioni dovrebbero anche verificare lo stato delle patch di dispositivi embedded, legacy e altri potenzialmente obsoleti nei loro ambienti.

Esecuzione della Simulazione

• Narrativa e Comandi dell’Attacco: L’avversario ha ottenuto un certificato dalla CA intermedia eMudhra compromessa. Per bypassare i controlli di sicurezza standard, hanno impostato un listener malevolo che presenta questo certificato durante la stretta di mano TLS. L’obiettivo è stabilire un canale C2 che sembri utilizzare una catena di fiducia valida, sebbene compromessa. Simuleremo questo utilizzando openssl per ospitare un server web locale usando un certificato che imita i metadati/impronte del certificato eMudhra compromesso, costringendo il sensore Zeek a attivare un “avviso” basato sulla sua logica di identificazione.

• Script di Test di Regressione:

  # 1. Generare un certificato fittizio che imiti la firma compromessa di eMudhra
  # In uno scenario reale, l'attaccante usa il certificato realmente compromesso.
  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. Avviare un server web locale utilizzando questo certificato
  # Usare un processo in background per ospitare il server
  openssl s_server -accept 4443 -cert cert.pem -key key.pem -quiet &
  SERVER_PID=$!
  
  # 3. Attendere l'inizializzazione del server
  sleep 2
  
  # 4. Attivare la stretta di mano TLS (Questo genera il traffico Zeek)
  # Nota: In un laboratorio reale, il sensore Zeek deve essere configurato con lo
  # script/plugin specifico che identifica questo certificato come 'Compromised_Intermediate_Cert'
  curl -k https://localhost:4443
  
  # 5. Pulizia (Gestita nella sezione pulizia)
  kill $SERVER_PID

• Comandi di Pulizia:

  # Rimuovere i file del certificato fittizio generato e fermare il server
  rm -f key.pem cert.pem
  # Se il processo del server è ancora in esecuzione:
  pkill -f "openssl s_server"