Compromission emSign / eMudhra - scanner de magasins de confiance

Outillage de détection pour la compromission de la clé privée de l'AC intermédiaire eMudhra / emSign d'octobre 2026. Huit AC intermédiaires ont été émises avec des clés P-384 dont les scalaires privés étaient de minuscules entiers (valeurs récupérées 4, 56, 66, 115, 155, 156, 230, 237), de sorte que n'importe qui peut trivialement forger des certificats qui s'enchaînent à elles. Les navigateurs et les magasins de confiance des systèmes d'exploitation ont rapidement poussé la défiance - mais la plupart des magasins de confiance hors navigateur ne se mettent pas à jour automatiquement, ce que cet outil détecte.

Statut : l'incident est en cours, donc considérez les IOCs fournis comme un instantané (chaque exécution affiche leur date generated). Pour les mettre à jour, rafraîchissez tools/sources/*.json depuis le tracker amont et relancez le générateur (ci-dessous).

trustscan (Python) et trustscan.ps1 (Windows/PowerShell) inventorient les magasins de confiance et les bundles d'AC sur un hôte et signalent tout ce qui correspond aux certificats affectés. Stdlib pure + cryptography ; aucune autre dépendance.

Démarrage rapide

Nécessite Python 3 et cryptography (la seule dépendance) :

pip install -r requirements.txt

# scan this host's trust stores and CA bundles
python trustscan.py

# machine-readable for ticketing
python trustscan.py --format csv > findings.csv

# Windows-native: cert stores (both scopes) + GPO roots + env bundles
pwsh -File trustscan.ps1

Codes de sortie : 0 = propre, 1 = résultat(s), 2 = erreur. Les résultats uniquement INFO (voir --flag-aaa ci-dessous) renvoient 0.

Chaque exécution se termine par une mise en garde d'une ligne sur le chemin de contre-signature AAA (voir Périmètre et limitations). En mode text, elle fait partie du rapport ; en mode json/csv, elle est envoyée sur stderr afin que la sortie lisible par machine reste propre.

Comment un certificat est mis en correspondance

Chaque certificat trouvé à n'importe quel emplacement ci-dessous est empreinté et vérifié de quatre manières :

Correspondance	Sévérité	Signification
compromised_ca_cert	CRITICAL	intermédiaire compromis exact (SHA-256 du certificat)
compromised_key_reuse	CRITICAL	un certificat différent portant une clé compromise (SHA-256 du SPKI) - détecte les contre-signatures Sectigo et toute réémission
issued_by_compromised_ca	HIGH	un certificat feuille/sous-CA dont l'AuthorityKeyIdentifier pointe vers un intermédiaire compromis - falsifiable
distrust_root_present	CRITICAL	une racine emSign non approuvée est encore approuvée ici. Sa propre clé est intacte - mais les clés intermédiaires sont publiques, donc tant que cette racine est approuvée, un certificat falsifié pour n'importe quel domaine est validé pour tout client qui ne vérifie pas la révocation (la plupart des clients non-navigateurs). Supprimez-la / mettez à jour le bundle. À elle seule, elle ne ferme pas le chemin de contre-signature AAA (ci-dessous)

Une vérification supplémentaire est optionnelle (--flag-aaa / -FlagAaa) :

Correspondance	Sévérité	Signification
cross_sign_root_present	INFO	la racine légitime Sectigo AAA Certificate Services est présente. Elle a contre-signé les huit intermédiaires, elle ancre donc leur second chemin de confiance ; sa propre clé est intacte. Mozilla et Chrome l'ont retirée en avril 2025, mais Windows, Apple, les anciens bundles Linux et de nombreux keystores Java l'approuvent encore. Signalée uniquement sur demande, pour les équipes décidant de la retirer (la mise à jour Debian pour cet incident le fait) ; n'affecte jamais le code de sortie

Par défaut, AAA Certificate Services n'est pas signalée : sa propre clé est intacte et sa suppression est un choix délibéré, pas une remédiation par défaut. Voir les limitations ci-dessous pour comprendre pourquoi cela importe.

Où trustscan cherche

Bundles de fichiers

Source	Ce que c'est	Emplacements vérifiés
certifi	Bundle de CA Python	certifi.where() (résolu à l'exécution)
bundles → distro	Agrégats ca-certificates du système d'exploitation	Debian/Arch/Alpine /etc/ssl/certs/ca-certificates.crt · RHEL /etc/pki/tls/certs/ca-bundle.crt, /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem, cacerts Java consolidé, répertoire anchors/ de l'administrateur · SUSE /etc/ssl/ca-bundle.pem, /var/lib/ca-certificates/ca-bundle.pem · Répertoire source Debian /usr/share/ca-certificates/ · /etc/ssl/cert.pem
bundles → FreeBSD	ca_root_nss	/usr/local/share/certs/ca-root-nss.crt · /usr/local/etc/ssl/cert.pem
bundles → Homebrew / MacPorts	brew / port ca-certificates, openssl	/opt/homebrew/etc/ca-certificates/cert.pem · /opt/homebrew/etc/openssl*/cert.pem · /usr/local/etc/... (Intel) · /opt/local/etc/{openssl,ssl}/cert.pem
bundles → curl	bundle curl autonome	/usr/local/share/curl/curl-ca-bundle.crt · /opt/local/share/curl/curl-ca-bundle.crt · C:\Program Files\Git\...\ca-bundle.crt
bundles → conda	ssl/cacert.pem de chaque environnement	$CONDA_PREFIX · /opt/conda · ~/anaconda3, ~/miniconda3, ~/miniforge3 (y compris envs/*)
bundles → AWS CLI v2	botocore embarqué	/usr/local/aws-cli/.../botocore/cacert.pem · C:\Program Files\Amazon\AWSCLIV2\...
bundles → SDK cloud / registre / écosystème	autres bundles embarqués	gcloud / Azure CLI third_party/certifi · registre de conteneurs /etc/{docker,containers}/certs.d/*/ · Perl Mozilla::CA · Erlang/Elixir certifi
bundles → pip	certifi embarqué dans pip	<pip>/_vendor/certifi/cacert.pem (résolu via import pip)
nss	Firefox / Thunderbird / Chrome-Linux + base de données NSS système	~/.mozilla/firefox/*/cert9.db · ~/.thunderbird/*/cert9.db · ~/snap/firefox/common/.mozilla/firefox/*/cert9.db · ~/.pki/nssdb/cert9.db · /etc/pki/nssdb/cert9.db · %APPDATA%\Mozilla\Firefox\Profiles\*\cert9.db · %APPDATA%\Thunderbird\Profiles\*\cert9.db

Magasins de confiance du système d'exploitation et autres sources