Der lange Abschied von RC4

Posted on Posted in Hacker News

Er ist angreifbar – und die NSA liest angeblich mit: Die Internet Engineering Taskforce hat den Einsatz des einst beliebtesten Verschlüsselungsalgorithmus RC4 untersagt. Doch Sicherheit lässt sich nicht einfach verordnen.

Minimale Codebasis, einfache Implementierung und ein sehr geringer Ressourcenverbrauch in der Anwendung: Lange galt RC4 als beliebtester Verschlüsselungsalgorithmus – obwohl Sicherheitsforscher im Lauf der Jahre kritische Lücken fanden. Aber erst 2014 kam das Aus: Die Internet Engineering Task Force (IETF) verbot den Einsatz von RC4 für TLS-Verbindungen.

Vor wenigen Tagen haben Forscher erneut verbesserte Angriffe gegen RC4 veröffentlicht. Dennoch ist RC4 auf vielen Webseiten weiter im Einsatz, und der Abschied von dem unsicheren System vollzieht sich nur schleppend. Denn viele Webdienste fürchten Kompatibilitätsprobleme, wenn sie den Algorithmus einfach abschalten.

Verschlüsselung in Block und Strom

Außerdem befinden sich nach jahrelanger Nutzung RC4 und ähnliche veraltete Kryptostandards tief in vielen Programmbibliotheken. Der Algorithmus wurde 1987 von dem Mathematiker und Kryptologen Ron Rivest vorgestellt. RC4 steht wahlweise für Rivest Cipher oder Rons Code. Mit Hilfe eines deterministischen Pseudozufallszahlengenerators wird dabei aus einem vorliegenden Schlüssel ein Schlüsselstrom erzeugt. Der Schlüsselstrom wird dann mit Hilfe einer XOR-Verknüpfung mit dem zu verschlüsselnden Text verknüpft.

RC4 ist eine sogenannte Stromverschlüsselung. Im Unterschied zu Blockchiffren werden die zu verschlüsselnden Informationen Bit für Bit mit dem Schlüsselstrom zu einer Nachricht verschlüsselt. Aus diesem Grund eignen sich Stromchiffren vor allem für Anwendungsszenarien, die Echtzeit-Verschlüsselung verlangen. Sie sind schlicht schneller als Blockchiffren, bei denen immer erst der nächste Block mit Daten aufgefüllt werden muss, bevor die eigentliche Chiffrierung beginnen kann.

Die Zufallszahlen können berechenbar sein

Die Verschlüsselung arbeitet schnell und lässt sich ohne großen Aufwand implementieren – deshalb fand sie eine weite Verbreitung. Der Algorithmus war lange ein Geschäftsgeheimnis der Firma RSA Security, bis der Quellcode im Jahr 1994 auf einer Mailingliste auftauchte. Der Schöpfer des Codes bestätigte die Echtheit der geleakten Informationen später indirekt, indem er auf die Wikipedia-Seite zu dem Thema verlinkte. Dass RC4 unter dem Namen Arcfour (Alleged RC4) nun öffentlich verfügbar war, trug zur weiteren Verbreitung des Algorithmus bei.

RC4 hat jedoch ein grundlegendes Problem: Die Pseudozufallszahlen, die der Algorithmus als Basis für die Verschlüsselung benutzt, nehmen bestimmte Werte mit einer höheren Wahrscheinlichkeit an. Mit RC4 verschlüsselter Text weist somit wiederkehrende Elemente auf. Für sich betrachtet, ist das zunächst kein großes Problem. Wenn ein Angreifer jedoch viele so verschlüsselte Dokumente zur Verfügung hat, kann er mittels stochastischer Analysen den Ausgangstext bestimmen


 

Erste Angriffe stoppen die Verbreitung nicht

Schon 2001 nutzte ein erster Angriff diese Berechenbarkeit aus. Er richtete sich gegen die WLAN-Verschlüsselung WEP. Der Vorgänger des heute üblichen WPA2-Standards nutzte zur Absicherung des Netzwerkes RC4. Da beim Aufbau einer WLAN-Verbindung häufig berechenbare, wiederkehrende Informationen verschickt werden, gelang es Angreifern, aus der Masse der übertragenen Daten das Passwort zu extrahieren.

