Logjam-Attacke: Zehntausende Websites durch Schwäche in TLS-Verfahren gefährdet

Logjam-Attacke? Eine Schwäche im TLS-Verfahren kann dazu führen, dass verschlüsselte Verbindungen auf den unsicheren 512-Bit-Diffie-Hellman-Schlüsseltausch reduziert werden. Die Forscher, die dies entdeckt haben, mutmaßen, dass dieses Angriffsszenario auch hinter dem NSA-Programm Turmoil stecken könnte. Betroffen sind nicht nur Web-, sondern auch E-Mail-, SSH- sowie VPN-Server.

Ein Team aus Krypto-Forschern hat ausführliche Analysen zum Diffie-Hellman-Schlüsselaustausch in vielen Protokollen, darunter auch TLS, vorgenommen. Dabei gelang es, HTTPS-Verbindungen mittels Man-in-the-Middle-Angriffen in unsichere Export-Modi zu zwingen, die angreifbar werden. Angreifern wird es so ermöglicht, beispielsweise Javascript-Codes einzuschleusen oder den Datenverkehr mitzulesen. Die Forscher haben das Angriffsszenario „Logjam“ getauft – Namenspate ist der diskrete Logarithmus, der über die Sicherheit des Diffie-Hellman-Verfahrens entscheidet.

Logjam-Attacke: PFS durch Diffie-Hellman-Verfahren

Hinter dem klassischen Diffie-Hellman-Schlüsselaustausch steckt ein älteres Verfahren, mit dem der PFS-Zusatz in verschlüsselten Verbindungen aktiviert werden kann. Die Kommunikationspartner einigen sich dabei auf einen sogenannten Generator oder eine Gruppe; das klassische Diffie-Hellman-Verfahren verwendet als Gruppe eine große Primzahl. Genau diese Primzahl-Größe entscheidet nun über die Verfahrenssicherheit. 512 Bit gelten bereits seit langem als extrem unsicher, selbst 1.024 Bit sind problematisch und erst 2.048 Bit gelten heute als sicher.

Die Ursprünge dieser Sicherheitslücke liegen im Übrigen, wie schon im FREAK-Angriffsszenario, in der US-amerikanischen Gesetzgebung der 80er und 90er Jahre. Aufgrund der damaligen Export-Beschränkungen von Kryptographie führte man in SSL, dem TLS-Vorgänger, einen Export-Modus fürs Diffie-Hellman-Verfahren ein, der die Länge der Primzahl auf 512 Bit begrenzt. Normalerweise wird dieser Modus gar nicht mehr verwendet, jedoch unterstützen ihn viele Server aus Kompatibilitätsgründen. Das Forschungsteam geht davon aus, dass 8,4 % der Millionen beliebtesten Seiten eben diesen unsicheren Modus unterstützen.

Schwäche im TLS-Handshake

Theoretisch greift kein moderner Browser auf diesen Modus zurück. Doch führt eine Schwäche im TLS-Handshake dazu, den Modus doch zu verwenden: der Client schickt dem Server eine Algorithmen-Liste, aus dieser trifft der Server seine Wahl. Zu diesem Zeitpunkt ist der Handshake jedoch noch nicht signiert. Aktive Angreifer können nun den Handshake des Nutzers so ändern, dass dem Server nicht der gewöhnliche Diffie-Hellman-Schlüsselaustausch, sondern der unsichere Export-Schlüsselaustausch angeboten wird. Der Server reagiert seinerseits mit einer unsicheren Antwort aus der 512-Bit-Gruppe. Dass die meisten Clients auch im normalen Modus derartig kleine Gruppen akzeptieren, ist die eigentliche Krux dabei. Es ist ein Leichtes für Angreifer, die Serverantwort zu manipulieren und dem Client einen normalen Schlüsselaustausch mit unsicheren 512 Bits vorzugaukeln. Werfen Sie einen Blick auf diese Analyse von Golem: einige Browser akzeptieren sogar komplett unsichere Gruppen mit wenigen Bits.

