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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par DevTroglodyte
