Dire que Recall est mal né est un euphémisme. A l'origine vedette du lancement des PC Copilot+, cette fonction IA de Windows enregistrant des instantanés d'écran pour mieux retrouver des traces de sa navigation est rapidement devenu « un cauchemar pour la vie privée ». Les multiples actions prises par Microsoft, qui s'était laissé plusieurs mois pour améliorer la situation en relançant cet outil en avril dernier, n'ont manifestement pas suffi. Les dernières faiblesse de sécurité de Recall ont encore été démontrées par Alexander Hagenah, directeur exécutif de SIX Group, qui avait déjà mis en évidence ses failles en 2024. Ce dernier a détaillé un Poc d'exploit, TotalRecall Reloaded, dont les conclusions ont été publiées. Lorsque l’éditeur avait relancé son outil, il assurait que sa nouvelle architecture limiterait « les tentatives de logiciels malveillants latents » exploitant l’authentification utilisateur. Une affirmation que conteste aujourd’hui Alexander Hagenah : « Lorsque vous utilisez Recall normalement, TotalRecall Reloaded, reste actif en arrière-plan, puis extrait tout ce que l'outil a pu capturer », prévient le directeur, estimant que le scénario observé correspond précisément à celui que Microsoft prétendait empêcher.

Dans la continuité de ses travaux, le chercheur indique avoir transmis ses résultats au centre de réponse aux incidents de Microsoft dès le 6 mars, accompagnés du code source et des étapes de reproduction. Après un mois d’analyse, l’éditeur a toutefois conclu le 3 avril que le comportement signalé « ne constituait pas un contournement d’une barrière de sécurité ni un accès non autorisé aux données » Une position qui n'a pas convaincue l'expert. Dans un e-mail adressé à CSO, un porte-parole de Microsoft maintient cependant sa position : « Après une enquête approfondie, nous avons déterminé que les schémas d’accès mis en évidence sont conformes aux mesures de protection prévues et aux contrôles existants, et ne constituent ni un contournement d’une barrière de sécurité ni un accès non autorisé aux données. La période d’autorisation est assortie d’un délai d’expiration et d’une protection anti-hameçonnage qui limitent l’impact des requêtes malveillantes. »

Le chiffrement pas remis en cause

Malgré ce désaccord, Alexander Hagenah ne remet pas en cause la robustesse du chiffrement mis en œuvre. Selon lui, le problème se situe ailleurs, dans la gestion des données une fois déchiffrées. « Les captures d’écran en texte clair et le texte extrait se retrouvent dans un processus non protégé pour être affichés », explique-t-il à CSO. Autrement dit, même si les données sont bien sécurisées au repos, elles deviennent exposées au moment de leur utilisation. « Tant que le contenu déchiffré passe par un processus accessible au code du même utilisateur, quelqu’un trouvera un moyen d’y accéder », souligne-t-il. Partant de ce constat, Alexander Hagenah estime qu’une correction partielle pourrait être mise en œuvre rapidement. « La solution à court terme est assez simple. Microsoft pourrait renforcer l'intégrité du code et les protections du processus AIXHost.exe, qui affiche la chronologie de Recall. À l'heure actuelle, il n'en dispose d'aucune, ce qui rend l'injection possible. « Cela bloquerait la technique spécifique que j'ai démontrée et rendrait la tâche nettement plus difficile », a-t-il déclaré.

Mais, selon lui, cette approche ne traiterait qu’une partie du problème. A plus long terme, la question est plus structurelle. « Microsoft devrait repenser la manière dont les données déchiffrées sont traitées après avoir quitté l’enclave. Le problème est que les captures d’écran en clair et le texte extrait se retrouvent dans un processus non protégé pour être affichés. Tant que le contenu déchiffré passe par un processus accessible au code du même utilisateur, quelqu’un trouvera un moyen de s’introduire », a-t-il déclaré. Selon lui, seule une refonte plus profonde garantirait de corriger durablement la faille. « Une solution durable impliquerait soit d'effectuer le rendu au sein d'un processus protégé, soit d'adopter un modèle de composition dans lequel les données brutes ne franchissent jamais la limite de confiance. Cela demande davantage d'efforts, mais c'est la seule façon de résoudre correctement ce type de problème », a-t-il ajouté.

Un risque réel d'exploitation

Le seuil nécessaire pour exploiter cette technique serait plus faible que ne le laissent entendre les messages de sécurité de Microsoft, selon Alexander Hagenah. Il suffit, explique-t-il, qu’un code s’exécute dans le contexte de l’utilisateur et puisse réutiliser une session Recall autorisée. « C’est un seuil bien plus bas que ce que beaucoup de gens pourraient supposer à la lecture des messages de sécurité de Microsoft », précise-t-il. Certes, le fait que Recall soit limité aux PC Copilot+ et proposé en option réduit l’ampleur de l’exposition globale. Toutefois, le chercheur estime que des usages malveillants ciblés restent possibles à court terme. « En ce qui concerne les abus ciblés, la surveillance ou la collecte de données sur des utilisateurs de grande valeur, ce scénario est tout à fait plausible », ajoute-t-il.

Dans une logique de défense proactive, l'expert indique avoir publié volontairement le code source afin de donner la possibilité aux défenseurs, aux fournisseurs d’EDR et aux équipes de sécurité de développer des mécanismes de détection en amont. « A mon avis, cela donne aux défenseurs une précieuse longueur d’avance », souligne-t-il. Une analyse que rejoint le chercheur indépendant en sécurité Kevin Beaumont, après ses propres tests de la mise en œuvre actuelle de Recall. « Oui, on peut simplement lire la base de données en tant que processus utilisateur », écrit-il sur Mastodon le 11 mars. « La base de données contient également toutes sortes de champs qui ne sont pas rendus publics et qui servent à suivre l'activité de l'utilisateur. Aucune alerte antivirus ou EDR n'a été déclenchée », a-t-il constaté.