Hintergründe zur schweren SSL-Sicherheitslücke bei Apple

Der Sicherheitsforscher Stefan Esser spricht im Interview mit Mac & i über die am Freitag bekanntgewordene Verschlüsselungslücke in iOS und OS X und ihre Hintergründe.

Lesezeit: 11 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 160 Beiträge
Von
  • Ben Schwan
Inhaltsverzeichnis

Am Freitag veröffentlichte Apple ein wichtiges Sicherheitsupdate für iOS 6 und 7. Wie sich herausgestellt hat, enthalten sowohl das Mobilbetriebssystem als auch OS X Mavericks eine schwerwiegende Lücke, die Angriffe auf verschlüsselte SSL-Verbindungen im lokalen Netz ermöglichen. OS X Mavericks ist noch ungeschützt, Apple verspricht ein baldiges Sicherheitsupdate.

Hinweis: Apple hat die SSL-Lücke in Mavericks mit OS X 10.9.2 am 25. Februar behoben.

Stefan Esser.

(Bild: SektionEins)

Stefan Esser gehört zu den bekanntesten IT-Security-Experten in Deutschland und ist Geschäftsführer der Kölner Sicherheitsfirma SektionEins. Er hat sich seit Freitag intensiv mit Apples SSL-Problem beschäftigt und einen experimentellen Patch entwickelt, mit dem man OS X Mavericks gegen Apples SSL-Lücke schützen kann, empfiehlt aber, auf Apples eigene Lösung zu warten. Im Mac & i-Interview spricht Esser ausführlich über die aktuelle Problematik und ihre Hintergründe.

Mac & i: Herr Esser, es herrscht derzeit etwas Verwirrung darüber, welche OS-X-Versionen von der noch nicht geschlossenen SSL-Lücke betroffen sind. Wie sich mit der Test-Website gotofail.com überprüfen lässt, scheinen alle Versionen vor Mavericks (OS X 10.9) nicht angreifbar; Mavericks, das erst im Oktober 2013 erschien, dagegen schon. Ist das korrekt?

Stefan Esser: Wenn man in den Quelltext des Security Frameworks schaut, der auf opensource.apple.com liegt, dann sieht man, dass das überflüssige "goto fail;" im Quelltext von 10.8.5 nicht zu finden ist. Daher liegt der Schluss nahe, dass nur Mavericks betroffen ist.

Mac & i: Bei iOS steckt der Bug dagegen in iOS 7 und auch 6, das wesentlich älter ist. iOS 6 erschien erstmals im September 2012. Haben Sie eine Erklärung dafür?

Esser: Apple lässt sich nicht gerne in die internen Karten schauen, daher sind alle Informationen über die Arbeitsweise nur Hörensagen. Aber es sieht wohl so aus, dass die Codebasen von iOS und OS X zu einem Zeitpunkt in der Vergangenheit getrennt und von zwei unterschiedlichen Teams weiterentwickelt worden sind. Das zeigte sich immer darin, dass bestimmte Sicherheitsfeatures zuerst in iOS eingeführt und erst später auf OS X übertragen wurden.

In iOS ist der Fehler behoben, in OS X aber noch nicht.

Das führte aber auch dazu, dass Sicherheitsprobleme in iOS und OS X ungleich gepatcht wurden. Das heißt, dass Probleme zwar in iOS gepatcht waren, aber nur unzureichend in OS X – und andersherum. Nun gibt es das Gerücht, dass Apple zwischen iOS 6 und 7 angefangen hat, die zwei großen Codebäume wieder näher aneinander zu bringen, um solche Probleme in Zukunft zu vermeiden. Dies ist zwar ein Gerücht aus dem letzten Jahr, würde aber die Historie dieser Lücke vollständig erklären.

Mac & i: Können Sie beschreiben, wie sich die Lücke konkret ausnutzen lässt und was ein Angreifer dann tun kann?

Esser: Man muss zunächst wissen, dass sich hinter HTTPS bzw. verschlüsselten Webseiten eine Reihe von Protokollen mit unterschiedlichen möglichen Verschlüsselungs- und Authentifizierungsalgorithmen verstecken. Welche dieser Protokolle und Algorithmen letztendlich für die Kommunikation von Client und Server verwendet werden, handeln diese beim sogenannten Handshake am Anfang der Verbindung aus. Die Verwundbarkeit, über die wir hier sprechen, tritt nur auf für SSL-Verbindungen, die den Diffie-Hellman-Schlüsselaustausch verwenden – und nicht TLS v1.2.

Bei so einem Schlüsselaustausch tauschen Server und Client jeweils eine Nachricht aus, aus der beide zusammen dann den geheimen Schlüssel für die Verschlüsselung berechnen können. Als Schutz gegen sogenannte Man-in-the-middle- Angriffe wird die Nachricht des Servers dabei von ihm digital unterschrieben, damit niemand diese Nachricht des Servers abändern kann. Hierbei kommt dann das SSL-Zertifikat ins Spiel.

Das Sicherheitsproblem bei Apple ist, dass das überflüssige "goto fail;" dafür sorgt, dass diese digitale Signatur überhaupt nicht geprüft wird. Das heißt: Ein potenzieller Angreifer kann sich zwischen Client und Server setzen und das Paket an den Client mit Datenmüll "signieren". Ungepatchte iOS und OS X-Geräte werden es dennoch akzeptieren. Von diesem Moment an kann der Angreifer den verschlüsselten Datenverkehr zwischen Client und Server ausspähen und modifizieren, also zum Beispiel die Kommunikation mit der Webseite ihrer Bank, mit ihrem E-mail-Provider, irgendeinem Onlineshop oder sozialen Netzwerken wie Facebook. Bei iOS und OS X kommen dann noch Dinge wie die eingebaute Twitter-Kommunikation, Software-Updates (die allerdings noch über weitere digitale Signaturen vor Veränderungen geschützt sein sollten) und die Push-Benachrichtigungen hinzu.

Um dies alles tun zu können, muss der Angreifer jedoch in der Lage sein, sich in den Datenverkehr einzuklinken. Dies ist besonders einfach, wenn das Opfer offene WLAN-Hotspots in einem Café, einem Hotel, auf einer Konferenz oder am Flughafen benutzt. Aber auch Angriffe auf Router sind möglich, die die DNS-Konfiguration der Opfer ändern und so alle Abfragen über Server des Angreifers umleiten.