Pentest Blog

07. Februar 2017 – Know-how

SHA-1-Signaturen werden ungültig

Ein Fachartikel von IT-Security Consultant Dr. Adrian Vollmer

Mehrere große Hersteller von Browsern haben angekündigt, ab Anfang 2017 TLS-Verbindungen, die ein mit SHA-1 signiertes Zertifikat präsentieren, als unsicher zu behandeln. Bei Microsoft ist dies am 14. Februar 2017 der Fall. Dieser Beitrag gibt eine Übersicht über mögliche Auswirkungen im Firmenumfeld.

SHA-1 ist ein Hash-Algorithmus, der mehrere kryptografische Schwächen aufweist. Insbesondere besteht die Gefahr, dass ein Angreifer einen Kollisionsangriff erfolgreich durchführen kann. Dabei erstellt er ein harmloses Zertifikat und ein Zertifikat, das zum Signieren anderer Zertifikate verwendet werden darf, sodass beide Zertifikate den gleichen Hash-Wert besitzen. Das harmlose Zertifikat lässt er sich dann von einer anerkannten Zertifizierungsstelle signieren und schreibt die gleiche Signatur in sein zweites Zertifikat, das nun als anerkanntes Zwischenzertifikat beliebige Unterzertifikate problemlos signieren kann.

Kollisionsangriffe auf SHA-1 sind in letzter Zeit in greifbare Nähe gerückt. Es wurde von Sicherheitsforschern geschätzt, dass eine SHA-1-Kollision für einen Preis in der Größenordnung um $100.000 zu produzieren ist.

Auswirkungen

Hauptsächlich betroffen sind Browser, also insbesondere Internet Explorer 11, Edge, Firefox, Chrome und möglicherweise Safari. Hier wird der Besucher einer mit TLS geschützten Seite (also eine Seite, die über das Protokoll HTTPS aufgerufen wird) mit einer Warnmeldung konfrontiert, dass die Verbindung nicht sicher sei. Diese Warnmeldung lässt sich jedoch bei allen Browsern umgehen, sodass der Benutzer für diese Seite eine Ausnahmegenehmigung erteilen kann.

Darüber hinaus sind grundsätzlich alle Dienste betroffen, die die Windows Crypto API verwenden, um TLS-Zertifikate zu prüfen.

Zu beachten ist jedoch, dass ausschließlich Zertifikate von "öffentlichen" Zertifizierungsstellen betroffen sind, also Zertifikate, die bereits mit Microsoft Windows ausgeliefert werden (Windows Root Certification Program). Zertifikate, die von einer eigenen Zertifikatstelle ausgestellt wurden (oder von einem Hersteller, der eben nicht an oben genanntem Programm teilnimmt), werden auch weiterhin als gültig anerkannt, selbst wenn sie mit SHA-1 signiert wurden, solange sie entsprechend im Zertifikatspeicher importiert und als vertrauenswürdig markiert wurden.

Es werden keine Zertifikate aus dem Zertifikatspeicher entfernt, denn die Regelung betrifft nur untergeordnete Zertifikate und keine Wurzelzertifikate. Wurzelzertifikate sind immer selbstsigniert und daher niemals über andere Zertifikate validierbar. Selbstsignierte Zertifikate könnten genauso gut gar keine Signatur tragen, weshalb der verwendete Algorithmus irrelevant ist.

Nicht betroffen sind damit fast alle Dienste, die nicht öffentlich erreichbar sind, da "öffentliche" Zertifizierungsstellen diese nicht verifizieren können. Es gibt allerdings Ausnahmen: "Öffentliche" Zertifizierungsstellen können Wildcard-Zertifikate ausstellen. Das sind Zertifikate, die im Common Name eine Domäne wie zum Beispiel *.beispielfirma.de stehen haben. Hier kann es nun Subdomänen geben, die nur vom internen DNS-Server und nur auf interne IP-Adressen aufgelöst werden. So ist dann beispielsweise der Hostname beispielnetz.beispielfirma.de nur vom internen Netz aus erreichbar, präsentiert aber ein von einer "öffentlichen" Zertifizierungsstelle signiertes TLS-Zertifikat. Für diesen internen Dienst greift dann die SHA-1-Regelung.

