iOS Sicherheitslücke – Malware-Infizierung über Webseiten
Ende August veröffentlichte das Project Zero Team von Google eine detaillierte Beitragsserie über eine gefundene iOS Sicherheitslücke, welche heftige mediale Reaktionen auslöste.
Das Betriebssystem iOS, welches unter anderem auf den iPhones von Apple zum Einsatz kommt, wies gleich mehrere Sicherheitslücken auf. Einzeln betrachtet mögen sie relativ trivial in der Wirkung aussehen, jedoch ergeben sie kombiniert einen ernstzunehmenden Angriff. Dabei bilden eine Vielzahl von Exploits mit speziell entwickelter Schadsoftware eine Art „Hacking-Framework“, um so unmittelbar sensible Informationen, wie beispielsweise verschlüsselte Chatnachrichten, Bilder oder GPS-Daten zu entwenden. Der Schadcode bleibt bis zu einem Neustart des Geräts erhalten und ermöglicht es den Angreifern frei nach Belieben Informationen von einem infizierten Gerät abzufragen. Interessant dabei: ein einfacher Besuch einer komprimitierten Website reicht aus, um der darauf lauernden Schadsoftware nichtpersistenten Vollzugriff auf das iPhone des Besuchers zu ermöglichen.
Gefunden hatte das Project Zero Team diese Exploits scheinbar rein durch Zufall. Bei der Analyse gehackter Webseiten ergab sich, dass diese für sogenannte „Watering-Hole Attacks“ (der gezielte Angriff auf eine bestimmte Personengruppe) genutzt wurden und dabei mehrere 0-day Exploits für iPhones zum Einsatz kamen.
Aufgrund dieses Ausmaßes setzte das Team von Google die Frist zur Behebung der zugrundeliegenden Sicherheitslücken auf lediglich sieben, statt der üblichen 90 Tage. Apple reagierte umgehend und lieferte nach wenigen Tagen die erforderlichen Hotfixes. Verwunderlich jedoch erscheint das offizielle Statement von Apple, in welchem behauptet wird, dass es sich hierbei gar nicht um einen massenfähigen Hack handeln würde, mit der Begründung, dass die von Google gefundenen Websites nur eine bestimmte Zielgruppe hätten. Über die tatsächliche Anwendung, die Intention und die Herkunft dieser Hacks lässt sich nur spekulieren. Allerdings steht fest, dass die von Google gelieferten, technischen Analysen klar belegen, dass es sich hierbei um eine Langzeitoperation mit beachtlichen Ressourcen gehandelt haben muss und sehr wohl nahezu jeder Nutzer mit einem iPhone der Betriebssysteme iOS 10.0 bis iOS 12.1 potentiell zum Opfer werden konnte und das lediglich durch das Besuchen einer infizierten Internetseite.
Angriffsverlauf
Auch wenn die Sicherheitslücken sowohl von der Hardware selbst als auch der iOS-Version abhängen, ist die Grundidee immer dieselbe: Zunächst wird eine von mehreren Sicherheitslücken im Webbrowser Safari ausgenutzt, um den ersten Schritt auf das Gerät zu machen. Anschließend werden Informationen, wie die genau verwendete iOS Version und die verbaute Hardware, gesammelt. Anhand dieser Informationen wird die gewünschte Exploit-Chain (die Verkettung einzelner, sich ergänzenden Sicherheitslücken) ermittelt, um umfangreiche Berechtigungen auf dem angegriffenen Gerät zu erhalten. Zum Schluss wird Schadcode auf dem Gerät installiert, welcher nach erfolgreichem Start Daten entwendet und jederzeit über den Server der Angreifer steuerbar ist. Insgesamt fanden die Sicherheitsforscher 14 unterschiedliche Schwachstellen, sieben Safari-Exploits, fünf Kernel-Exploits und zwei Sandbox-Escapes.
Phase Eins – Einfallstor Safari
Der erste Schritt scheint zugleich der Wichtigste. Erst durch die Sicherheitslücken des Webbrowsers Safari war es den Angreifern überhaupt möglich auf das Gerät zu gelangen. Zusätzlich jedoch ermöglichten diese Lücken auch das teilweise Umgehen des Sandboxings. Auf iOS werden jegliche Anwendungen in einer sogenannten „Sandbox“ (isoliert vom Rest) betrieben. Weitere Informationen über das Sicherheitskonzept von iOS finden sich im iOS Security Guide von Apple.
Der Angriff richtete sich auf die von Safari verwendete JavaScript Engine WebKit. Obgleich es sieben verschiedene Angriffsmethoden gab, wurde für jede der Rendering-Prozess „Web Content“ attackiert, mit dem Ziel Lese- und Schreibberechtigung im Speicher zu erhalten. Sobald dieses Ziel erreicht wurde, injizierten die Angreifer ihren eigenen Shellcode, welcher zur Berechtigungseskalation führt.
Besonders zu beachten ist, dass laut den Sicherheitsforschern von Google an dieser Stelle nicht ersichtlich ist, ob es sich bei diesen Angriffen tatsächlich um 0-day-Lücken handelt, oder ob sich darunter auch einige 1-day-Lücken befinden. Während eine 0-day vom Angreifer selbst ermittelt wurde und es dafür noch keinen Patch gibt, sind 1-day Lücken bereits bekannt, aber noch nicht auf den Livesystemen behoben.
Es wird vermutet, dass unter den sieben genutzten Lücken auch einige 1-days dabei sind. Doch wie kann das sein?
Sobald eine Sicherheitslücke bekannt wurde, machten sich Entwickler von WebKit an die Arbeit und versuchten die gemeldete Lücke zu verifizieren. Dies geschah in Form von Proof-of-Concepts oder konstruierten Test-Cases. Nach einer Verifizierung wurde die Lücke in der aktuell zu entwickelnden Version meist geschlossen. Problematisch hierbei ist jedoch, dass die Test-Cases und PoCs in der Versionskontrolle gelassen wurden. Da nach einer einzigen Änderung im Code jedoch nicht unmittelbar eine neue Version an alle Nutzer der Engine vergeben wird, landete dieser Code zunächst im öffentlichen Git-Repository. Dies ermöglichte es den Angreifern einfach die genutzten Test-Cases und PoCs für ihren eigenen Gebrauch anzupassen und zu nutzen, denn zwischen initialem Gitpush und der tatsächlichen Veröffentlichung der Version vergingen oftmals mehrere Monate. So konnte man beispielsweise im Commit 4a23c92e6883 (11. März 2017) von WebKit die Behebung einer gemeldeten Lücke (CVE-2017-2505) sehen, welche alledings erst mit dem iOS Update 10.3.2 am 15. Mai 2017 an die Nutzer verteilt wurde.
Auf diese Weise konnten also alle Menschen mit zwielichtigen Motiven diese, von den Entwicklern selbst zur Verfügung gestellte, Sicherheitslücke über zwei Monate für ihr eigenes Unwesen nutzen. Dieses Problem trat ebenfalls bei Googles Chromium auf, bei welchen mit dem Commit 52a9e67a477b ein PoC mitgeliefert wurde.
Nachdem die Angreifer nun in der Lage waren bestimmte Speicherbereiche zu lesen und zu beschreiben, mussten sie als nächstes ihre eigene Berechtigung erhöhen.
Im Jahr 2016 stellte Apple eine neue Methodik vor, um das Beschreiben bestimmter Bereiche zu erschweren (RWK JIT Region). Dabei wird dieser zu schützende Bereich „versteckt“ gemappt und zum Beschreiben verwendet, statt des „sichtbaren“ Mappings. Hierfür wird allerdings eine Kopiermethode benötigt (jit_memcpy). Genau diese Methode wurde zum Ziel der Angreifer und dazu genutzt, den eigenen Shellcode auszuführen und mit diesem die eigenen Berechtigungen hochzustufen.
Phase Zwei – uneingeschränkter Vollzugriff
Da sich die Angreifer nun auf dem Gerät befinden, aber auf diesem noch nicht viel erreichen können, müssen diese ihre Berechtigung weiter erhöhen und das am Besten so, dass sie den kompletten Systemzugriff erlangen.
Je nach iOS Version wurde hierfür eine von fünf unterschiedlichen und äußerst komplexen Exploit-Chains verwendet. Meist wurde hierfür eine Schwachstelle in einem Grafiktreiber (com.Apple.AGX) des Gerätes ausgenutzt sowie Techniken wie Heap-Grooming (spezieller Angriff auf kalloc) oder das Ausnutzen ungewollter Nebeneffekte einzelner Methoden aus dem Entwicklerkit.
Nachdem die Angreifer nun priviligierte Berechtigung auf dem Gerät besitzen, müssen noch einige von Apples Sicherheitsvorkehrungen deaktiviert werden, um später bei der Ausführung des eigenen Schadcodes keine Schwierigkeiten zu bekommen.
Zunächst wurde die Codesignatur des Schadcodes in den Trust Cache des Kernels geschrieben und verschiedene entitlements dem Schadcode zugewiesen. Unter anderem keychain-access-groups, erlaubt den Zugriff auf alle gespeicherten Secrets in der Keychain des Systems, com.apple.location, ermöglicht das Nutzen der GPS Funktion, ohne die explizite Erlaubnis des Anwenders, sofern GPS aktiviert ist und com.apple.coretelephony.Identity.get, erlaubt den Zugriff auf die Mobilnummer des Geräts. Somit nervt der lästige Nutzer auch nicht beim Hacken des Gerätes, da er keinerlei Bestätigungsanfragen mehr bekommt und keine Chance mehr hat den Angriff zu bemerken.
Phase Drei – der Schadcode
Nachdem der Schadcode endlich mit der gewünschten Berechtigung systemweit und ohne Sandbox auf dem iPhone installiert und ausgeführt wurde, haben die Angreifer nun uneingeschränkten Zugriff auf das System. Doch was genau macht dieser Schadcode und was kann er?
Der Schadcode kommuniziert mit einem sogenannten Command & Control Server, dessen IP-Adresse fest im Code zu finden ist. Zunächst startet das Tool einen initialen Bulk-Upload. Hierbei werden generische Informationen, wie der Standort, eingespeicherte Kontakte, installierte Apps und die in iOS genutzen Container von beliebten Apps wie WhatsApp, Gmail, Telegram oder iMessage ausgelesen und an den C&C Server versendet.
[self uploadDevice]; [self requestLocation]; [self requestContacts]; [self requestCallHistory]; [self requestMessage]; [self requestNotes]; [self requestApps]; [self requestKeychain]; [self requestRecordings]; [self requestSmsAttachments]; [self requestSystemMail];
Für genaue Details dieser Container verweise ich erneut auf das iOS Security Guide von Apple. Zusammengefasst beinhalten diese jedoch zu Usability-Zwecken unverschlüsselte Inhalte, meist in Form von Datenbanken der jeweiligen App. Damit wird also auch die eingesetze End-to-End Verschlüsselung, welche bei diesen populären Messengern zum Einsatz kommt, ausgehebelt.
Ganz besonders kritisch ist die Art der Übermittlung. Der Schadcode steuert einen Endpoint auf dem Zielserver mittels unverschlüsseltem HTTP Request an. Das bedeutet also, dass jegliche Informationen, inklusive aller möglichen Passwörter für Netzwerke, Inhalte von vertraulichen Nachrichten oder auch Single-Sign-On Tokens, wie z.B. von Google im Klartext über das aktuell verbundene Netzwerk versendet werden. Sollte sich das Opfer also beispielsweise zufällig in einem öffentlichen WLAN befinden, wird diese Anfrage an das gesamte Netzwerk und jeglichen darin angemeldeten Client gebroadcastet, bevor es an den C&C Server weitergeleitet wird.
Nach diesem initialen Massentransfer startet eine Warteschleife, die alle 60 Sekunden eine weitere Anfrage an den C&C Server sendet, um nach Instruktionen zu bitten. Diese Instruktionen werden in Form eines JSON-encoded Objekts erwartet und sehen folgendermaßen aus:
{ "data" :
{ "cmds" :
[
{"cmd" : <COMMAND_STRING>
"data" : <OPTIONAL_DATA_STRING>
}, ...
]
}
}
Über diese Form der Kommunikation ist es den Angreifern also möglich jegliche gewünschte Instruktion auf dem Gerät auszuführen. Da beim initzialen Bulk-Upload nur die gängigsten Apps abgefragt wurden, könnten das Opfer also zunächst Glück gehabt haben, sollte es einen anderen Mailclient verwendet haben. Jedoch sendet der Schädling auch eine Liste mit den installierten Apps. Möchten die Angreifer also Informationen aus einer bestimmten App, die nicht im initialen Bulk-Upload vorhanden waren, so würden sie diese Anfrage einfach über diese angeforderten Instruktionen zukommen lassen und auch prompt erhalten. Interessant zu sehen ist, dass unter den vorhandenen Methoden des Schadcodes auch unimplementierte Methoden enthalten sind.
systemmail : upload email from the default Mail.app device : upload device identifiers (IMEI, phone number, serial number etc) locate : upload location from CoreLocation contact : upload contacts database callhistory : upload phone call history message : upload iMessage/SMSes notes : upload notes made in Notes.app applist : upload a list of installed non-Apple apps keychain : upload passwords and certificates stored in the keychain recordings : upload voice memos made using the built-in voice memos app msgattach : upload SMS and iMessage attachments priorapps : upload app-container directories from hardcoded list of third-party apps if installed (appPriorLists) photo : upload photos from the camera roll allapp : upload container directories of all apps app : upload container directories of particular apps by bundle ID dl : unimplemented <-- shot : unimplemented <-- live : unimplemented <--
Wie kann man sich besser schützen?
Die Art dieses Angriffs ist äußerst ungewöhnlich und in solch einem Umfang etwas Neues. Jahre der (Weiter-)Entwicklung, verbunden mit unglaublichen Ressourcen, wurden für diese Technik ausgegeben. Das Problem hierbei ist, dass es sich um Schwachstellen handelt, auf die der normale Anwender keinerlei Einfluss hat. Der 0-day Markt für iOS ist äußerst teuer, da es diese nicht in Massen gibt. Auch wenn es, besonders durch die absolut fragwürdige Stellungnahme, nicht so scheint, bemüht sich Apple stark um die Sicherheit seiner Geräte und hat hierbei auch hervorragende Schutzmaßnahmen entwickelt. Hinter dieser Aktion müssen also gewaltige Kräfte stecken und ob man ein Ziel dieser kriminellen Machenschaften ist, lässt sich ebenfalls nicht unmittelbar herausfinden.
Als Anwender bleibt Ihnen also nur die Option Ihre Geräte immer auf dem aktuellen Stand zu halten. Also alle Updates regelmäßig einzuspielen, nicht nur von Ihrem Betriebssystem, sondern auch von jeglicher installierter Software. Außerdem sollten Sie sich vor Augen halten, dass so nützlich und notwendig unsere kleinen Helfer auch sind, diese potentiell immer gegen uns verwendet werden können und auch dementsprechend behandelt werden sollten. Die freiwillige Datenverteilung, die in den letzten Jahren zugenommen hat, muss nicht immer sein. Finden Sie eine akzeptable Balance zwischen Sicherheit, Privatsphäre und Nutzen.
Als Entwickler können Sie ebenfalls stark von diesem Fund profitieren. Wie wir festgestellt haben, wurde es den Angreifern in diesem Fall oft, oder vielleicht sogar ausschließlich, möglich überhaupt auf das System zu gelangen, weil sie vom Patch-Gap profitiert haben, dem Zeitraum zwischen öffentlichem Commit inklusive Schließung der Lücke und dem tatsächlichen Ausliefern der Updates an die Nutzer.
Sollten Sie also eine Sicherheitslücke in Ihrer Software beheben, fügen Sie unter keinen Umständen Test-Cases oder PoC in Ihre Commits mit ein. Geben Sie so wenige Informationen wie möglich bekannt, bis das Update mit den Fixes tatsächlich bei Ihren Nutzern angekommen ist und verweisen Sie danach in Ihren Patchnotes oder den folgenden Commits auf die entsprechenden CVEs.
Fazit
Die erstaunliche Komplexität, der Umfang der gefundenen Schwachstellen und das Ziel dieses Angriffs lässt nur spekulieren wer hinter diesem Angriff steckt. Entdeckt wurden diese Schwachstellen lediglich durch einen Zufall und verweisen auf eine bestimmte Water-Hole Attacke. Wo diese Lücke sonst über die Jahre ausgenutzt wurde und wer tatsächlich alles davon betroffen ist, wird wohl für immer ein Geheimnis bleiben. Auch regt dieser Fund zum Nachdenken an: Wer auch immer für diesen verantwortlich ist, hat womöglich noch viel mehr in petto, wenn er der Meinung ist für diesen speziellen Fall, diese eigentlich sehr wertvollen Lücken zu verwenden.
Ich empfehle jedem, die von mir unten aufgeführten Quellen zu lesen, sofern Sie sich für dieses Thema interessieren und gerne genaue Informationen über jeden vorgekommenen Prozess lernen möchten.
Quellen und Verweise
[1] A very deep dive into iOS Exploit – Google Project Zero Blog
[2] Implant Teardown – Google Project Zero Blog
[3] iOS Security Guide – Apple
[4] Behind the Scenes with iOS Security – Black hat 2016
[5] Heap Overflows and the iOS Kernel Heap – Azeria-Labs.com
