HTTPSVerschlüsselte Datenübertragung ist nicht sicher

Eine schon bekannte Sicherheitslücke in der Datenübertragung per HTTPS konnte erstmals ausgenutzt werden. Von dem Hack ist nicht nur das Onlinebanking betroffen. von 

Die verschlüsselte Datenübertragung bei PayPal kann nach Angaben der Sicherheitsexperten Thai Duong und Juliano Rizzo ausgelesen werden.

Die verschlüsselte Datenübertragung bei PayPal kann nach Angaben der Sicherheitsexperten Thai Duong und Juliano Rizzo ausgelesen werden.  |  © Karen Bleier/AFP/Getty Images

Ein einziger Buchstabe wiegt die Nutzer von Onlinebanking-Seiten in Sicherheit: das "s" im Adresspräfix https. Das steht für Hypertext Transfer Protocol Secure – also sicheres Übertragungsprotokoll. Internetadressen, die mit https beginnen, verschlüsseln die Kommunikation zwischen Website und Nutzer. Ein Angreifer, der sich in diese Kommunikation beispielsweise mit einem sogenannten "Man in the middle-Angriff" einklinkt, sieht keinen Klartext. Zwei Sicherheitsexperten behaupten nun, dass genau das doch möglich ist.

Den beiden ist es nach eigenen Angaben gelungen, die lange als abhörsicher geltende Technologie zu entschlüsseln. Ein "Mann in der Mitte" könnte mit ihrer Methode die vermeintlich sicheren Sitzungen beim Onlinebanking, bei Onlinehändlern, aber auch beim Instant Messaging kapern und für seine Zwecke nutzen.

Anzeige

Komplizierter Angriff

Der Vietnamese Thai Duong und der Argentinier Juliano Rizzo haben einen sogenannten Proof-of-concept-Code geschrieben, der die Verschlüsselung rückgängig macht. Die beiden anerkannten Experten nennen ihr in der Programmiersprache Javascript geschriebenes Programm BEAST , eine Abkürzung für Browser Exploit Against SSL/TLS .

SSL steht dabei für Secure Sockets Layer . Es ist die bei Https-Verbindungen genutzte Verschlüsselung, um transportierte Daten unlesbar zu machen. Sie wurde bereits 1994 von Netscape eingeführt. SSL wird immer noch verwendet, doch ist heute das Nachfolge- Protokoll TLS stärker verbreitet, wobei die Abkürzung für Transport Layer Security steht. Alle gängigen Browser und viele Dienste-Anbieter nutzen diese Protokolle.

Der Angriff selbst ist kompliziert und weit davon entfernt, ein Massenphänomen zu werden: Zunächst muss der Angreifer in die Position des "Man in the middle" gelangen, sich also unerkannt im selben Netzwerk befinden wie sein Opfer und dessen Kommunikation mit der Zielseite mitschneiden. In offenen WLAN-Netzen ist das vergleichsweise leicht, Hacker finden aber auch andere Wege.

Besucht das Opfer dann eine Seite wie PayPal, warten die Angreifer ab, bis sich der Nutzer eingeloggt hat. Die Website sendet in diesem Fall einen verschlüsselten Session Cookie . Das ist eine Art zeitlich begrenzter Ausweis, mit dem sich der Nutzer bei der Seite identifiziert, solange er auf ihr surft. Dieser Cookie ist verschlüsselt. Duong und Rizzo ist es gelungen, ihn zu entschlüsseln und anschließend selbst zu nutzen – sich also für den eigentlichen Inhaber des Accounts auszugeben.