Dieser Angriff führte früh zu massiven Schäden. Hackern gelang es im Jahr 2005 zum Beispiel, in das Firmennetzwerk des US-Unternehmens TJ Maxx einzudringen und dort über mehrere Jahre unerkannt Kundendaten und Kreditkarten-Informationen zu entwenden. Sie nutzten dabei das mit WEP unzureichend abgesicherte WLAN-Netzwerk der Firma aus, um ihre Schadsoftware zu installieren. Schätzungen von Branchenkennern zufolgeverursachte der Angriff einen Schaden von bis zu einer Milliarde US-Dollar.

Schlüsselstrom beschneiden, Sicherheit verbessern

Der 2001 aufgedeckte Angriff gegen WEP führte jedoch nicht dazu, dass der Einsatz von RC4 flächendeckend eingestellt wurde. Der Angriff wurde von Sicherheitsexperten vor allem einer mangelhaften Implementation des Verschlüsselungsstandards zugeschrieben.

Um diese ersten Angriffe gegen RC4 abzuwehren, empfahl RSA Security im Jahr 2011, bei der Implementierung einer RC4-Verschlüsselung die ersten 256 Zeichen des Schlüsselstroms zu streichen, da hier besonders häufig wiederkehrende Muster erkennbar waren. Alternativ sollten Nutzer den Schlüsselstrom mit einem Verfahren wie MD5 hashen. Unter diesen Voraussetzungen, so die Firma damals, sei der Algorithmus sicher.

Dieses Vorgehen schwächte die Probleme tatsächlich ab, es funktioniert jedoch nicht unter allen Umständen. Dieser Versuch zur Absicherung steht einem wichtigen Einsatzgebiet von RC4 im Weg, nämlich dem im Rahmen von TLS. Denn die TLS-Spezifikationen erschweren einen solchen Eingriff.

RC4 profitiert vom Beast-Angriff

RC4 profitierte allerdings im Jahr 2011 von einem Angriff auf die in TLS verwendeten Blockchiffren, etwa AES. Im September des Jahres stellten die Sicherheitsforscher Juliano Rizzo und Thai Duong einen praktikablen Angriff auf das TLS-Protokoll vor. Die Beast-Attacke (Browser Exploit Against SSL/TLS) nutzte Fehler, die bei der Verschlüsselung von Webtraffic mit Blockchiffren entstanden, um mittels eines Man-in-the-Middle-Angriffs geheime Daten auszulesen.

Da gegen die in SSL genutzte Implementierung von RC4 zu diesem Zeitpunkt noch kein praktikabler Angriff vorlag, empfahlen zahlreiche Sicherheitsforscher, RC4 anstelle der angegriffenen Blockchiffren zu nutzen. Dies führte zu einer enormen Zunahme der Verwendung von RC4. Schätzungen zufolge betrug der Anteil zeitweise mehr als 50 Prozent des mit TLS/SSL verschlüsselten Traffics.

Der Kryptograph Matthew Green warnte bereits 2011 in seinem Blog davor, die Verschlüsselung einfach auf RC4 umzustellen und verwies auf ein Beispiel aus der Erziehung seiner Kinder. “Habe ich schon mal jemanden gesehen, der sich ein Auge ausgestochen hat, weil er mit einer Schere in der Hand gerannt ist? Nein. Und trotzdem warne ich meine Kinder und sage: Rennt nicht mit der Schere in der Hand um den Pool.”

Der Anfang vom Ende: ein praktikabler Angriff

Alle bislang vorgestellten Angriffe gegen RC4 wiesen erfolgreich nach, dass der Algorithmus grundlegende Schwächen hat. Einen in der Praxis unter realen Bedingungen praktikablen Angriff gab es bis zu diesem Zeitpunkt jedoch nicht. Das änderte sich im Jahr 2013.

