- Pixnapping est une nouvelle technique d’attaque par laquelle une application Android malveillante vole en secret des informations personnelles affichées dans d’autres applications ou sur des sites web
- Cette attaque exploite un canal auxiliaire entre les API Android et le matériel GPU, et touche la plupart des appareils récents des grands fabricants comme Google et Samsung
- Toutes les informations visibles à l’écran, comme les codes d’authentification, les chats et les e-mails, peuvent être exposées, et l’attaque est possible sans aucune permission d’application
- Dans Google Authenticator, il est possible de dérober un code d’authentification à deux facteurs en moins de 30 secondes
- Google comme les fournisseurs de GPU disposent tous deux de peu de correctifs ou de contre-mesures fiables pour atténuer l’attaque
Vue d’ensemble
- Pixnapping est une attaque qui permet à une application Android malveillante de voler, à l’insu de l’utilisateur, les informations affichées dans d’autres applications ou sur des sites web
- La fuite d’informations repose sur l’abus d’un canal auxiliaire (side channel) entre les API Android et le GPU, et touche la plupart des smartphones Android récents, y compris les appareils Google et Samsung
- Parmi les applications effectivement touchées figurent Gmail, Signal, Google Authenticator, Venmo, Google Maps ; il est également possible de voler les codes 2FA de Google Authenticator en moins de 30 secondes
Article de recherche et démonstration
- La publication doit être présentée à ACM CCS 2025 sous le titre « Pixnapping: Bringing Pixel Stealing out of the Stone Age »
- La prépublication permet déjà de consulter le principe de l’attaque et ses détails techniques
Principales questions-réponses
Quels appareils sont concernés ?
- L’attaque a été démontrée sur des Google Pixel 6, 7, 8, 9 et Samsung Galaxy S25 sous Android 13 à 16
- Il est très probable que le principe central de l’attaque fonctionne aussi sur des appareils d’autres fabricants
Conditions de l’attaque
- Toute application Android sans permission peut lancer l’attaque
- Elle fonctionne sans aucune déclaration de permission spécifique dans le manifeste de l’application
Quelles informations peuvent être volées ?
- Toutes les informations affichées à l’écran (chats, codes d’authentification, e-mails, etc.) sont des cibles potentielles
- Les informations internes non visibles à l’écran ne peuvent pas être exfiltrées
Cas d’exploitation réels
- On ne sait pas à ce stade si la faille est exploitée activement dans la nature
Comment les utilisateurs peuvent se protéger ?
- Il est recommandé d’installer immédiatement chaque nouveau correctif de sécurité Android dès sa publication
Comment les développeurs peuvent-ils se protéger ?
- Aucune mesure de défense ou solution de contournement efficace n’a été identifiée pour le moment
- Les chercheurs demandent à être contactés en cas d’insight pertinent en matière de sécurité
Fonctionnement de l’attaque
- Une application malveillante appelle l’application cible (par ex. Google Authenticator) afin de provoquer le rendu d’informations sensibles
- Elle force ensuite l’application d’un traitement graphique (comme un flou) sur des pixels spécifiques de l’écran cible
- Elle extrait ensuite ces pixels un par un en exploitant un canal auxiliaire tel que GPU.zip
- En répétant les étapes 2 et 3, il devient possible de reconstruire l’ensemble des pixels puis d’en extraire le contenu original via OCR
- L’effet est similaire à une capture d’écran d’un contenu auquel l’application malveillante ne devrait normalement pas avoir accès
API Android exploitées
- L’attaque utilise la window blur API pour appliquer un traitement graphique (flou) à des zones de pixels sensibles
- Elle s’appuie sur des callbacks VSync pour mesurer les temps de rendu et les exploiter dans l’extraction pixel par pixel
Correctifs et réponse de Google
- Google a tenté de répondre en limitant le nombre d’activités avec effet de flou qu’une application peut invoquer, mais une solution de contournement a rapidement été découverte
- Cette solution de contournement reste actuellement non publique sous embargo
Canal auxiliaire au niveau matériel
- Les informations de pixels sont extraites via GPU.zip, un canal auxiliaire fondé sur le GPU
- En octobre 2025, aucun fabricant de GPU ne prévoit de correctif spécifique
Identifiant de vulnérabilité (CVE)
- La faille est officiellement enregistrée sous CVE-2025-48561
Impact sur les autres systèmes d’exploitation
- Android est vulnérable à ce type d’attaque parce qu’une application peut y appliquer des traitements graphiques aux données d’affichage d’une autre application et en mesurer les effets de bord
- On ignore encore si l’attaque est applicable à d’autres systèmes d’exploitation
Vulnérabilité supplémentaire App List Bypass
- Il existe aussi une vulnérabilité app list bypass permettant d’identifier la liste des autres applications installées sans permission ni déclaration dans le manifeste
- Elle peut servir au profilage des utilisateurs et, contrairement aux méthodes de contournement existantes, fonctionne sans déclaration supplémentaire
- Google l’a jugée « Infeasible » et a clos le dossier sans mesure additionnelle
Logo, code source et licence
Réponse et calendrier principal
- Entre février et octobre 2025, les vulnérabilités ont été divulguées progressivement à Google et Samsung, avec demandes de correction
- Google a classé Pixnapping et app list bypass aux niveaux de gravité High/Low, et a conclu que certains correctifs étaient insuffisants ou impossibles à mettre en œuvre
- Des correctifs supplémentaires sont prévus dans le bulletin de sécurité Android de décembre 2025
Résumé
- Pixnapping est une attaque qui exploite une combinaison de failles dans le modèle de permissions des applications et le fonctionnement du matériel pour exfiltrer illicitement des informations importantes réellement affichées à l’écran
- La situation met en évidence la nécessité de correctifs structurels à la fois dans la sécurité logicielle et matérielle d’Android
1 commentaires
Commentaires sur Hacker News
À mon avis, le problème central est que le système de permissions d’Android autorise par défaut des choses comme « exécution en arrière-plan » ou « accès à Internet » sans l’accord de l’utilisateur ; ce type d’attaque est possible parce que toutes les applications — même un jeu hors ligne — disposent de ces permissions par défaut. Beaucoup d’apps ne devraient avoir accès à Internet que « pendant l’utilisation de l’application » ; ce ne serait pas une protection parfaite, mais comme il existe toujours un risque de lancer par erreur une app malveillante, cela pourrait réduire fortement l’efficacité de l’attaque.
Je me demande s’il existe une étude sérieuse sur le niveau de risque entre les mises à jour automatiques et les mises à jour manuelles / absentes, notamment dans des environnements semi-sandboxés comme Android ; j’aimerais savoir s’il y a des travaux comparant les taux de défaillance.
En réalité, la permission d’accès à Internet existe, et sur GrapheneOS on peut carrément refuser l’accès à Internet pour les applications qui la déclarent.
Il existe une réponse convaincante à la question de savoir pourquoi Android ne demande pas l’autorisation de l’utilisateur pour l’accès à Internet dans les apps Android ; c’est une réponse directe de l’équipe de développement Android source. Concernant l’« exécution en arrière-plan », comme Android est basé sur des « intents », une app peut être réveillée à tout moment, donc une simple option « interdire l’exécution en arrière-plan » pourrait ne pas fonctionner comme l’utilisateur l’attend.
J’ai regardé la vidéo, mais j’ai quand même du mal à comprendre comment cette attaque fonctionne ; je me demande s’il est vraiment possible d’accéder aux pixels d’une app d’authentification après avoir changé d’application.
À la question de savoir comment protéger les utilisateurs en tant que développeur d’app, il est dit qu’il n’existe pas de contre-mesure publiée, mais je pense qu’on peut au moins tenter quelques approches de base : par exemple ne pas fixer la position du code secret à l’écran, le masquer en arrière-plan, le faire bouger en permanence, modifier les couleurs et le contraste, afficher du bruit statique, ou ne faire clignoter brièvement qu’une partie du code au lieu du code entier. Bien sûr, cela aurait un certain impact sur l’UX, mais en théorie cela pourrait considérablement augmenter la difficulté pour l’attaquant. Je précise toutefois que si des informations secrètes sont mises en cache via des captures d’écran, ces méthodes ont leurs limites.
Je me souviens que Google Authenticator avait autrefois changé son comportement pour n’afficher les codes TOTP qu’après un toucher ; à l’époque, je pensais que cela ne bloquait pas vraiment une menace concrète et ne faisait qu’ajouter de la gêne, et beaucoup de gens étaient du même avis, donc la fonctionnalité a été discrètement annulée peu après. Je me demande si c’était une mesure préventive contre cette faille.
Présentation d’une démo : unscreenshottable.vercel.app
Il est souligné que, pour que cette attaque soit réellement praticable contre du TOTP, il faut connaître parfaitement la police et la position des pixels. D’après l’article, voler une zone sensible de l’écran prend du temps ; par exemple, un code 2FA est renouvelé toutes les 30 secondes par défaut, donc la contrainte temporelle est stricte. Si l’attaquant ne parvient pas à exfiltrer les 6 chiffres en moins de 30 secondes, la valeur disparaît. En revanche, si la police est connue de l’attaquant, quelques pixels peuvent suffire à distinguer le code.
Il est indiqué que la technique existe depuis longtemps, mais qu’elle est très efficace pour viser des cibles de manière précise. Si l’on peut installer une application spécifique sur le téléphone d’un utilisateur, il n’est même pas forcément nécessaire de faire quelque chose d’aussi complexe : on peut simplement accéder directement aux informations voulues depuis l’application. Par exemple, si une entreprise comme Facebook affichait une alerte de confidentialité disant « cette application capture périodiquement votre écran », un nombre surprenant de personnes l’accepterait quand même. Le code source de Pixnapping devait être publié ici une fois le correctif possible, mais en réalité l’ingénierie inverse ne semble pas particulièrement difficile. Ils auraient pu attendre que le patch soit déployé, mais on a l’impression que les chercheurs voulaient susciter rapidement l’attention.
Le correctif de la vulnérabilité d’origine est déjà public ; le message de ce commit associé indique explicitement qu’il « empêche le vol de pixels en mesurant le temps de flou entre fenêtres ». Si les chercheurs ne publient pas le code, c’est parce qu’ils ont découvert une méthode de contournement de ce patch. Ils ajoutent aussi qu’« aucun fournisseur GPU n’a promis de corriger GPU.zip » et que « Google n’a pas non plus l’intention de corriger la vulnérabilité de contournement de la liste d’applications » (« clôturé comme non corrigé »). Vu que la première divulgation date du 24 février 2025, il est difficile de dire que les chercheurs ont agi dans la précipitation. Et même s’il y avait une alerte du type « cette application capture périodiquement votre écran », les écrans explicitement marqués comme non capturables ne peuvent pas être capturés sans exploit distinct.
La date de première divulgation à Google est le 24 février 2025 ; ils ont laissé suffisamment de temps.
Il est reconnu que cette attaque est une technique astucieuse exploitant le temps de rendu comme canal auxiliaire. Même avec Google Authenticator, récupérer l’ensemble des pixels prendrait un certain temps. Ce qui m’inquiète davantage, c’est jusqu’où cette méthode pourrait s’appliquer au vol d’OTP dans les SMS. Il y a aussi de plus en plus d’e-mails de phishing au format très figé, comme les notifications GitHub, au point que j’ai complètement arrêté de cliquer sur les liens dans les e-mails. Je pense aussi qu’il vaut mieux éviter désormais d’ouvrir des apps via des recommandations d’intent ; mieux vaut lancer soi-même l’application, faire ce qu’on a à faire, et supprimer les apps inutiles. La surface d’attaque peut aussi s’étendre via des SDK ou des intents de pages web, et c’est souvent sous-estimé.
En voyant seulement le titre, j’avais cru qu’il s’agissait d’un jeu dans le navigateur web.
Je ne suis pas expert en sécurité, mais j’ai l’impression que si l’on installe une application sur un bureau Windows, des attaques bien plus rapides et plus discrètes que le pixnapping d’Android sont possibles. Si l’on réutilise le même mot de passe sur plusieurs sites, l’un d’eux peut le voler et s’en servir pour se connecter ailleurs, en l’absence de couche de sécurité supplémentaire. En théorie, c’est peu sûr, mais dans la pratique ce genre d’attaque n’est ni si courant ni si facile à exécuter.
Lien vers la discussion précédente
J’ai l’impression que les appareils modernes sont devenus trop complexes pour permettre une sécurité totale ; on continue d’y ajouter sans fin des fonctions dont on n’a pas vraiment besoin, et c’est probablement pour cela qu’on se retrouve avec ce genre de situation. Je pense qu’à l’avenir, la demande pour des OS axés sur la sécurité avec un minimum de fonctionnalités, à la FreeBSD, va augmenter.
Je voudrais un environnement dans lequel je peux faire
make worlddepuis un terminal même en déplacement.Il y a Precursor, créé par Bunnie ; c’est impressionnant, mais je le trouve beaucoup trop cher. Si vous trouvez qu’une calculatrice à 100 $ est chère, Precursor a un format similaire et une puissance de calcul comparable, sauf qu’il coûte 1 000 $ et qu’on ne peut même pas l’utiliser pour un examen de maths. Blog officiel de Precursor (actuellement inaccessible, mais peut-être de nouveau disponible plus tard)
Après avoir lu les commentaires HN pendant des années, j’en viens à penser que les connaissances et les pratiques en matière de sécurité ont énormément régressé, et la généralisation de l’IA générative va probablement encore aggraver la situation. Ces temps-ci, on voit aussi beaucoup de gens parler de projets de téléphones FSF tout en se plaignant du caractère pénible des apps de banque mobile. Certains disent même qu’entrer un mot de passe toutes les 30 minutes sur desktop est trop contraignant, ou demandent s’il faut « avoir deux téléphones ». À mon avis, si un voleur vous dérobe votre téléphone après avoir observé votre saisie du mot de passe, il ouvrira immédiatement l’app bancaire, l’app d’argent, etc., pour exfiltrer un maximum de données. Ce type de crime existe réellement tous les jours. Mieux vaut ne pas installer ces applications sur son téléphone, ni les laisser connectées, et il en va de même pour les apps 2FA. C’est comme se promener avec une valise de voyage de marque très chère : on se désigne soi-même comme cible. À moins d’être un CEO ou une cible d’attaque d’envergure étatique, il faut être encore plus prudent. Même un appareil « OS de sécurité à fonctionnalités minimales » ne résout pas fondamentalement le problème du vol physique (quelqu’un voit le mot de passe puis vole l’appareil), mais il faut en tout cas séparer strictement le téléphone qui sert dans les bars avec des jeux et des apps publicitaires, de celui qui sert à la banque, à la 2FA et au travail.