TLS-Sicherheit: Hintergründe zum neuen „Lucky Thirteen“-Angriff

Das Lucky Thirteen-Exploit für das Protokoll Transport Layer Security (TLS) erlaubt es Angreifern, sich zwischen Client und Server zu schalten.

Die neueste Schwachstelle im Protokoll Transport Layer Security (TLS) gibt nach Ansicht der zwei Forscher, die sie entdeckt haben, keinen Grund zur Panik. Allerdings kann man sich durchaus Sorgen über mögliche verbesserte Versionen dieser Angriffsart machen. Die neue Lücke setzt außerdem eine lange Reihe von Problemen mit dem grundlegenden Mechanismus für Client-Server-Sicherheit im Internet fort.

„Ich bin seit Jahren fasziniert von Anwendungen von Kryptografie im echten Leben. So gesehen war TLS eines der interessantesten Ziele für jemanden wie mich“, sagt Kenneth Paterson, Professor und Co-Autor eines vor kurzem veröffentlichten Aufsatzes über den neuen TLS-Angriff. Die Grundlage dafür seien jahrelange Erfahrungen mit anderen Kommunikationsprotokollen gewesen, bei denen das Timing von unterschiedlichen System-Nachrichten Rückschlüsse auf den Inhalt erlauben. Das Paper mit dem Titel „Lucky Thirteen: Breaking the TLS and DTLS Record Protocols“ wurde von Paterson und dem PhD-Studenten Nadhem AlFardan gemeinsam verfasst. Beide arbeiten im Team Information Security an der University of London. 

Bei TLS kann sich ein Angreifer zwischen einen Client und einen Server schalten, erklärt Paterson. Der Übeltäter würde dann Pakete abfangen und sehr subtil modifizieren: Die zum Server gesendeten Pakete bekommen eine ungewöhnliche Form mit einem Header-Feld aus 13 Bytes, von dem auch der Name „Lucky Thirteen“ abgeleitet ist. Bei der Entschlüsselung dieser Pakete auf dem Server gibt es dann Fehler, weil in TLS ein Mechanismus zum Integritätsschutz enthalten ist. „Höflicherweise“ sendet der Server über jeden diesen Fehler eine Nachricht an den Client.

Es folgt der entscheidende Teil, so Paterson: „Der Zeitaufwand für die Ausgabe der Fehlermeldung variiert etwas in Abhängigkeit davon, was genau bei der Entschlüsselung passiert. Wir modifizieren die Pakete, und zwar auf eine Weise, die zu mehr und weniger Zeitaufwand beim Server führt. Aus diesen Unterschieden lässt sich dann der Klartext bestimmen“.

Laut Paterson liegen die Zeit-Differenzen dabei im Bereich von einer halben bis mehreren Mikrosekunden. Ihre genaue Höhe hänge stark von der Hardware des Servers ab. Zudem müssen die Pakete mit den Fehlermeldungen auch das Netzwerk durchqueren, was ebenfalls eine Zeitlang dauere. Es gebe also viele Verzögerungen und Schwankungen aus allen möglichen Quellen wie den Routern im Netzwerk.

Weil trotzdem genau die Zeit gemessen werden muss, ist es für einen Angreifer optimal, wenn er sich im selben Netzwerk-Segment befindet wie der Server. Das ist ein nicht unbedingt typisches, aber durchaus mögliches Szenario, so Paterson. Zum Beispiel könne es sich beim Angreifer ja um den eigenen Internet-Provider handeln, und der könne in Staaten, in Bürger eher als Gegner betrachtet werden, zu solchen unschönen Mitteln greifen.

Allerdings machen die beiden Forscher in ihrem Aufsatz auch klar, dass ein vernünftiger Angreifer die neue Methode wohl nicht als ersten Angriffsweg wählen würde. Denn erstens wird es umso schwieriger, verwertbare Messungen zu bekommen, je weiter entfernt hinsichtlich der Netzwerk-Topologie der Angreifer vom Server ist. Selbst in großer Nähe braucht es für jedes entschlüsselte Byte zudem mehrere Messungen der Zeitdifferenz.

Für viele Messungen müssen auch viele TLS-Sitzungen initiiert werden. Dadurch entsteht viel „Lärm“ im Netzwerk, der bei Überwachung klare Hinweise auf einen möglichen Angriff liefert. Die meisten kommerziellen Server machen ohnehin von sich aus nicht mit, wenn sie immer von derselben IP-Adresse aus aufgefordert werden, ungewöhnlich viele TLS-Sitzungen zu starten.

Der „Lucky Thirteen“-Angriff in seiner jetzt vorgestellten Form dürfte also in der Realität nicht schnell zu einem großen Problem werden, erklärt das Team. Allerdings ist noch nicht bekannt, welche Verbesserungen sich noch daran vornehmen lassen, die vielleicht zu einem effektiveren Einsatz führen könnten.

Wie könnten solche Verbesserungen aussehen? Erstens könnte es möglich sein, die Zahl der für das Knacken der Verschlüsselung notwendigen Sitzungen zu verringern. Paterson hat sogar schon Ideen dazu: „Man müsste einen Teil des Textes vorab bestimmen können, indem man zum Beispiel davon ausgeht, dass es sich bei den ersten abgefangenen Bytes um den Header eines Cookies handelt. Wenn man das Format von Standard-Cookies kennt, kann man so die Zahl der nötigen Messungen von 2 hoch 23 auf 2 hoch 19 verringern. Es gibt noch einen weiteren Trick: Wenn der Angreifer auch die letzten zwei Bytes im Block kennt, verringert sich die Zahl der Messungen weiter auf 2 hoch 13“.

Auch das sorgt noch für viel Netzwerk-Lärm, führt aber zu einem einigermaßen schnellen Angriff. Im vorgestellten Test-Szenario dauerte es 15 Minuten, ein Byte zu Klartext zu entschlüsseln.

Paterson selbst würde das immer noch nicht als erstes Mittel für einen Angriff sehen (auf mehrfaches Nachfragen entschied er sich hier für eine Phishing-Mail). Doch die neue Lücke ist nur die jüngste in einer langen Reihe von Problemen im Bereich der Sicherheit von TLS und seinem Vorgänger Secure Sockets Layer (SSL).

Ein paar weitere aktuelle Beispiele: Schwächen im Umgang mit SSL führen dazu, dass sich die Arbeitsspeicher von Android- und iOS-Geräten auf Entfernung löschen lassen: Ein JavaScript-Angriffswerkzeug namens BEAST ist in der Lage, fremde SSL-Sitzungen zu kontrollieren. Schließlich haben immer neue Probleme mit Zertifikaten, die als Grundlage für das Vertrauen in das SSL-Protokoll dienen sollen, den Ruf des wohl am weitesten verbreiteten Sicherheitsmechanismus im Internet nachhaltig beschädigt. 

Eine unschön lange Liste mit Angriffen auf TLS und SSL finden Sie hier.

Erfahren Sie mehr über Bedrohungen

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close