21.05.2015 16:10

CVE-2015-4000 alias "Logjam" ..

.. alias "Yet another downgrade-attack" alias "Don't panic in the face of the cryptocalypse". Beim ersten Überfliegen der Informationsseite ist man geneigt, die Problematik als eine zweite Version der bekannten 'FREAK'-Attacke abzutun.

Während jedoch die Implikationen des Angriffs gleich sind - ein Angreifer bekommt potentiell die Möglichkeit, vertrauliche Informationen mitzuschneiden - ist die Problematik eine andere. 'FREAK' war ein aktiver Angriff auf den RSA-Key-Exchange während die Sicherheitsforscher auf weakdh.org sowohl aktive als auch passive Angriffe auf den Diffie-Hellman-Key-Exchange (DH) beschreiben.

Schwachstelle

'Logjam' besteht also aus zwei separaten Problemen:

  • Wiederverwendung von Moduli zur DH-Generierung.

Die Sicherheit von DH basiert auf der Komplexität der Berechnung von diskreten Logarithmen in Restklassen Modulo einer Primzahl. Ein großer Teil des Aufwandes der Berechnung hängt aber nur vom Modulus ab, nicht aber vom Exponenten oder der Basis. Hat man diese Vorberechnungen einmal gemacht, dann ist der diskrete Logarithmus -- und damit das Brechen von DH -- nicht mehr sehr aufwändig. Man kann das in etwa mit Rainbow-Tables für das Passwort-Knacken vergleichen.

Viele Softwareprodukte, darunter auch bekannte Namen wie OpenSSH oder nginx, verwenden ein kleines Set an vordefinierten Moduli (zu finden hier und hier) für die Generierung der DH-Parameter, wenn man Ihnen nicht anderweitige Anweisungen gibt.

Werden Moduli mit nur 512 Bits verwendet - das ist leider nicht nur die Ausnahme - dann reichen die Ressourcen von Sicherheitsforschern aus, um die entsprechenden Tabellen zu berechnen, und damit TLS-Verbindungen zu entschlüsseln. Hierzu ist kein man-in-the-middle nötig: ein rein passives Mitlauschen reicht. Ein Angreifer mit entsprechenden Ressourcen, beispielsweise (ein) NSA (Nation State Actor - ein Schelm wer hier etwas anderes dachte!), ist mit grösster Wahrscheinlichkeit in der Lage, die relevanten Tabellen für stärkere Varianten zu berechnen.

'NSA' ist ein gutes Stichwort: Aus den Snowden-Leaks ging bereits vor längerer Zeit hervor, dass die NSA (diesmal wirklich die National Security Agency) gezielt versucht, verschlüsselte Verbindungen - insbesondere VPN-Verbindungen aller Art und HTTPs - aufzubrechen. Es gab auch deutliche Hinweise dass Ihnen dies für schwache Verschlüsselungen bereits gelungen ist - die Enteckung von 'Logjam' könnte einige der Fragen nach dem 'Wie?' beantworten.

  • Downgrade-Attacke.

Nachdem es also möglich ist, DH-Parameter zu brechen kann ein Angreifer dies, im Zusammenspiel mit den berüchtigten 'Export Ciphers', nutzen, um eine Downgrade-Attacke auf eine TLS-Verbindung durchzuführen.

  • Ein Man-in-the-Middle fängt die Verbindung zwischen dem Client und dem Server ab und ersetzt alle akzeptablen Ciphersuites mit Export Ciphers
  • Der Server entscheidet sich daraufhin für die schwachen Ciphers und fährt mit dem regulären Key Exchange fort
  • Der Client hat keine Möglichkeit zu wissen, dass er gerade Opfer einer MitM-Attacke wird und nimmt an, dass sich der Server die schwachen Ciphers freiwillig ausgesucht hat
  • Der Angreifer kann nun aufgrund der verwendeten, schwachen, DH-Parameter diese brechen, den Session-Key ergattern und den verschlüsselten Traffic mitlesen

Die einzige Möglichkeit die der Client hat, sich vor so einem Angriff zu schützen, ist das Ablehnen von Parametern <1024 Bit. Serverseitig ist die Deaktivierung der Export Ciphers sowieo die Verwendung eines eigenen Modulisets empfehlenswert.

Mitigation

Um die Sicherheitslücken zu mitigieren sind serverseitig folgende Schritte empfohlen:

  • Deaktivierung von Export-Cipher-Suites.

Wer dies nach dem Bekanntwerden von CVE-2015-0204 noch nicht getan hat sollte dies nun dringend nachholen; keine Clientsoftware (nicht einmal Internet Explorer 6) ist heute mehr auf diese angewiesen. Für die gängigste Serversoftware finden sich unter weakdh.org/sysadmin.html zahlreiche Hinweise. Für exotischere Software empfiehlt es sich, mit dem Hersteller beziehungsweise dessen Support Kontakt aufzunehmen.

Wichtig ist jedoch zu beachten, dass viele Server auch verwundbare Parameter für Non-Export-DHE anbieten, um veraltete TLS-Versionen (Paradebeispiel dafür: veraltetes Java) zu unterstützen. Hier sollte genau geschaut werden, um unerwünschte Überraschungen zu vermeiden.

  • Aktivierung von Elliptic-Curve Diffie-Hellman (ECDHE).
Der Einsatz von ECDHE ermöglicht die Vermeidung nahezu aller realistischen Angriffe auf das verwendete Kryptosystem, die meisten Webbrowser bevorzugen ECDHE gegenüber 'normalem' DHE bereits.

  • Generierung einer eigenen DH-Gruppe mit sinnvoller Grösse..
Auf allen Systemen, die OpenSSL installiert haben lässt sich dies mit folgendem Befehl durchführen:

openssl dhparam -out dhparams.pem 4096

(Siehe dazu auch den aktuellen Blogeintrag des BetterCrypto Project.) Informationen zur entsprechenden Konfiguration finden sich auf der oben verlinkten Seite. Für Apache ist zu beachten dass die Verwendung von selbstgenerierten DH-Parametern erst mit der Version 2.4.7 unterstützt wird.

Clientseitig sind Browser das wohl grösste Angriffsziel. Dementsprechend ist damit zu rechnen dass die minimale Grösse für DH-Parameter von momentan (je nach Browser) 512 Bits / 768 Bits auf mindestens 1024 Bits angehoben wird. Dementsprechend ist die Wahrscheinlichkeit hoch, dass es in naher Zukunft für alle grossen Browser Updates geben wird. Nutzer von Apple's Safari sollten jedoch für den Moment besondere Vorsicht walten lassen:

In our experiments, Internet Explorer, Chrome, Firefox, Opera, all accepted 512-bit primes, whereas Safari allowed groups as small as 16 bits

Gleichzeitig sollten auch andere, nicht weniger kritische Applikationen - wie beispielsweise Mailclients - nicht ausser Acht gelassen werden und, sobald möglich, gepatcht werden. Sollte jemand an detaillierten technischen Informationen interessiert sein, so haben die Sicherheitsforscher das akademische Paper ebenfalls auf der Seite der Schwachstelle veröffentlicht.

Links:

Post Scriptum: Es ist uns bekannt, dass https://cert.at momentan in Bezug auf dieses Problem nicht optimal konfiguriert ist. Aufgrund der in Debian Wheezy vorhandenen Version von Apache ist eine simple Anwendung der Hinweise aus den obigen Links leider nicht so einfach möglich. Wir arbeiten bereits an einer Lösung.

Autor: Alexander Riepl