Geknackte Cipher Suites und Hash-Funktionen: Fehlendes Bewusstsein

(Last Updated On: 6. September 2017)

Als Security Consultant stolpere ich bei Penerations-Tests und Security Audits immer wieder über die Tatsache, dass Kunden häufig noch unsichere Verschlüsselungsbibliotheken oder Hashes in Ihren Anwendungen verwenden. Die „großen“ Sicherheitslücken wie beispielsweise der Poodle-Angriff sind zwar häufig bekannt, jedoch hört es bei anderen Angriffsmethoden wie den Beast- und FREAK-Attacks auf. Ich möchte mit diesen Ungereimtheiten in diesem Blog-Beitrag aufräumen und einmal eine kurze aktuelle Übersicht über die bekanntermaßen verwundbaren Cipher Suiten und Hash-Funktionen aufstellen. Wir reden in diesem Beitrag über das kommende TLS 1.3, warum Sie von SSLv3 und TLS 1.0 die Finger lassen sollten, und welche Cipher Suites im aktuellen Stand als sicher anzusehen sind.

 Hash-Funktionen wie MD5 und SHA-1

Erst vor einigen Tagen veröffentlichte Troy Hunter, der Gründer der Website Have I been pwned? über 319 Millionen Passwort-Hashes, die er nach Dateneinbrüchen entnommen hatte. Diese Meldung zeigt, welche detaillierten Informationen (inklusive E-Mail-Adressen und Namen des Eigentümers des Passwortes) aus diesen Hashes gewonnen werden konnten.

Grundsätzlich, wenn Sie über die technischen Schwachstellen von Hash-Funktionen lesen, gilt es, zwei verschiedene Schwachstellen zu unterscheiden:

  • Wie einfach ist es, durch Brute Force den Hash Wert der Originaldaten zu finden?
    Wenn Sie beispielsweise Passwörter mit einer Hash-Funktion bearbeiten und das Ergebnis in einer Datenbank speichern, dann muss einerseits das Passwort eine ausreichende Komplexität haben, um zu verhindern, dass das Passwort durch Brute Force schnell erraten werden kann, um genau diesen Hash-Wert zu produzieren. Jedoch ist es auch wichtig, wie lange es dauert, um einen Schlüssel per Brute Force Methode zu testen. Dieser Faktor wird von der Komplexität der Hash-Funktion genutzt. Hierzu sollten Sie einen Algorithmus wählen, welcher das Key Stretching Verfahren unterstützt.
  • Wie anfällig ist die Hash-Funktion gegen eine sogenannte Collision? Eine Collision sagt aus, dass es möglich ist, dass zwei verschiedene Eingabedaten den gleichen Hash-Wert erzeugen, wenn der Hash-Algorithmus auf sie angewandt wird. In einem praktischen Beispiel heißt das, Sie können sich mit einem Passwort in einem System einloggen, welches gar nicht das eigentliche Passwort des Benutzers ist, nur weil dieses Passwort den selben Hash-Wert erzeugt. In einem noch strengeren Beispiel könnten Sie elektronische Signaturen fälschen. So könnten Sie sich etwa für den Microsoft Windows Update Server ausgeben (wenn deren Server-Zertifikate etwa mit einer SHA1-Signatur signiert sind) und einem Unternehmensnetzwerk Update-Pakete mit Schadsoftware unterjubeln, und das, obwohl Sie nicht das Original-Zertifikat verwenden.

Die Hash-Funktionen MD5 und SHA-1 haben in der Vergangenheit leider bewiesen, dass Sie gegen solche Szenarien verwundbar sind. So beziffern sich die Kosten einer SHA-1 Collision Attack zwar im sechsstelligen Bereich, sind damit aber definitiv mit dem Cash-Flow einer Nation oder Großorganisation abdeckbar.

Welche Hash-Funktion statt MD5 und SHA-1 verwenden?

