Analyse de l’incident CA d’eMudhra : Résultats clés et impact

Résumé

L’Autorité de Certification indienne eMudhra a involontairement émis huit certificats intermédiaires liés à des clés privées non sécurisées. Ce compromis pourrait permettre aux attaquants de générer des certificats TLS et de signature de code valides pour des noms d’hôte arbitraires sur Internet. Ce problème représente un risque important pour les clients connectés au réseau, en particulier les systèmes embarqués et les appareils qui n’ont pas reçu les mises à jour de sécurité actuelles.

Enquête

L’enquête a déterminé que l’incident provenait de clés privées non sécurisées associées aux certificats intermédiaires eMudhra. L’analyse se concentre sur l’identification de ces certificats dans le trafic réseau avec Zeek en correspondant les hachages de leurs informations de clé publique du sujet (SPKI). Cette approche est plus fiable que la correspondance d’empreintes de certificat car elle prend également en compte les certificats croisés et la malléabilité potentielle de la signature.

Atténuation

Les principaux fournisseurs de navigateurs et de systèmes d’exploitation ont ajouté les certificats concernés aux mécanismes de méfiance tels que CRLSet de Chrome et OneCRL de Mozilla. Les utilisateurs doivent s’assurer que leurs appareils sont entièrement à jour pour recevoir ces modifications de méfiance. Pour la surveillance du réseau, déployer le paquet Zeek emudhra-weak-keys permet la détection des certificats concernés lors des poignées de main TLS.

Réponse

Lorsque Compromised_Intermediate_Cert les avis apparaissent dans les journaux Zeek, les équipes de sécurité doivent examiner à la fois l’hôte de destination et le client connecté. Une Compromised_Intermediate_Cert_Established alerte indique que le client a accepté avec succès un certificat potentiellement frauduleux. Les organisations doivent également vérifier l’état des correctifs des appareils embarqués, anciens et autres potentiellement obsolètes dans leurs environnements.

Exécution de simulation

• Narratif & Commandes de l’attaque : L’adversaire a obtenu un certificat de l’autorité de certification intermédiaire eMudhra compromis. Pour contourner les contrôles de sécurité standard, ils ont mis en place un écouteur malveillant qui présente ce certificat lors de la poignée de main TLS. L’objectif est d’établir un canal C2 qui semble utiliser une chaîne de confiance valide, bien que compromise. Nous allons simuler cela en utilisant openssl pour héberger un serveur web local utilisant un certificat qui imite les métadonnées/empreinte du certificat eMudhra compromis, forçant le capteur Zeek à déclencher un « avis » basé sur sa logique d’identification.

• Script de test de régression :

  # 1. Générer un certificat fictif qui imite la signature eMudhra compromise
  # Dans un scénario réel, l'attaquant utilise le certificat compromis réel.
  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. Démarrer un serveur web local utilisant ce certificat
  # Nous utilisons un processus en arrière-plan pour héberger le serveur
  openssl s_server -accept 4443 -cert cert.pem -key key.pem -quiet &
  SERVER_PID=$!
  
  # 3. Attendre l'initialisation du serveur
  sleep 2
  
  # 4. Déclencher la poignée de main TLS (Cela génère le trafic Zeek)
  # Remarque : Dans un laboratoire réel, le capteur Zeek doit être configuré avec le script/plugin spécifique
  # qui identifie ce certificat comme 'Compromised_Intermediate_Cert'
  curl -k https://localhost:4443
  
  # 5. Nettoyage (Géré dans la section de nettoyage)
  kill $SERVER_PID

• Commandes de nettoyage :

  # Supprimer les fichiers de certificat fictif générés et arrêter le serveur
  rm -f key.pem cert.pem
  # Si le processus du serveur est toujours en cours d'exécution :
  pkill -f "openssl s_server"