EN

Was ist der SWEET32-Angriff und wie kann man ihn verhindern?

In diesem Artikel:

Der SWEET32-Angriff ist eine Schwachstelle in der Cybersicherheit, die Blockchiffre-Kollisionen ausnutzt. Angreifer können 64-Bit-Blockchiffren verwenden, um HTTPS-Verbindungen zu kompromittieren. 

Obwohl Blockchiffre Algorithmen wie Triple-DES und Blowfish als Verschlüsselungsmodus für gängige Sicherheitsprotokolle weit verbreitet sind, ist die Wahrscheinlichkeit einer SWEET32-Schwachstelle eher gering, da eine Reihe anderer Bedingungen erfüllt sein müssen, um einen erfolgreichen Angriff durchzuführen. 

Im Folgenden wird erläutert, worum es sich bei dem SWEET32-Angriff handelt und wie Sicherheitsprobleme im Zusammenhang mit diesem Angriff verhindert werden können.

Was ist der SWEET32-Angriff?

Der SWEET32-Angriff basiert auf einer Sicherheitslücke in den in kryptografischen Protokollen verwendeten Blockchiffren. Er ähnelt dem RC4-Angriff in Bezug auf die Komplexität der Berechnungen. 

Blockchiffren werden bei vielen Gelegenheiten verwendet. OpenVPN nutzt beispielsweise als Standardchiffre Blowfish. Fast alle HTTPS-Webserver unterstützen den Triple-DES-Algorithmus.

The SWEET32 attack visually represented in a graphic - Crashtest Security

Wie funktioniert das?

Protokolle wie TLS, SSH und OpenVPN verwenden häufig Blockchiffrieralgorithmen für die Verschlüsselung der Daten, die zwischen Webservern und Clients übertragen werden. Zu den gängigsten Algorithmen gehören Triple-DES, Blowfish und AES. Bei ihnen werden die übertragenen Daten in Stücke einer bestimmten Länge – Blöcke – zerhackt, anstatt den Klartext Bit für Bit zu verschlüsseln. Die Blöcke werden dann in einer bestimmten Betriebsart verschlüsselt. 

Die Blocklänge des Verschlüsselungsalgorithmus unterscheidet sich von der Länge des Schlüssels. Die Blocklänge wird dabei durch den Algorithmus festgelegt. Selbst wenn Sie sich also für eine große Schlüssellänge entscheiden, kann diese durch die Chiffre begrenzt sein. 

Bei den Algorithmen Triple-DES und Blowfish beträgt die Blockgröße 64 Bit, während sie bei AES 128 Bit beträgt. Je kürzer eine Blockgröße ist, desto anfälliger ist sie für einen Geburtstagsangriff – eine Art von Anfälligkeit, die auf dem Geburtstagsproblem in der Wahrscheinlichkeitstheorie beruht. Dies macht 128-Bit-Verschlüsselungen wie AES sicherer.  

Kurze Blockgrößen machen Webserver anfällig dafür, denselben Hash für mehrere Eingaben zu verwenden. Durch die Beobachtung des Datenaustauschs zwischen einem Webserver und einer Website über einen längeren Zeitraum hinweg können Angreifer sichere HTTP-Cookies wiederherstellen. 

Kurz gesagt: Wie sicher eine Blockchiffre ist, hängt von der Schlüsselgröße (k) ab. Wenn ein Angriff mit erschöpfender Schlüsselsuche eine Komplexität von 2k hat, kann er tatsächlich sichere Daten offenlegen. Bei CBC (3DES-CBC-Chiffren) und ähnlichen Verschlüsselungsverfahren (CTR, GCM, OCB und andere) ist die Blockgröße (n) ebenfalls ein Sicherheitsfaktor, wenn Blockchiffren große Datenmengen verschlüsseln. Solche Blockchiffren können nur eine bestimmte Anzahl von Blöcken verschlüsseln – nachdem 2n/2 Datenblöcke mit demselben Schlüssel verschlüsselt wurden – bevor es zu einer Kollision zwischen zwei Chiffrierblöcken in der Ausgabe kommt, was bedeutet, dass ein identischer Chiffretext erzeugt wird. Dies würde zur gleichen Eingabe führen, die es wiederum ermöglicht, die Klartextblöcke der sicheren Daten zu erhalten. 

Im Falle von 64-Bit-Blockchiffrieralgorithmen kann ein Kollisionsangriff nach etwa 32 GB Daten erfolgen. Wenn ein Angreifer mit Hilfe von JavaScript, das einen Hochgeschwindigkeitsstrom vom Browser zum Webserver sendet, eine ausreichende Datenmenge generiert, kann er Zugang zu HTTP-Sitzungscookies erhalten. Experimente haben jedoch gezeigt, dass für einen praktischen Kollisionsangriff bis zu 785 GB an Daten benötigt werden können. Dies machte ein Angriffsszenario nicht so einfach durchführbar.

Entdeckung der SWEET32-Schwachstelle

Karthikeyan Bhargavan und Gaëtan Leurent, Forscher am INRIA, dem nationalen französischen Forschungsinstitut für Informatik, entdeckten die Schwachstelle im Jahr 2016. Ihre Versuche zeigten, dass die Wiederherstellung eines HTTP-Sitzungscookies mit der Methode der langen Beobachtung in weniger als zwei Tagen möglich ist. 

