0.18 CSI MacMark: OS X, iOS: XARA, Cross-App Resource Access Attacks Inhaltsverzeichnis

Die sogenannten XARA-Angriffe ermöglichen den Programmen unter einem User verschiedene Wege für unautorisierte Zugriffe auf die Daten der Programme unter demselben User. Was dahinter steckt und wie problematisch das wirklich ist, untersuche ich in diesem Artikel.

Flaws 2015

Im Jahr 2015 kann man es sich nicht mehr erlauben, einfach ein paar Schwachstellen zu dokumentieren. Die geschilderten Probleme müssen auch einen kernigen Namen oder ein knackiges Kürzel haben. Das haben sie auch hier gelöst, indem sie ihre lose Analyse-Sammlung XARA nennen.

Mit der Nummer wäre man vor wenigen Jahren auch noch durchgekommen. Aber heute braucht man auch noch ein Logo. So wie bei den Poodle-Angriffen den Pudel oder den Pwnie-Awards (von "to own": übernehmen, beherrschen) das rosa Pony. Kein Logo für XARA. Schade. Aber man muß ja auch nicht jeden Hipster-Gag mitmachen.

Viel schwerer wiegt hingegen die Kritik von angesehenen Schwergewichts-Hackern wie Charlie Miller, der ihre eingesetzten Werkzeuge bemängelt. Charlie sagt, sie wären keine Profis, wenn sie als Disassembler Hopper einsetzen.

Er und die anderen großen Jungs setzen IDA Pro ein. Die mir bekannten Hacker-Fachbücher arbeiten auch alle mit IDA Pro und Hopper wird nicht einmal erwähnt.

Die XARA-Probleme

Auf den üblichen Nachrichten-Seiten fehlt schlicht der Tiefgang in der Problem-Analyse. Wie immer. Wohltuend abheben tut sich der Artikel XARA, deconstructed: An in-depth look at OS X and iOS cross-app resource attacks. Den habe ich mir angesehen und natürlich die Original-Quelle über die XARA-Angriffe. Das alles kombiniert mit dem Wissen eines Programmierers für die Apple-Plattformen ergibt dann diesen Artikel hier.

Wie isst man einen Elefanten? Stück für Stück. XARA besteht aus vier verschiedenen Angriffs-Typen:

• Abreifen von Paßworten durch Fallen in Keychain-Einträgen
• Zugriff auf private Daten-Container von Programmen
• Tricks mit WebSockets
• Kommunikation abgreifen durch URL-Schema

Im Folgenden sehen wir uns die vier Punkte genauer an.

Paßworte stehlen

So lautet jedenfalls die Überschrift, die sie gebrauchen. Es werden jedoch keine bestehenden Paßworte gestohlen. Bei diesem Angriff geht es vielmehr darum, daß eine Mac-App ein Keychain-Item weiterbenutzt, das eine andere App angelegt hat und dort ihre Daten, zum Beispiel Paßworte, ablegt. Diese sind für die andere App, die das Item angelegt hat, lesbar.

Normalerweise können Apple-Apps nicht auf Keychain-Items anderer Apps zugreifen. Auf OS X kann eine App jedoch optional Zugriffslisten (Access Control Lists, ACLs) an Schlüsselbundeinträge hängen, die festlegen, wer noch so alles auf diesen Eintrag zugreifen darf. Auf iOS gibt es diese Möglichkeit gar nicht, das Problem betrifft also nur Macs.

Das gemeinsame (Weiter-)Benutzen von Schlüsselbundeinträgen ist sinnvoll bei Programm-Updates und bei Programm-Familien eines Entwicklers. Dadurch ergeben sich zwei Angriffswege:

