zurück zum Artikel

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.

Am Freitag veröffentlichte Apple ein wichtiges Sicherheitsupdate [1] für iOS 6 und 7. Wie sich herausgestellt hat, enthalten sowohl das Mobilbetriebssystem als auch OS X Mavericks [2] 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 [3].

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

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 [5] 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 [6] ü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 [7] des Security Frameworks schaut, der auf opensource.apple.com [8] 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.

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.

Exploit bald "in the wild"

Mac & i: Sind Beispiele bekannt, dass die Lücke ausgenutzt wurde?

Esser: Solche Beispiele sind momentan nicht öffentlich bekannt, allerdings arbeiten seit Freitag diverse Personen daran, diesen Angriff in ihre Tools einzubauen.

Mac & i: Welche Personen sind das?

Esser: Ich weiß von diversen Sicherheitsforschern, die sich über das Wochenende Tools hierfür gebaut haben. Man kann aber davon ausgehen, dass auch die Entwickler von Überwachungssoftware, die bereits andere SSL-Man-in-the-Middle-Tools entwickelt haben (und verkaufen), diesen Angriff aufnehmen, da er nicht besonders schwer einzubauen sein sollte.

Mac & i: Es gibt Spekulationen, wonach der Bug vom US-Geheimdienst NSA eingesetzt wurde. Halten Sie das für plausibel?

Esser: Es gibt viele Spekulationen, was die NSA oder andere Geheimdienste machen, aber es gibt letztendlich keinen öffentlichen Informationen, die belegen, ob diese Lücke bestimmten Leuten bekannt war oder eben nicht.

Grundsätzlich halte ich es aber für plausibel, dass ein Geheimdienst, der mit einem Milliardenbudget nach Sicherheitslücken sucht und Angriffswerkzeuge baut, von Sicherheitslücken vor der Allgemeinheit weiß und diese auch aktiv ausnutzt, wenn sie brauchbar sind. Und diese Apple-Sicherheitslücke ist es.

Mac & i: Sie haben selbst einen Patch für OS X geschrieben, während Apple noch an diesem arbeitet. Warum braucht Apple so lange?

Esser: Dieser Fehler kann auf Seiten von Apple behoben werden, indem eine Zeile Code entfernt und das Programm neu kompiliert wird. Dies hört sich erst einmal nicht nach viel Arbeit an und ist viel weniger Aufwand als die Entwicklung des Binärpatches.

Aber eine Firma wie Apple kann es sich nicht leisten, die Zeile zu entfernen, neu zu kompilieren und dann ein Update zu pushen. Sie müssen sowohl den einzeiligen Patch als auch die komplette Auslieferungmethode bei jedem Release auf verschiedener Hardware testen, um sicherzustellen, dass sie keine Produktivsysteme kaputt machen. Das hört sich zwar für einen Außenstehenden für eine Zeile Code überzogen an, aber letztendlich war es auch nur eine Zeile Code, die zu diesem Sicherheitsdesaster geführt hat.

Interessant ist hier nur, warum Apple nicht iOS und OS X gleichzeitig gepatcht hat. Wäre es meine Entscheidung gewesen, dann hätte ich nur gleichzeitig gepatcht, da es mittlerweile ein Sport ist, binäre Sicherheitspatches zu analysieren und die Verwundbarkeiten daraus zu extrahieren. Und dabei rede ich nur von denen, die das wirklich als Sport betrachten und nicht denen, die dafür bezahlt werden, weil Exploits ihr Geschäft sind.

Angst vor der NSA

Mac & i: Es scheint sich um einen eher trivialen Fehler zu handeln – der Entwickler wiederholte ja wie erwähnt eine goto-Anweisung. Wie ungewöhnlich sind solche Bugs?

Esser: Dieser Fehler sieht sehr merkwürdig aus, wenn man den offenen Quelltext von OS X 10.8.5 und 10.9 vergleicht, da an dieser Stelle wirklich nur eine Zeile verdoppelt wurde. Normalerweise würde so ein Fehler bei normaler Entwicklung nicht passieren, da das Einfügen dieser einen Zeile keinen Sinn macht. Man muss hier jedoch beachten, dass man nicht sehen kann, welche Revisionen intern zwischen diesen beiden Releases existieren.