In dem Jahr stellte ein Team um den Verschlüsselungsexperten Dan Bernstein einen in der Praxis implementierbaren Angriff auf RC4 in TLS-Verbindungen vor. Das Team nutzte die seit langem bekannten Regelmäßigkeiten im Cipher-Text aus. Es gelang ihm nachzuweisen, dass es auch nach den ersten 256 Zeichen Regelmäßigkeiten im chiffrierten Text gibt.

Eigentlich sind mehrere Gigabyte an abgefangenen Daten erforderlich, um den Angriff erfolgreich durchzuführen. Doch da Internetprotokolle eine hohe Standardisierung mit vielen wiederkehrenden Elementen aufweisen, reichen unter Umständen schon weniger Daten aus – das Team um Bernstein spricht von 2 hoch 24 Verbindungen. Damit seien bestimmte Webapplikationenverwundbar.

Nach neuesten Erkenntnissen ist jedoch nicht nur die Implementierung von RC4 in Webdiensten angreifbar, sondern auch im E-Mail-Protokoll IMAP. Auch dies geht auf die ursprüngliche Schwachstelle des Algorithmus zurück. Da bei IMAP bereits an früherer Stelle im Datenstrom ein Passwort übertragen wird, reduziert sich die Anzahl mitzuhörender Pakete enorm. Statt mehrerer Milliarden Pakete müssten jetzt nur noch 60 Millionen Pakete mitgelesen werden, so das Team um Kenny Paterson. Diese hohe Zahl an Aufrufen können Angreifer erreichen, indem sie Nutzer auf eine bösartige präparierte Webseite locken, die dann eine Vielzahl an Aufrufen generiert.

Doch damit nicht genug: Angeblich kann der Geheimdienst NSA RC4 sogar in Echtzeit knacken.


 

Entschlüsselung in Echtzeit?

RC4 könne von Geheimdiensten wie der NSA in Echtzeit entschlüsselt werden,behauptet der Aktivist und Tor-Entwickler Jacob Appelbaum, der auch im investigativen Spiegel-Team an den Snowden-Enthüllungen mitarbeitet. Es gibt für diese Behauptung zwar keinen Beleg, jedoch passt sie zu Medienberichten über die gezielte Manipulation von Verschlüsselungsverfahren durch Geheimdienste, etwa das Programm Bullrun der NSA.

Die NSA soll bei bekannten Herstellern von Sicherheitslösungen wie RSA Security interveniert haben, um Verschlüsselungsverfahren zu schwächen. Der US-Geheimdienst versuchte demnach, bei verschiedenen Algorithmen genau jene Schwachstelle zu forcieren, die RC4 angreifbar macht: den berechenbaren Zufall. Die Firmen wiesen die Anschuldigungen zurück.

Die Internet Engineering Taskforce reagierte Anfang 2015 auf die von den Sicherheitsforschern demonstrierten Angriffe. Mit dem relativ knappen Request for Comment 7465 regelte das Expertengremium, dass gültige TLS-Verbindungen ab sofort kein RC4 mehr einsetzen dürften. Vielmehr wird Webseitenbetreibern nahelegt, AES-GCM zu verwenden.Test der Sicherheitszertifikate von Google.de mit dem SSL Report von Qualys SSL Labs (Bild: Hauke Gierow)

Der RC-4-NOMORE-Angriff

Auch nach dem Verbot von RC4 in TLS-Verbindungen durch die IETF suchen Sicherheitsforscher weltweit weiter nach Sicherheitslücken in RC4. Durch den im Juli 2015 von Mathy Vanhoef und Frank Piessens vorgestellten Angriff RC NOMORE (Numerous Occurrence Monitoring & Recovery Exploit) ist es nach Angaben der Forscher möglich, mit RC4 verschlüsselte Authentifizierungs-Cookies mit einer Wahrscheinlichkeit von 94 Prozent innerhalb von nur 75 Stunden zu knacken.

In einem Test gelang es unter günstigen Bedingungen angeblich sogar, ein solches Cookie innerhalb von lediglich 52 Stunden zu entschlüsseln. Bislang dauerten vergleichbare Angriffe bis zu 2000 Stunden. Mit dem erbeuteten Cookie können Angreifer die Accounts ihrer Opfer übernehmen und sich in Webdienste wie E-Mail-Konten oder soziale Netzwerke einloggen.