Leserkommentare
  1. Bei dem gefundenen Angriff handelt es sich um einen Angriff, welcher eine Schwachstelle in der Implementierung des SSL/TLS 1.0 Protokolls ausnutzt. Das bedeutet, dass nicht etwa das Protokoll an sich unsicher wäre, sondern die Umsetzung fehlerbehaftet ist. Daher wird es wohl so sein, dass die Broweranbieter schnell Patches gegen den Angriff anbieten werden.

    Natürlich ist das egal, da 99% der Internetuser nie ihren Browser oder andere Software aktualisieren :D

    5 Leserempfehlungen
    Reaktionen auf diesen Kommentar anzeigen

    Die über das Protokoll verschlüsselten Daten (hier das Sessioncookie) wurden entschlüsselt.

    Dies ist aber nur möglich, wenn der Angreifer den Browser kontrolliert und über den verschlüsselten Kanal beliebige Werte schicken kann. Dann kann die Verschlüsselung geknackt werden, weil der Angreifer die originalen Werte und die dazugehörigen verschlüsselten Werte kennt. Wenn er dann das Sessioncookie abfängt und entschlüsselt, kann er die Accountdaten ermitteln. Allerdings werden nicht die verschlüsselten Daten selbst geändert, so daß man nicht von einem "man-in-the-middle"-Angriff sprechen kann. Sowas nennt man allgemeinhin sniffing.

    Die Frage, die noch unbeantwortet bleibt, ist, wie die Kontrolle über den Browser erlangt werden kann, so daß von diesem speziell manipulierte Pakete gesendet werden.

    *gaehn* an die Zeit. Was nicht alles moeglich ist. Wenn ich die Schluesselstaerke ueber 2048 bit ansetze koennen die machen was die wollen. Die Sitzung ist eher abgelaufen als die den Schluessel geknackt haben.

  2. Sollte man sowieso unterbinden. Das ist die Ursache derart vieler Sicherheitslöcher, dass man es gar nicht erst zulassen sollte. Firefox ist in dieser Hinscht ein sehr guter Browser, weil sich mit einigen Add Ons Cross-Site-Scripting einigermassen effektiv abstellen lässt.

    Allerdings sieht die Online-Präsenz der Zeit recht seltsam aus, wenn man auch dort konsequent alle Scripte fremder Sites nicht zulässt ;) Aber mit etwas Gebastel an den Filtern bekommt man auch das in den Griff.

  3. "Cross-Site-Scripting sollte man sowieso unterbinden ... Firefox ist in dieser Hinscht ein sehr guter Browser"

    Cross-Site-Scripting hat - entgegen der sicherlich irritierenden Namensgebung - nichts mit dem Browser zu tun. Es handelt sich bei XSS unter anderem um das Reflektieren von Code, der an den Server geschickt wurde, hier ist also die WEBSITE die Schuldige. (Siehe Wikipedia)

    Was Sie meinen, ist das Ausführen von Code fremder Domänen. Das wird bereits seit Jahren von allen modernen Browsern (z. B. FF3 und IE6) serienmäßig gesperrt.

    Reaktionen auf diesen Kommentar anzeigen

    Firefox bietet aber über Add Ons die Möglichkeit, Cross-Site-Scriüting sehr effektiv zu unterbinden.

    Mir ist klar, dass die Website der Schudige ist. Mit NoScript lät sich aber unter Firefox recht gut steuern, welche Seiten sowas dürfen und welche nicht. Darum ging es mir.

    Sorry, falls mißverständlich formuliert.

  4. Ich möchte der Vollständigkeit halber noch anfügen, dass der Internet Explorer seit IE8 TLS 1.1 und 1.2 unterstützt. Der aktuelle Firefox 6 jedoch nur TLS 1.0.

    Reaktionen auf diesen Kommentar anzeigen

    solange nur die ältere Version des Protokolls serverseitig Unterstützung findet.

  5. Firefox bietet aber über Add Ons die Möglichkeit, Cross-Site-Scriüting sehr effektiv zu unterbinden.

    Mir ist klar, dass die Website der Schudige ist. Mit NoScript lät sich aber unter Firefox recht gut steuern, welche Seiten sowas dürfen und welche nicht. Darum ging es mir.

    Sorry, falls mißverständlich formuliert.

    Antwort auf "XSS - Klarstellung"
  6. Die über das Protokoll verschlüsselten Daten (hier das Sessioncookie) wurden entschlüsselt.

    Dies ist aber nur möglich, wenn der Angreifer den Browser kontrolliert und über den verschlüsselten Kanal beliebige Werte schicken kann. Dann kann die Verschlüsselung geknackt werden, weil der Angreifer die originalen Werte und die dazugehörigen verschlüsselten Werte kennt. Wenn er dann das Sessioncookie abfängt und entschlüsselt, kann er die Accountdaten ermitteln. Allerdings werden nicht die verschlüsselten Daten selbst geändert, so daß man nicht von einem "man-in-the-middle"-Angriff sprechen kann. Sowas nennt man allgemeinhin sniffing.

    Die Frage, die noch unbeantwortet bleibt, ist, wie die Kontrolle über den Browser erlangt werden kann, so daß von diesem speziell manipulierte Pakete gesendet werden.

    Reaktionen auf diesen Kommentar anzeigen

    Wenn dir der Inhalt deiner cookies so wenig schutzbedürftig erscheint, dann schick mir doch mal jene, welche du beim Einloggen bei paypal&co empfängst. Ich hätte da schon so einige Ideen...

  7. Also welche Verschluesselung wurde nun geknackt - die des Session Cookie wenn ich den Artikel richtig verstehe.

    Sofern ich mich nicht irre wird https mit RSA verschluesselt - das ist eine Einwegverschluesselung (Public Key Encription).
    Sofern ich mich nicht irre kann RSA bisher nicht "geknackt" werden, solange die Zahl gross genug ist.

    Da hier von einigen Minuten rechnen geschrieben wird kann es sich nicht um RSA beim Cookie handeln... - oder es muesste im Bereich von 256Bit oder weniger sein.
    Wenn das Cookie aber mit einer private Key Enctryption verschluesselt wurde dann ist es doch eigentlich klar dass das nicht sicher ist...

    Waere es moeglich solche Details bitte ausfuehrlich im Artikel zu nennen - denn diese Fehlen mir doch sehr.
    Verschluesselung ist nicht gleich Verschluesselung.

    (Und ich hoffe auf nicht zu viele Tippfehler...)

    Reaktionen auf diesen Kommentar anzeigen

    Sie hauen in Ihrem Kommentar einige Dinge durcheinander:

    1. HTTPS unterstützt diverse Kryptalgorithmen, die idR über die OpenSSL-Bibliotheken nachgeladen werden. RSA wird u.a. zur Authentication und für den Key Exchange eingesetzt.
    Siehe http://httpd.apache.org/d...

    RSA ist ein asymmetrisches Kryptoverfahren, das hat nichts mit Einwegverschlüsselung zu tun. Einweg"verschlüsselungen" (ugs. Hash oder auch Prüfsummen) sind eine einfache mathematische Funktion, deren Inverses komplexitätstheoretisch schwer zu berechnen ist. (Groß-O-Notation als Leseempfehlung).

    RSA gilt als mathematisch sicher, wenn die Faktorisierun hinreichend groß ist. In der Praxis werden solche Systeme aber über Seitenkanäle angegriffen (Keylogger z.B.)

    Die Aussage, dass Private-Key-Verschlüsselung unsicher ist, ist so auch nicht zutreffend und erst recht nicht zu treffen, das gesamte System muss analysiert werden.

    Der Session Cookie wird normal als Datenpaket verschickt, wie er verschlüsselt ist, hängt vom ausgewählten Algorithmus (siehe 1. Punkt) ab.

    Mein Tipp: besorg dir Applied Cryptography von Schneier, das ist *DIE* Kryptobibel und sollte dir als Mathestudent keine Probleme bereiten. Die Mathematik der Kryptographie ist eigentlich recht simpel.

    Danke an all die Geeks hier, von denen ich gar nicht wusste, dass sie die ZEIT lesen, für die aufschlussreiche Diskussion, die sich ja mal so was von positiv von den verschwörungstheoretischen Kommentatoren beispielsweise unter Libyen-Artikeln oder den eine-Seite-beschimpft-die-andere-und-keiner-hört-zu-Diskussionen unter anderen Themen abhebt.
    Ich denke trotzdem nicht, dass man wie von Ihnen gewünscht zu viele technische Details in den Artikel packen sollte, da der durchschnittliche ZEIT-Leser es sonst ganz schnell mit der Angst zu tun bekommt. Wenn zur Erklärung eines Begriffes schon wieder zwei neue erklärungsbedürftige Begriffe nötig sind, ist der Rahmen eines einfachen Artikels eben schnell gesprengt, zumindest der eines Online-Artikels und die sind ja scheinbar in der Regel deutlich kürzer als die der Printausgabe. Letztere erscheint schließlich auch nur einmal in der Woche und soll ja wohl immer noch einen gewissen Mehrwert liefern. Die ZEIT-Online-Leser mögen zwar technikaffiner sein, aber die Zusammenhänge zwischen RSA und https finden Sie wahrscheinlich nicht einmal in den heute aktuell erschienenen Online-Artikel der einschlägigen Technikmagazine bzw. Technikportale.

    • dth
    • 20. September 2011 22:38 Uhr

    Wenn ich die bisher recht spärlich vorhandenen Informationen richtig interpretiere, wurde ein Designfehler im TLS-Protokoll ausgenutzt. Es wurde hingegen kein cryptographisches Verfahren direkt angegriffen.
    Bei TSL werden verschiedene Verfahren angewendet, assymetrische Verfahren wie RSA werden verwendet, um die Beteiligten (durch Zertifikate) zu authentifizieren und einen nur für die dauer der Kommunikation gültigen symetrischen Schlüssel auszuhandeln. Das passiert deshalb, weil symetrische Verfahren viel schneller sind.
    Bei der Anwednung mancher dieser Verschlüsselungsverfahren gibt es in TLS wohl einen Fehler, der "known plain text"-Angriffe ermöglicht. Wenn man also bestimmte Klartexte senden kann, kann man den Schlüssel herausfinden.

    Was wohl nun gelungen ist, ist einen Weg zu finden, wie man Browsern ein Javascript-Program unterschieben kann (z.B. durch manipulation unverschlüsselter Datenströme), dass dann dafür sorgt, dass Klartexte erzeugt versendet werden, die das Knacken der Verschlüsselung erlauben. Bei korrekter Verwendung der Verschlüsselungsverfahren wäre das nicht möglich.
    Kennt man den Schlüssel, kann man die gesammte Kommunikation entschlüsseln, dabei auch das Session-Cookie. Das Session-Cookie ist deshalb relevant, weil es einen Authentifizierungscode enthält. Kennt man diesen, kann man die Sitzung übernehmen.
    Vermutlich kann man alles, nicht nur dieses Cookie entschlüsseln. Aber das ist eben der interessante Teil der Information.

  8. solange nur die ältere Version des Protokolls serverseitig Unterstützung findet.

    Antwort auf "TLS-Protokolle"

Bitte melden Sie sich an, um zu kommentieren

  • Artikel Auf einer Seite lesen
  • Quelle ZEIT ONLINE
  • Schlagworte Browser | Internetzensur | Kommunikation | Netscape | Onlinebanking | PayPal
Service