Et de pirater tous les sites visités par la victime à l’instar de PayPal
Un étudiant en cybersécurité a montré à Apple que ses webcams Mac sont vulnérables à des attaques de cybercriminels. La sévérité du bogue lui a permis de gagner 100 500 $ grâce au programme Bug Bounty de l’entreprise.
En effet, il explique que :
« Avec mon hack, j’ai réussi à obtenir un accès non autorisé à la caméra en exploitant une série de problèmes avec le partage iCloud et Safari 15. Bien que ce bogue oblige la victime à cliquer sur “ouvrir” sur une fenêtre contextuelle de mon site Web, il en résulte plus qu’un détournement d’autorisation multimédia. Cette fois, le bogue donne à l’attaquant un accès complet à tous les sites Web jamais visités par la victime. Cela signifie qu’en plus d’allumer votre appareil photo, mon bogue peut également pirater vos comptes iCloud, PayPal, Facebook, Gmail, etc.
« Cette recherche a abouti à 4 bogues 0day (CVE-2021-30861, CVE-2021-30975 et deux sans CVE), dont 2 ont été utilisés dans le hack de la caméra ».
Ryan Pickren, qui a précédemment découvert une vulnérabilité sur l’appareil photo iPhone, a reçu ce qui est estimé être le plus gros paiement de prime de bogue d’Apple. Selon Pickren, la nouvelle vulnérabilité de la webcam concernait une série de problèmes avec Safari et iCloud qu’il dit qu’Apple a maintenant corrigés. Avant d’être corrigé, un site Web malveillant pouvait lancer une attaque en utilisant ces failles.
Dans son récit complet de l’exploit, Pickren explique que cela donnerait à l’attaquant un accès complet à tous les comptes Web, d’iCloud à PayPal, ainsi que l’autorisation d’utiliser le microphone, la caméra et le partage d’écran. Si l’appareil photo était utilisé, cependant, son voyant vert régulier s’allumerait toujours normalement.
Pickren rapporte que le même piratage signifierait finalement qu’un attaquant pourrait obtenir un accès complet à l’ensemble du système de fichiers d’un appareil. Il le ferait en exploitant les fichiers “webarchive” de Safari, le système utilisé par le navigateur pour enregistrer des copies locales des sites Web.
« Une caractéristique surprenante de ces fichiers est qu’ils spécifient l’origine Web dans laquelle le contenu doit être rendu », écrit Pickren. « C’est une astuce géniale pour laisser Safari reconstruire le contexte du site Web enregistré, mais comme les auteurs de Metasploit l’ont souligné en 2013, si un attaquant peut modifier ce fichier d’une manière ou d’une autre, il pourrait effectivement atteindre UXSS [universal cross-site scripting] en conception ».
Un utilisateur doit télécharger un tel fichier d’archive Web, puis l’ouvrir également. Selon Pickren, cela signifiait qu’Apple ne considérait pas cela comme un scénario de piratage réaliste lors de la première mise en œuvre de l’archive Web de Safari.
« Certes, cette décision a été prise il y a près de dix ans, lorsque le modèle de sécurité du navigateur n’était pas aussi mature qu’il l’est aujourd’hui », déclare Pickren. « Avant Safari 13, aucun avertissement n’était même affiché à l’utilisateur avant qu’un site Web ne télécharge des fichiers arbitraires », a-t-il poursuivi. « Donc, télécharger dans le fichier webarchive était facile ».
Apple a payé à Pickren 100 500 $ de son programme de primes de bogues, 500 $ de plus que les paiements précédemment annoncés.
Le programme de primes aux bogues peut officiellement attribuer jusqu’à 1 million de dollars, et la société publie une liste des sommes maximales par catégorie de problème de sécurité signalé. Les experts en sécurité ne sont pas tenus de divulguer publiquement le montant qu’ils ont reçu. Il est donc possible qu’Apple ait payé plus que les 100 500 $ de Pickren. Cependant, la société a déjà été fortement critiquée pour avoir payé moins que ses propres maximums, ainsi que pour sa lenteur à corriger les bogues signalés.
Contexte de la découverte
« Apple a corrigé ma dernière chaîne 0day (CVE-2020-3852 + CVE-2020-3864 + CVE-2020-3865) en rendant l’accès à la caméra considérablement plus difficile. Désormais, l’accès multimédia n’est autorisé que lorsque le protocole est “https:” et que le domaine correspond à vos paramètres enregistrés. Cela signifie que les URI intelligemment malformés ne marcheront plus. Maintenant, nous devons véritablement injecter notre code malveillant dans l’origine cible. En d’autres termes, nous devons trouver un bogue Universal Cross-Site Scripting (UXSS).
« Mais qu’est-ce que l’UXSS exactement ? Google Project Zero a un bon résumé dans son article, “Analysis of UXSS exploits and mitigations in Chromium” : “Les attaques UXSS exploitent les vulnérabilités du navigateur lui-même […] pour atteindre une condition XSS. En conséquence, l’attaquant n’a pas seulement accès à la session utilisateur sur un seul site Web, mais peut accéder à n’importe quel [site Web]”.
« Les auteurs de cet article continuent d’estimer qu’UXSS figure “parmi les menaces les plus importantes pour les utilisateurs de n’importe quel navigateur” et ont “presque autant de valeur qu’un exploit d’exécution de code à distance (RCE) avec l’évasion du bac à sable”. Ça sonne plutôt bien, non ? Imaginez la création d’un site Web qui peut accéder à https://zoom.com pour allumer l’appareil photo, accéder à https://paypal.com pour transférer de l’argent et détourner https://gmail.com pour voler des e-mails ».
Après avoir fait cette lecture, il a essayé de trouver un bogue UXSS dans la dernière version de Safari (Safari v15 beta au moment où il rédigeait son billet). Comme toujours, la première étape consiste à faire beaucoup de recherches sur les travaux antérieurs.
Après avoir lu de nombreux articles sur les bogues Safari UXSS corrigés, il a décidé de concentrer ses recherches sur les fichiers webarchive. Ces fichiers sont créés par Safari comme alternative au HTML lorsqu’un utilisateur enregistre un site Web localement.
Une caractéristique surprenante de ces fichiers est qu’ils spécifient l’origine Web dans laquelle le contenu doit être rendu. C’est une astuce géniale pour permettre à Safari de reconstruire le contexte du site Web enregistré, mais comme les auteurs de Metasploit l’ont souligné en 2013, si un attaquant peut d’une manière ou d’une autre modifier ce fichier, il pourrait effectivement réaliser un UXSS par conception.
Selon Metasploit, Apple n’a pas considéré ce scénario d’attaque comme très réaliste, car « les archives Web doivent être téléchargées et ouvertes manuellement par le client ». Il faut préciser qu’il s’agit d’une décision qui a été prise il y a près de dix ans, lorsque le modèle de sécurité du navigateur n’était pas aussi mature qu’il l’est aujourd’hui.
La décision d’Apple de prendre en charge ce type de fichier ultra-puissant a fait place à une ère de pirates essayant de les ouvrir de force sur les machines des victimes. Fondamentalement, cette attaque peut être divisée en deux étapes :
- télécharger de force un fichier webarchive malveillant ;
- l’ouvrir de force.
Jusqu’à récemment, il n’y avait aucune protection pour empêcher l’étape numéro 1. Avant Safari 13, aucun avertissement n’était même affiché à l’utilisateur avant qu’un site Web ne télécharge des fichiers arbitraires. Donc télécharger dans le fichier webarchive était facile. (Maintenant avec Safari 13+, les utilisateurs sont invités avant chaque téléchargement).
L’ouverture du fichier webarchive était plus délicate, mais toujours gérable en naviguant d’une manière ou d’une autre vers le schéma file://URI. À l’époque où les pages d’erreur de Safari vivaient sur le schéma file://, les cybercriminels ont compris comment invoquer délibérément une page d’erreur pour simplement modifier son nom de chemin, un hack surnommé “Errorjacking”. Une autre approche qui fonctionnait à l’époque consistait simplement à définir la balise <base> sur file://.
Avance rapide jusqu’en 2022 et les choses deviennent beaucoup plus difficiles. Non seulement les téléchargements automatiques sont empêchés par défaut, mais les fichiers webarchive sont considérés comme des applications malveillantes par macOS Gatekeeper. Cela signifie que les utilisateurs ne peuvent même plus ouvrir eux-mêmes manuellement des archives Web étrangères. Apple semble avoir changé sa position de 2013 sur la dangerosité de ces fichiers.
Pourtant, les fichiers Webarchive semblent trop intéressants pour être abandonnés. Ryan Pickren a proposé une exploration pour montrer comment ce piratage à l’ancienne peut encore se produire sur les dernières versions de Safari et macOS.
Exploration de schémas d’URI personnalisés
« J’ai trouvé le succès avec mon dernier projet Safari Camera Hacking en effectuant une plongée en profondeur dans les schémas URI officiels enregistrés par l’IANA. Ce projet a été fortement guidé par les RFC et la documentation publique. Mais il existe tout un monde de schémas d’URL personnalisés dont je n’ai pas parlé. Ces schémas non officiels et (pour la plupart) non documentés sont généralement utilisés par des applications tierces iOS/macOS comme une forme de lien profond. Il existe en fait toute une communauté construite autour de la découverte et de l’utilisation de ces schémas interapplications pour des projets amusants et de hacking.
« Une remarque intéressante est que plusieurs applications système propriétaires telles que Apple Help Viewer (help://), FaceTime (facetime-audio://) et Apple Feedback (applefeedback://) prennent également en charge les schémas d’URI personnalisés. L’abus de ces schémas à partir d’un site Web dans Safari n’est pas une technique nouvelle. En effet, les pirates ont trouvé des moyens d’utiliser des schémas personnalisés pour lancer (et exploiter les bogues dans) les applications système depuis un certain temps déjà. Les hacks vont de passer des appels ennuyeux, d’aider à l’ingénierie sociale, à l’exécution arbitraire de fichiers. Sérieusement, il y a des recherches impressionnantes dans cet espace.
« Pour aider à lutter contre ces attaques, les versions modernes de Safari avertissent l’utilisateur avant de lancer aveuglément des applications secondaires. Autrement dit, à moins qu’ils ne soient l’une des exceptions codées en dur identifiées dans cette excellente présentation Blackhat.
Tous ces schémas sont enregistrés auprès de Launch Services, vous pouvez donc les lister (ainsi que d’autres) grâce à cette commande :
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump | grep -B6 bindings:.*: | grep -B6 apple-internal« Après avoir fouillé dans les schémas internes d’Apple et les avoir croisés avec ceux de confiance de Safari, j’en ai trouvé un qui a attiré mon attention – “icloud-sharing :”. Ce schéma semble être enregistré par une application de partage iCloud appelée “ShareBear”.
« ShareBear m’intéressait, car le partage de documents iCloud semblait être une voie plausible vers le téléchargement et le lancement de fichiers webarchive. Je n’ai trouvé aucune documentation ou recherche accessible au public sur ce programme, alors j’ai commencé à le fouiller moi-même ».
source : developpez