• Man kann vorab ein Keychain-Item neu anlegen, das es noch nicht gibt, aber von dem man weiß, daß es eine bestimmte App, wenn sie mal installiert wird, benutzen wird. Diesem Eintrag gibt man eine ACL, die dem Zielprogramm Zugriff gewährt. Das Zielprogramm wird dann seine Daten in das fremdangelegte Item schreiben. Und das können auch Paßworte sein.
• Es gibt einen Bug in der Keychain, der anderen Apps erlaubt, vorhandene Einträge im Schlüsselbund zu löschen. Also löscht man einen bestehenden Eintrag und legt ihn wie im ersten Fall mit passender ACL neu an und wartet auf Daten, die reingeschrieben werden.

Man kann bei jedem einzelnen Keychain-Item prüfen, welche Apps darauf Zugriff haben. Dazu in KeyChain Access (Schlüsselbundverwaltung) einen Eintrag wählen und mit Get Info sich die Access Control Liste anschauen. Dort sollten dann keine unerwarteten Apps gelistet sein, die Zugriff haben. Genau diese Informationen können sich auch die Apps selbst holen und die Liste prüfen, um sicherzugehen, daß sie nicht mit kompromittierten Einträgen arbeiten.

Letztendlich müßte nur der Bug, der das unbefugte Löschen ermöglicht, behoben werden. Optional könnte Apple den Programmierern die Prüfung, wem der Schlüsselbundeintrag gehört, vereinfachen bzw. eine automatische Warnung in solchen Fehlen zurückgeben. Nur eine Warnung oder Hinweis, denn es gibt ja auch legitime Situationen, die ein gemeinsamens Nutzen der Einträge erfordern.

Dem Benutzer kann so ein Abgreifen auffallen, wenn die App, die sein Paßwort eigentlich schon kannte, dieses plötzlich "vergessen" hat, weil der Angreifer den Schlüsselbundeintrag gelöscht hat und auf die neuen Daten wartet.

Container Cracking

Auf Unix ist das wesentliche Sicherheits-Feature die Trennung der Benutzer untereinander. Apple ist mit OS X in den letzten Versionen noch einen Schritt weitergegangen und gibt Apps, die eine Sandbox benutzen, wozu alle Apps aus dem App Store gehören, private Verzeichnisse in ~/Library/Containers/, die als jeweils eindeutigen Namen die App-Bundle-ID der jeweiligen App tragen. Der App Store achtet darauf, daß keine IDs doppelt vorkommen.

Mit Container Cracking ist nun gemeint, daß es einen Weg gibt, wie eine App doch auf den Container einer anderen App zugreifen kann innerhalb desselben Nutzers.

Eine App kann XPC-Services und Helper-Apps enthalten. Diese haben auch eine Bundle-ID und sie bekommen ebenso Daten-Container zugewiesen wie die Apps selbst. Der Trick besteht nun darin, der Haupt-App zwar eine individuelle Bundle-ID zu geben, der Helper-App darin aber eine Bundle-ID, die der des Zielprogrammes entspricht. Dadurch kann die Helper-App auf den fremden Container zugreifen, denn beide haben dieselbe Bundle-ID.

Apple hat dieses Problem inzwischen serverseitig behoben, indem nun auch die enthaltenen Sub-Programme vom App Store auf Eindeutigkeit überprüft werden.

Für iOS stellte sich dieses Problem erst gar nicht, weil Apps und etwaige Hilfsprogramme ihre Container in unterschiedlichen Mutter-Verzeichnissen haben und außerdem zufällig erzeugte Namen tragen.

WebSockets kompromittieren

WebSockets sind eine Technik, bei der ein Webclient und ein Webserver in beide Richtungen Daten gleichzeitig senden und empfangen können. Man möchte damit den Overhead von HTTP loswerden und anstelle von Request/Response eine stehende Verbindung mit geringerer Verzögerung (Latenz) zwischen Client und Server ermöglichen. Der Name WebSocket rührt daher, daß man das Konzept der Sockets auf das Web übertragen möchte. Damit kann eine Webseite in einem Browser oder in einem WebView einer App direkt mit einer anderen App über eine JavaScript-API kommunizieren. Es handelt sich also im Gegensatz zu HTTP bei WebSockets um eine full-duplex Kommunikation.