Diese Frage stellen vor allen Dingen Entwickler, welche eine Hash-Funktion in Ihrer eigens entwickelten Software-Anwendung nutzen wollen. Für Passwörter sollten Sie auf dedizierte Algorithmen wie bcrypt, sha512crypt oder scrypt zugreifen. Vor allem scrypt eignet sich zu diesem Zweck, denn der Algorithmus erhöht die Menge an Speicher, die für das Cracken des Passwortes notwendig ist, enorm, stellt jedoch auch erhöhte Anforderungen an die speichernde Anwendung. Vergessen Sie nicht, zu den Passwörtern von Benutzern Pepper und Salt hinzuzufügen, bevor Sie eine Hash-Funktion auf diese anwenden. Hierbei sollte Pepper und Salt wiederum für jedes Passwort unique sein, damit zwei Benutzer mit dem gleichen Passwort nicht den selben Hash-Wert erzeugen.

Für alle anderen Hash-Vorgänge sollten Sie zumindest ein 256 Bit Mitglied einer Hash-Familie auswählen. Ein gängiges Beispiel wäre etwa SHA-3. Jedoch empfehle ich Ihnen den Sieger der Password Hashing Competition, Argon2. Von Argon2 gibt es zwei Varianten. Argon2i ist resistenter gegen Side-Channel Attacken, Argon2d resistenter gegen GPU Cracking Attempts.

 Protokolle und Verschlüsselungsbibliotheken

Bewegliche Daten werden heute meist verschlüsselt übertragen. Alle großen Online-Businesses liefern Ihre Daten heutzutage mit einer TLS-Verschlüsselung aus. SSLv3 sollten Sie bekanntermaßen nicht mehr verwenden. Doch wie sieht es mit anderen Cipher Suites aus?

Zur Klarstellung: SSLv3, TLS 1.1, TLS 1.2 und TLS 1.3 sind Protokolle zur Übertragung verschlüsselter Daten. Diese Protokolle haben den Inhalt anderer Anwendungsprotokolle wie beispielsweise HTTP oder LDAP als Inhalt und bekommen in Kombination meist einen Kombinationsnamen wie beispielsweise HTTPS oder LDAPS. Diese Protokolle haben die Aufgabe, die drei Säulen der IT-Sicherheit, nämlich

  • Vertraulichkeit
  • Authenzität
  • und Integrität

zu garantieren. Um dies zu gewährleisten, kombinieren diese Protokolle Verschlüsselung (Ein- oder Zwei-Wege-Verschlüsselung für Vertraulichkeit und Ein-Wege-Verschlüsselung für die Integrität) sowie X.509-Zertifikate für die Authentizität.