Microsoft schränkt das Verhalten weiter ausdrücklich auf TLS-Serverzertifikate ein. Nicht betroffen sind demnach Clientzertifikate, S/MIME-Zertifikate, codesignierende Zertifikate etc.

Registry-Einstellungen

Laut einem Microsoft Whitepaper vom 05.11.2016 (s. u. Quellen [1]) ist es in der aktuellen Version von Microsoft Windows möglich, zum einen die Regelung frühzeitig zu aktivieren und zum anderen das alte Verhalten nach dem Stichtag wiederherzustellen. Dazu wird empfohlen, die folgenden Befehle auszuführen.

Zum frühzeitigen Aktivieren:

set LogDir=C:\Log
mkdir %LogDir%
icacls %LogDir% /grant *S-1-15-2-1:(OI)(CI)(F)
icacls %LogDir% /grant *S-1-1-0:(OI)(CI)(F)
icacls %LogDir% /grant *S-1-5-12:(OI)(CI)(F)
icacls %LogDir% /setintegritylevel L
Certutil -setreg chain\WeakSha1ThirdPartyFlags 0x80900004

Um den vorherigen Befehl rückgängig zu machen:

Certutil -delreg chain\WeakSha1ThirdPartyFlags
Certutil -delreg chain\WeakSignatureLogDir

Zum Deaktivieren nach dem Stichtag:

reg add HKLM\Software\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config\ /f /v WeakSha1ThirdPartyFlags /t REG_DWORD /d "80000000"

An diese Einstellung halten sich aber nur Anwendungen, die die Microsoft Windows Crypto API verwenden. Dieser Workaround wird außerdem ausdrücklich nicht empfohlen.

Empfehlungen

Grundsätzlich sollten alle Zertifikate, die noch SHA-1 verwenden, soweit wie möglich durch ein neues Zertifikat ersetzt werden, das mit einem SHA-2-Algorithmus (also beispielsweise SHA-256) signiert wurde.

Sollte dies stellenweise nicht möglich sein, empfiehlt die SySS GmbH, die SHA-1-Regelung auf einem ausgewählten Testclient vorzeitig zu aktivieren und die Funktion genau zu prüfen.

Im unwahrscheinlichen Fall, dass Systemdienste oder Software von Drittanbietern nicht mehr wie erwartet arbeiten, kann als Notlösung das alte Verhalten wiederhergestellt werden, zum Beispiel per Gruppenrichtlinie.

In jedem Fall sollten die Mitarbeiter und Endbenutzer Ihres Unternehmens rechtzeitig auf die Änderung aufmerksam gemacht und darauf hingewiesen werden, dass es vereinzelt zu Warnungen im Browser kommen kann. Idealerweise melden sich diese dann in der IT-Abteilung, die dann streng genommen den Fingerabdruck des präsentierten Zertifikats von Hand prüfen muss. Sie kann den Endbenutzer dann anweisen, wie vorzugehen ist.

Quellen

Die Aussagen in diesem Beitrag stützen sich auf die folgenden Quellen:

Microsoft behält sich das Recht vor, jederzeit von der geplanten Vorgehensweise abweichen zu dürfen, insbesondere wenn neue Schwächen von SHA-1 bekannt werden.

Termine

01.03.2017 - 02.03.2017
SySS-Schulung – Hack4: Angriffe gegen VoIP-Infrastrukturen
06.03.2017
Live-Hack mit Sebastian Schreiber, Quedlinburg
07.03.2017 - 08.03.2017
SySS-Schulung – Hack7: Sicherheit und Einfallstore bei Webapplikationen
09.03.2017
Live-Hack, DIGITALE TRANSFORMATION, Ravensburg