Es könnte sein, dass ein Programmierer ein Stück Code eingefügt hat und beim Herausnehmen später die einzelne Zeile vergessen wurde. Es könnte aber auch sein, dass Apple tatsächlich versucht, die unterschiedlichen Codebäume wieder zusammenzuführen und diese Verdoppelung durch ein automatisches "Mergen" der Codebäume entstanden ist. Wir Außenstehende werden das jedoch nie erfahren.

Mac & i: Es gibt auch Verschwörungstheorien, das dahinter die erwähnte NSA stecken könnte.

Esser: Nachdem die Snowden-Leaks bestätigt haben, dass die NSA ein Budget dafür hat, gezielt Hintertüren in Produkte einzubauen, liegen solche Verschwörungstheorien natürlich nahe. Aber die meisten Leute vergessen, dass die NSA nicht der einzige Geheimdienst sind. Und gerade wenn es wie hier um das Einfügen eine einzigen Codezeile in den SSL-Code geht, gibt es sicherlich viele Möglichkeiten, dies zu tun.

Genauso könnte das verseuchte Notebook eines Apple Mitarbeiters schuld sein, welches von der XYZ-Regierung oder einer anderen Gruppierung gehackt wurde. Oder aber hier ist wirklich nur ein Auto-Merge-Tool schuld an der Sache. Wir werden das nie erfahren, außer Apple gibt die Ergebnisse der internen Untersuchung preis, die sie sicherlich gestartet haben.

Mac & i: Der Code für das entsprechende Framework liegt quelloffen vor. Hätte man ihn so nicht vergleichsweise leicht entdecken können?

Esser: Ich habe gerade nochmals nachgeschaut. Der Quelltext von OS X Mavericks wurde am 24. Oktober 2013 veröffentlicht. Das heißt: Vis heute sind gerade einmal vier Monate vergangen. Der CVE-Eintrag für die SSL-Verwundbarkeit wurde laut Berichten schon am 8. Januar von Apple reserviert. Also scheint Apple knapp 2,5 Monate nach der Veröffentlichung der Quellen von der Verwundbarkeit erfahren zu haben. Sie haben diesmal niemandem für diese Lücke gedankt. Das kann heißen, dass derjenige entweder nicht genannt werden möchte, oder aber dass die Lücke intern gefunden wurde. Bisher gab es glaube ich noch keine Aussage dazu.

Es dauert in der Regel eine Zeit lang, bis Lücken in quelloffenen Produkten gefunden werden, da die Menge an quelloffenem Code ziemlich groß ist und die Zahl der qualifizierten Auditoren, die kostenlos in ihrer Freizeit prüfen, klein ist. Und diese Zahl wird immer kleiner, je mehr große Firmen Bug-Bounties vergeben, da die Hobby-Sicherheitsforscher dann eher dort auditieren, wo sie vielleicht auch noch eine kleine Geldprämie kriegen können. Daher sind eine Lebenszeit von vier Monaten für eine Sicherheitslücke in einem quelloffenden Produkt nicht wirklich viel.

Mac & i: Wie bewerten Sie Apples Reaktionsgeschwindigkeit?

Esser: Neutral formuliert kann man sagen, dass Apple unter Sicherheitsforschern nicht als Musterbeispiel für Reaktionsgeschwindigkeit gilt. (bsc [9])

URL dieses Artikels:
https://www.heise.de/-2121951

Links in diesem Artikel:
[1] https://www.heise.de/news/Sicherheitsupdate-fuer-iOS-6-und-7-2121441.html
[2] https://www.heise.de/news/SSL-Bug-in-Mac-OS-X-Apple-verspricht-Update-2121738.html
[3] https://www.heise.de/news/SSL-Bug-in-Mac-OS-X-Apple-verspricht-Update-2121738.html
[4] https://www.heise.de/news/goto-fail-Mac-OS-X-10-9-2-beseitigt-SSL-Schwachstelle-2122971.html
[5] https://www.sektioneins.de/blog/14-02-22-Apple-SSL-BUG.html
[6] https://gotofail.com/
[7] http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c
[8] http://www.opensource.apple.com/
[9] mailto:bsc@heise.de

Copyright © 2014 Heise Medien