Diese Protokolle an sich können bereits Lücken haben (deshalb sollten Sie SSLv3  und TLS 1.0 beispielsweise nicht mehr verwenden), jedoch können die Inhalte der Daten, die in den Paketen des Protokolls beherbergt sind, mit verschiedenen Algorithmen verschlüsselt werden. Die Algorithmen, welche für die Verschlüsselung des Dateninhaltes verwendet werden, werden mit Hilfe einer sogenannten Cipher-Suite angegeben. Eine Cipher Suite ist eine Sammlung von einem oder mehreren Algorithmen, welche die Verschlüsselungslogik auf den Datenbestand anwenden. Sie besteht in der Regel aus vier Algorithmen für

  • den Schlüsselaustausch (z. B. RSA, DH oder PSK)
  • die Authentifizierung (z. B. RSA, DSA, PESK
  • die Hash-Funktion (wie MD5 oder SHA)
  • die Verschlüsselung (bspw. RC4, DES, 3DES, IDEA, AES)

Verschlüsselungsbilbiotheken mit MD5 Hash Funktion

Grundsätzlich sind Verschlüsselungsbibliotheken, die den MD5-Algorithmus beinhalten, per se nicht gleich als „unsicher“ einzustufen. Denn auch wenn MD5 an sich eine Hash-Funktion mit einer Verwundbarkeit gegen Collision Attacks ist, invalidiert dies nicht gleich die Sicherheit der gesamten Cipher Suite. Aus Publicity Gründen sperren Unternehmen jedoch häufig Cipher Suites auf Ihren Servern, welche MD5 verwenden, da dieser Algorithmus entsprechend einen schlechten Ruf in der Öffentlichkeit genießt. Zufälligerweise ist MD5 außerdem meistens in Cipher Suites enthalten, die außerdem RC4 einsetzen. Und RC4 wiederum ist ein Algorithmus, den Sie heutzutage wirklich vermeiden sollten.

DES und 3DES

Die beiden Verschlüsselungsalgorithmen, die vielen Administratoren aus der Verschlüsselung von SSH-Keys geläufig sind, werden aus gutem Grund heute nicht mehr verwendet. Sie basieren auf einem symmetrischen Verschlüsselungsverfahren mit einem 56- bzw. 64-Bit langem Schlüssel. Diese Art von Verschlüsselung kann heutzutage von mehreren Standard-FPGA-Boards innerhalb von 3-5 Tagen geknackt werden.

RC4

Für den RC4-Algorthmus wurden gleich mehrere Schwachstellen aufgedeckt. Deswegen sollte auch heutzutage jeder Cipher, welcher den RC4-Algorithmus beinhaltet, invalidiert werden. Es wird sogar mittlerweile nicht nur den Server-Administratoren, sondern auch den Benutzern von Webbrowsern empfohlen, diese Cipher Suiten manuell zu invalidieren, was jedoch dazu führen kann, dass Webserver, die nur auf Basis von RC4-Cipher arbeiten, nicht mehr erreicht werden können.

RSA_EXPORT

Verschlüsselungsbibliotheken, welche im Schlüsselaustausch das Verfahren RSA_EXPORT verwenden, sind evtl. anfällig gegen FREAK Attacks. Als Administrator sollten Sie den entsprechenden SSL-Servertest von SSLLabs durchlaufen. Anwender sollten prüfen, ob der eigens verwendete Webbrowser anfällig ist.

Gibt es denn eine Liste mit Empfehlungen?

Ja, die gibt es.  Eine gute Quelle für eine möglichst aktuelle Liste sicherer TLS Cipher Suiten ist der Mozilla SSL Configuration Generator. Demnach sind aktuell folgende Cipher Suiten als sicher anzusehen

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256

Wie sieht es mit dem kommenden TLS 1.3 aus?

All diese Cipher Suiten sind TLS 1.3 kompatibel. TLS 1.3 bringt viele sinnvolle Neuerungen mit sich, befindet sich jedoch aktuell in der Drafting Phase. OpenSSL 1.1.1 bringt bereits eine Unterstützung für TLS 1.3 mit. Webserver-Administratoren sollten den Trend daher gut beobachten, da es durchaus sein kann, dass der TLS 1.3-Draft in naher Zukunft verabschiedet wird und dann sofort softwareseitig umgesetzt werden kann.

Meine Angebote im Bereich der TLS 1.3 Verschlüsselung

Sie betreiben ein Online-Business und suchen einen günstigen Webserver, der den Umstieg auf TLS 1.3 nicht verschläft? Dann sehen Sie mich meine Managed Server Pakete an und kontaktieren Sie mich bei Interesse.

Sie suchen einen Penetrationstester, Test-Manager oder Security Auditor, welcher die aktuellen Standards im Bezug auf Kryptografiestandards im Auge behält? Informieren Sie mich über mein Leistungspaket im Security Sektor.

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!

Das könnte Dich auch interessieren...

1 Antwort

  1. 20. Oktober 2017

    […] Sie meinen Post über unsichere und geknackte Cipher Suites / Verschlüsselungs-Bibliotheken gelesen haben, ist Ihnen die Problematik von der Verwendung unsicherer […]

Kommentar verfassen