Um den Angriff auszuführen, muss der Nutzer neben der anzugreifenden Seite eine unverschlüsselte Webseite aufrufen. Die Angreifer injizieren dann Javascript-Code in die Datenpakete, der den Rechner des Opfers auffordert, immer wieder die Daten des anzugreifenden Cookies zu übertragen. Die Entschlüsselung des Cookies muss nicht in einer einzigen Session erfolgen, sondern ist auch schrittweise möglich. Um den Angriff erfolgreich durchzuführen, nutzen die Angreifer bereits bekannte Schwachstellen in RC4 aus: den Fluhrer-Mc-Grew-Bias und den Mantin’s ABSAB Bias.

Die Forscher stellen zudem eine weitere Angriffsmethode vor: Mit Hilfe der Technik sei es möglich, die WPA-TKIP-Verschlüsselung von WLAN-Netzwerken innerhalb von nur einer Stunde zu brechen. Nutzer, die über WPA2 mit AES verschlüsseln, sind von dem Angriff nicht betroffen – diese Einstellung ist Standard bei den meisten heute erhältlichen Routern.

Bis zur Abschaffung von RC4 ist es ein weiter Weg

Die Empfehlungen von Sicherheitsforschern sind eindeutig: Auf den Einsatz von RC4 sollte ab sofort, wo immer es möglich sei, verzichtet werden. Doch der Abschied wird sich wohl noch etwa hinziehen. Das Verbot von RC4 wird jedoch nicht von allen Webseitenbetreibern umgesetzt. Einige scheuen den Aufwand der Umstellung, andere fürchten Kompatibilitätsprobleme. So können Anwender, die die Version 39 von Firefox nutzen, mit wenigen Ausnahmen auf einer Whitelist, nicht mehr auf nur mit RC4 verschlüsselte Webseiten zugreifen. Nutzer können die Sicherheit einzelner Server testen, wenn sie sich nicht auf die Webseitenbetreiber verlassen wollen.

Golem.de hat das am Beispiel von Google.de überprüft: Selbst die Server des Suchmaschinenkonzerns verwenden aus Kompatibilitätsgründen nach wie vor eigentlich überholte Standards wie SSL 3 und eben auch RC4 (siehe Screenshot). Der kurze Test zeigt ein bekanntes Problem: Zahlreiche Sicherheitslücken werden nach Bekanntwerden relativ schnell geschlossen. Doch viele Webseitenbetreiber nutzen aus Kompatibilitätsgründen – oder weil sie den Aufwand der Umstellung scheuen – noch alte Protokolle wie SSL in der Version 3 oder TLS 1.0. Die Server bleiben so ungeschützt. Nutzer bemerken dies oft nicht.

Problematisch ist auch, dass manche aktuelle Browser viele ältere Protokollversionen aus Gründen der Kompatibilität weiter mitführen.

Heartbleed zeigt, dass eine schnelle Umstellung möglich ist

Das macht auch die Erfahrung mit der Heartbleed-Sicherheitslücke 2014 deutlich. Sie zeigte, wie sich die Aufmerksamkeit für den Umgang mit Sicherheitslücken in den vergangenen Jahren verbessert hat: Erstmals machten sich die Sicherheitsforscher die Mühe, eine eigene Webseite mit Informationen über die Lücke zu entwickeln, auch der Name und das Logo trugen zu einer großen Medienaufmerksamkeit bei.

In einem Forschungsprojekt untersuchten IT-Experten der Universitäten Michigan, Illinois und anderen, wie schnell Webseitenbetreiber die zur Verfügung stehenden Patches einspielten. Innerhalb von nur 24 Stunden patchten 95 der 100 beliebtesten Webseiten ihre Systeme. Trotzdem waren zwei Monate nach der Attacke immer noch rund 300.000 Server anfällig für die Lücke.

Quelle: golem.de

Facebooktwittergoogle_plus