Die Kategorisierungen umfassen CVE-2016-2183 für DES- und Triple-DES-Chiffren und CVE-2016-6329 für die Blowfish-Chiffre-Schwachstelle im CBC-Modus. 

Kryptographen wussten schon vorher von dieser potenziellen Schwachstelle, aber das Ausmaß und die Geschwindigkeit, mit der sie ausgenutzt werden kann, wurden erst von den INRIA-Forschern enthüllt. 

Auswirkungen

Die Algorithmen DES, Triple-DES und Blowfish werden häufig für die Verschlüsselung von Blockchiffren für wichtige Protokolle wie TLS, SSH und OpenVPN verwendet. Das bedeutet, dass ein böswilliger Benutzer unter den richtigen Bedingungen Zugriff auf HTTP-Sitzungscookies erhalten kann. Zu den Bedingungen gehören eine längere Überwachung des Datenverkehrs und die Ausführung von JavaScript im anfälligen Browser, um den Benutzer dazu zu bringen, eine vom Angreifer kontrollierte Website zu öffnen.

Da OpenVPN den Blowfish-Algorithmus verwendete, war die große Mehrheit der VPN-Benutzer für den SWEET32-Angriff anfällig. 

Die Triple-DES-Chiffren waren bei HTTPS-Webservern recht beliebt. Für Sitzungen mit modernen Browsern würden diese Server jedoch immer noch eine Chiffre für eine stärkere Verschlüsselung bevorzugen. Deshalb fanden die INRIA-Forscher heraus, dass nur 1-2 % der HTTPS-Webserver auf eine schwache Verschlüsselung wie Triple-DES setzen. Von diesen haben nur 0,6 % eine falsche Konfiguration, die sie dem Risiko von SWEET32-Angriffen aussetzt. Die meisten Server sind so konfiguriert, dass sie stärkeren Chiffriersuiten den Vorzug geben. Daher ist die Triple-DES-Schwachstelle nicht so verbreitet.   

Dennoch waren einige hochkarätige Websites, die mindestens eine Million Anfragen in einer Verbindung akzeptieren – wie eBay, NASDAQ, Walmart, Amadeus, Bank-Websites und andere – gefährdet, als die SWEET32-Angriffsschwachstelle entdeckt wurde.

Präventionsleitfaden für SSL/TLS-Schwachstellen

Leitfaden

Erfahren Sie, wie Sie verschiedene Arten von SSL/TLS-Schwachstellen erkennen und verhindern können.

Mehr erfahren

Maßnahmen nach der Entdeckung

Als die SWEET32-Schwachstelle entdeckt und von Sicherheitsexperten öffentlich bekannt gegeben wurde, mussten alle großen Webbrowser, OpenSSL und OpenVPN Maßnahmen ergreifen, um das Sicherheitsrisiko zu beseitigen. Dies setzte die Softwarehersteller und Entwickler unter Druck, die anfälligen Versionen zu ersetzen und starke Verschlüsselungen einzuführen. 

Insgesamt gab es keine spezifischen Maßnahmen, die für normale Benutzer empfohlen wurden. OpenVPN-Benutzer können ihre Einstellungen über die Konfigurationsanweisung reneg-bytes auf regelmäßigeres Rekeying umstellen.

SSL SWEET32 Sicherheitsbewertung

Security Assessment Prevent SSL SWEET32

CVSS-Vektor: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Wie man SSL SWEET32-Angriffe verhindert

Um SWEET32-Angriffe zu verhindern, müssen Sie sicherstellen, dass Ihre Systeme nur starke Chiffren mit großen Blockgrößen verwenden. Eine moderne Blockchiffre würde sich auf eine höhere Anzahl von Blöcken stützen. 

Unter Sichere TLS-Konfiguration finden Sie weitere Informationen darüber, wie Sie gute Cipher-Suites konfigurieren und die Wahrscheinlichkeit von Blockchiffre-Kollisionen minimieren können.

Möchten Sie das Sicherheitsniveau Ihrer Webanwendung oder API überprüfen? Sie können den SSL Vulnerability Scanner von Crashtest Security verwenden, um Schwachstellen sofort zu entdecken.

Erhalten Sie jetzt kostenlos einen schnellen Sicherheitsbericht für Ihre Website

Wir analysieren derzeit https://example.com
Wir scannen derzeit https://example.com
Status des Scans: In Bearbeitung
Scan target: http://example.com/laskdlaksd/12lklkasldkasada.a
Datum: 24/06/2022
Crashtest Security Suite prüft auf:
Information disclosure Known vulnerabilities SSL misconfiguration Open ports
Scanauftrag ausfüllen
Bitte geben Sie Ihre Daten ein, um die schnelle Sicherheitsüberprüfung zu erhalten.
Ein Sicherheitsspezialist analysiert gerade Ihren Scan-Bericht.
Bitte geben Sie Ihre Telefon-/Handynummer an, damit wir Ihre Identität überprüfen können:
Vielen Dank.
Wir haben Ihren Antrag erhalten.
Sobald Ihr Sicherheitsaudit fertig ist, werden wir Sie benachrichtigen.