Um den Angriff tatsächlich durchzuführen, ist es unumgänglich, den Schlüsselaustausch in Echtzeit zu erwischen – eine Herausforderung selbst für Spezialcomputer mit den besten Algorithmen. Damit der Schlüsselaustausch nach Diffie Hellman wirklich angegriffen werden kann, muss der diskrete Logarithmus kalkuliert werden, und das beste dafür existierende Verfahren ist das Zahlkörpersieb. Damit kann der Angriff sehr zielgerichtet stattfinden: sind die verwendeten Gruppen im Voraus bekannt, können auch die meisten Berechnungen vorab durchgeführt werden. Welche Gruppe verwendet wird, ist kein Geheimnis und in aller Regel setzen Server für sämtliche Verbindungen auf dieselben Gruppen – oftmals sind diese Gruppen sogar Teil der Software. Immerhin nutzen unter den Servern, die den Export-Modus unterstützen, sagenhafte 93 % dieselbe Gruppe!

Angriffe mit weniger als einer Minute

Die Forscher stellten ein Cluster mit mehreren tausend PCs zusammen und unternahmen eine Woche lang Vorberechnungen für eine bestimmte Gruppe. Im Anschluss konnte ein aktiver Angriff auf ein System (4 Intel-Xeon-E7-CPUs mit jeweils 6 Kernen) binnen durchschnittlich 90 Sekunden durchgeführt werden – die Geschwindigkeiten variierten zwischen 36 bis 260 Sekunden. Die Forscher mutmaßen, dass Spezialhardware und weitere Optimierungen dazu führen könnten, Angriffe auf unter eine Minute zu reduzieren und auch größere Gruppen zu kompromittieren.

Weniger als eine Minute ist immer noch recht lang für aktive Angriffe. Jedoch erleichtern diverse Browser mit ihren Eigenschaften das Angriffsszenario. Das Protokoll TLS unterstützt das Warning Alerts-Feature. In der Folge werden solche Pakete von den Browsern zwar ignoriert, jedoch wird der Timeout-Counter zurückgesetzt. In Firefox führt das dazu, dass sich Handshakes beliebig lang verzögern lassen, andere Browser brechen die Verbindung nach einer Minute ab. Angreifbar sind laut den Forschern Chrome, Firefox sowie Safari. Um eine HTTPS-Verbindung nun unbemerkt anzugreifen, setzen Angreifer nicht auf die eigentliche Seite, sondern wählen den Umweg über externe Ressourcen wie Tracking- oder Werbe-Javascript-Codes. Das fällt beim Seitenaufbau nicht weiter auf.

Konkret: wann besteht Gefahr?

Die Forscher sehen bei Diffie-Hellman ab 1.024 Bit keine Gefahren, jedoch vermuten die Forscher, dass Geheimdienste auch 1.024-Bit-Diffie-Hellman-Verfahren knacken können. Unterstützen Client und Server das Export-Verfahren („DHE_EXPORT“), kann ein Fallback auf 512 Bit erzwungen werden. Mithilfe der Vorberechnungen sind plötzlich Man-in-the-Middle-Angriffe auf die verschlüsselte Verbindung möglich. Admins haben die Möglichkeit, ihre Server in dem von den Forschern zur Verfügung gestellten Test zu prüfen. Sind Sie betroffen, deaktivieren Sie die Export-Verschlüsselung und erzeugen Sie eine spezifische 2.048-Bit-Diffie-Hellman-Gruppe (eine Beschreibung finden Sie auf der Server-Testseite). Während die Entwickler der verwundbaren Browser an Patches arbeiten, wurde die Lücke im Internet Explorer von Microsoft bereits mit dem letzten Patch-Day geschlossen.

Update: Core-Update 91 für IPFire 2.17 schließt Logjam-Lücke

Die Firewall-Distribution IPFire 2.17 bekommt das Core-Update 91 spendiert, das Sicherheitslücken in StrongSwan, der VPN-Server-/-Client-Komponente, sowie in der OpenSSL-Bibliothek schließt. Weiter stopft die OpenSSL-Version 1.0.2b sechs weitere Löcher, unter anderem die kritische Logjam-Lücke. StrongSwan in der Version 5.3.1 schließt die Lücke, mit der DoS-Attacken zur Code-Ausführung gestartet werden können. Daneben wurde der automatische P2P-Block bei einer Neuinstallation aufgehoben, da der P2P-Verkehr insgesamt rückgängig sei und IPFire zu viele Pakete fälschlicherweise als P2P erkannt hat. Ein vorhandener P2P-Block bleibt nach dem Upgrade eines laufenden Systems auf die Core-Version 91 erhalten. Alle Update-Details finden Sie auf IPFire.org.