Manche Browser-Erweiterungen wie die von 1Password übertragen sensible Daten (Paßworte oder so) über WebSockets an eine lokale App. Das Problem dabei ist, daß nicht überprüft wird, mit wem man da spricht. Belegt nämlich eine andere App den benötigten WebSocket-Port, bevor die richtige App selbst diesen Port für sich behaupten kann, dann bekommt die falsche App die Daten geschickt.

Das ist ein generelles Problem, was man als App-Entwickler lösen muß und kein Sicherheitsproblem von iOS oder OS X. Wie der Hersteller von 1Password selbst schreibt könnten sie einen Schlüssel in der Keychain ablegen, auf den die Browser-Extension und ihre App Zugriff hat, und diesen Schlüssel dazu verwenden, daß sich beider gegenseitig beweisen können, daß sie die richtigen Partner sind für die Kommunikation. Angeblich haben jedoch manche Browser Probleme, die Keychain zu benutzen.

WebSockets und ihre nicht vorhandene Authentifizierung sind ein generelles HTML 5 Problem und nichts, was speziell mit Apples Plattformen zu tun hat. Das heißt, es kann überall auftreten, wo WebSockets, die Teil von HTML 5 sind, eingesetzt werden.

In dem Original-Text sehen sie das WebSocket-Problem nur in OS X. Theoretisch kann das aber auch in iOS-Apps ein Problem sein, nur verwenden das dort lokale Apps wohl so gut wie nie, um miteinander zu kommunizieren.

URL Scheme Hijacking

Auf OS X und iOS können Apps sich für URL-Schemes registrieren. Ich kann also festlegen, daß meine App mit allen Links aufgerufen wird, die mit MyAppNameScheme:// beginnen. Dabei bekommt die App den String hinter dem Schema mitgeteilt. Viele Apps verwenden das, um Daten zu übermitteln an andere Apps.

Problematisch wird es, wenn man über solche URL-Schemes sensible Daten schickt, und andere Apps sich auf dasselbe Schema registriert haben. Damit können die Daten an eine ungewollte App übertragen werden. Darum sollten App-Entwickler eben keine kritischen Informationen per URL-Schema übertragen. Diese Übertragungs-Art gibt es zum Beispiel auch bei Android.

Es gibt allerdings URL-Schemes, auf die sich Dritt-Apps nicht registrieren können auf Apples Plattformen. Dazu gehören zum Beispiel die URL-Schemes sms und facetime. Bei anderen Schemes wie beispielsweise http kann der User auswählen, welche App (welcher Browser im Falle von http) damit geöffnet werden soll standardmäßig.

Registrieren sich mehrere Apps auf ein Schema, dann gewinnt bei iOS die letzte App, die sich darauf registriert hat, und bei OS X die erste.

Wenn eine App durch ein URL-Schema angesprochen wird, kommt sie in den Vordergrund. Es könnte also auffallen, wenn eine nicht-gewünschte App durch ein Schema geöffnet wurde anstelle der erwarteten.

Ab iOS 9 bietet Apple Universal Links als Nachfolger zu Custom URL Schemes an. Ein Vorteil von Universal Links ist, daß sie nicht von unautorisierten Apps verwendet werden können. Dazu hinterlegt der Entwickler auf seiner Webseite eine Datei, die angibt, welche Apps diese URL verwenden können. Wenn die App installiert ist, werden bestimmte Links auf diese Webseite zum Öffnen der App benutzt. Ist die App nicht installiert, wird die Webseite und keine App geöffnet. Andere Apps können die URL nicht verwenden, weil iOS prüft, welche App-IDs auf der Webseite freigeschaltet sind.

Daß das Konzept der Universal Links auch in OS X verfügbar sein wird irgendwann, halte ich für wahrscheinlich. Aktuell ist es mir dort noch nicht aufgefallen, aber Apple wird uns da hoffentlich noch positiv überraschen.

---