emSign / eMudhra-Kompromittierung - Trust-Store-Scanner

Erkennungstooling für die Private-Key-Kompromittierung der eMudhra / emSign Intermediate CA im Oktober 2026. Acht Intermediate CAs wurden mit P-384-Schlüsseln ausgestellt, deren private Skalare winzige Ganzzahlen waren (wiederhergestellte Werte 4, 56, 66, 115, 155, 156, 230, 237), sodass jeder trivial Zertifikate fälschen kann, die zu ihnen verketten. Browser und Betriebssystem-Trust-Stores haben die Distrustierung schnell vorangetrieben - aber die meisten Nicht-Browser-Trust-Stores aktualisieren sich nicht automatisch, und genau das findet dieses Tool.

Status: Der Vorfall ist aktuell, daher sind die mitgelieferten IOCs als Momentaufnahme zu behandeln (jeder Lauf gibt ihr generated-Datum aus). Um sie zu aktualisieren, aktualisiere tools/sources/*.json aus dem Upstream-Tracker und führe den Generator erneut aus (siehe unten).

trustscan (Python) und trustscan.ps1 (Windows/PowerShell) inventarisieren die Trust-Stores und CA-Bundles auf einem Host und markieren alles, was mit den betroffenen Zertifikaten übereinstimmt. Reine Standardbibliothek + cryptography; keine weiteren Abhängigkeiten.

Schnellstart

Benötigt Python 3 und cryptography (die einzige Abhängigkeit):

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

Exit-Codes: 0 = sauber, 1 = Befund(e), 2 = Fehler. INFO-only-Ergebnisse (siehe --flag-aaa unten) beenden den Lauf mit 0.

Jeder Lauf endet mit einem einzeiligen Hinweis zum AAA-Cross-Sign-Pfad (siehe Geltungsbereich & Einschränkungen). Im text-Modus ist er Teil des Berichts; im json/csv-Modus geht er an stderr, damit die maschinenlesbare Ausgabe sauber bleibt.

Wie ein Zertifikat abgeglichen wird

Jedes Zertifikat, das an einem der unten genannten Orte gefunden wird, wird mit einem Fingerabdruck versehen und auf vier Arten geprüft:

Übereinstimmung	Schweregrad	Bedeutung
compromised_ca_cert	CRITICAL	exakt das kompromittierte Intermediate (Zertifikat-SHA-256)
compromised_key_reuse	CRITICAL	ein anderes Zertifikat, das einen kompromittierten Schlüssel trägt (SPKI-SHA-256) – erfasst die Sectigo-Cross-Signs und jede Neuausstellung
issued_by_compromised_ca	HIGH	ein Leaf/Sub-CA, dessen AuthorityKeyIdentifier auf ein kompromittiertes Intermediate zeigt – fälschbar
distrust_root_present	CRITICAL	eine nicht vertrauenswürdige emSign-Root wird hier noch vertraut. Ihr eigener Schlüssel ist intakt – aber die Intermediate-Schlüssel sind öffentlich, sodass, solange dieser Root vertraut wird, ein gefälschtes Zertifikat für jede Domain bei jedem Client validiert, der den Widerruf nicht prüft (die meisten Nicht-Browser-Clients). Entfernen Sie ihn / aktualisieren Sie das Bundle. Für sich genommen schließt dies den AAA-Cross-Sign-Pfad (unten) nicht

Eine weitere Prüfung ist optional (--flag-aaa / -FlagAaa):

Übereinstimmung	Schweregrad	Bedeutung
cross_sign_root_present	INFO	die legitime Sectigo-Root AAA Certificate Services ist vorhanden. Sie hat die acht Intermediates cross-signiert und verankert damit deren zweiten Vertrauenspfad; ihr eigener Schlüssel ist intakt. Mozilla und Chrome haben sie im April 2025 entfernt, aber Windows, Apple, ältere Linux-Bundles und viele Java-Keystores vertrauen ihr weiterhin. Wird nur auf Anfrage gemeldet, für Teams, die entscheiden, ob sie sie entfernen (Debians Update für diesen Vorfall tut dies); beeinflusst niemals den Exit-Code

Standardmäßig wird AAA Certificate Services nicht markiert: Ihr eigener Schlüssel ist intakt und sie zu entfernen ist eine bewusste Entscheidung, keine Standard-Behebung. Siehe die Einschränkungen unten, warum dies wichtig ist.

Wo trustscan sucht

Datei-Bundles

Quelle	Was es ist	Geprüfte Speicherorte
certifi	Python-CA-Bundle	certifi.where() (zur Laufzeit aufgelöst)
bundles → Distribution	OS-ca-certificates-Aggregate	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, konsolidiertes Java-cacerts, Admin-anchors/-Verzeichnis · SUSE /etc/ssl/ca-bundle.pem, /var/lib/ca-certificates/ca-bundle.pem · Debian-Quellverzeichnis /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	eigenständiges curl-Bundle	/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 jeder Umgebung	$CONDA_PREFIX · /opt/conda · ~/anaconda3, ~/miniconda3, ~/miniforge3 (inkl. envs/*)
bundles → AWS CLI v2	gebündeltes botocore	/usr/local/aws-cli/.../botocore/cacert.pem · C:\Program Files\Amazon\AWSCLIV2\...
bundles → Cloud-SDKs / Registry / Ökosystem	weitere mitgelieferte Bundles	gcloud / Azure CLI third_party/certifi · Container-Registry /etc/{docker,containers}/certs.d/*/ · Perl Mozilla::CA · Erlang/Elixir certifi
bundles → pip	pips mitgeliefertes certifi	<pip>/_vendor/certifi/cacert.pem (aufgelöst über import pip)
nss	Firefox / Thunderbird / Chrome-Linux + System-NSS-DB	~/.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

OS-Truststores & weitere Quellen