Le fonctionnement de cette attaque de désanonymisation est difficile à expliquer mais relativement facile à comprendre une fois que vous avez compris l’essentiel. Quelqu’un qui mène l’attaque a besoin de quelques éléments pour commencer : un site Web qu’il contrôle, une liste de comptes liés à des personnes qu’il souhaite identifier comme ayant visité ce site, et du contenu publié sur les plates-formes des comptes de sa liste cible qui soit permet aux comptes ciblés de voir ce contenu ou les empêche de le voir – l’attaque fonctionne dans les deux sens.
Ensuite, l’attaquant intègre le contenu susmentionné sur le site Web malveillant. Ensuite, ils attendent de voir qui clique. Si quelqu’un sur la liste ciblée visite le site, les attaquants sauront qui ils sont en analysant quels utilisateurs peuvent (ou ne peuvent pas) voir le contenu intégré.
L’attaque tire parti d’un certain nombre de facteurs que la plupart des gens tiennent probablement pour acquis : de nombreux services majeurs, de YouTube à Dropbox, permettent aux utilisateurs d’héberger des médias et de les intégrer sur un site Web tiers. Les utilisateurs réguliers ont généralement un compte avec ces services omniprésents et, surtout, ils restent souvent connectés à ces plates-formes sur leur téléphone ou leur ordinateur. Enfin, ces services permettent aux utilisateurs de restreindre l’accès au contenu qui leur est téléchargé. Par exemple, vous pouvez configurer votre compte Dropbox pour partager une vidéo en privé avec un ou plusieurs autres utilisateurs. Ou vous pouvez télécharger publiquement une vidéo sur Facebook, mais empêcher certains comptes de la visionner.
Ces relations « bloquer » ou « autoriser » sont au cœur de la façon dont les chercheurs ont découvert qu’elles peuvent révéler des identités. Dans la version “autorisée” de l’attaque, par exemple, les pirates peuvent partager discrètement une photo sur Google Drive avec une adresse Gmail potentiellement intéressante. Ensuite, ils intègrent la photo sur leur page Web malveillante et y attirent la cible. Lorsque les navigateurs des visiteurs tentent de charger la photo via Google Drive, les attaquants peuvent déduire avec précision si un visiteur est autorisé à accéder au contenu, c’est-à-dire s’il contrôle l’adresse e-mail en question.
Grâce aux protections de confidentialité existantes des principales plates-formes, l’attaquant ne peut pas vérifier directement si le visiteur du site a pu charger le contenu. Mais les chercheurs du NJIT ont réalisé qu’ils pouvaient analyser les informations accessibles sur le navigateur de la cible et le comportement de leur processeur au fur et à mesure que la demande se produisait pour déterminer si la demande de contenu était autorisée ou refusée.
La technique est connue sous le nom d’« attaque par canal latéral », car les chercheurs ont découvert qu’ils pouvaient faire cette détermination avec précision et fiabilité en entraînant des algorithmes d’apprentissage automatique pour analyser des données apparemment sans rapport sur la façon dont le navigateur et l’appareil de la victime traitent la demande. Une fois que l’attaquant sait que le seul utilisateur qu’il a autorisé à voir le contenu l’a fait (ou que le seul utilisateur qu’il a bloqué a été bloqué), il a anonymisé le visiteur du site.
Aussi compliqué que cela puisse paraître, les chercheurs préviennent que ce serait simple à réaliser une fois que les attaquants auraient fait le travail de préparation. Cela ne prendrait que quelques secondes pour potentiellement démasquer chaque visiteur du site malveillant et il serait pratiquement impossible pour un utilisateur peu méfiant de détecter le piratage. Les chercheurs ont développé une extension de navigateur qui peut contrecarrer de telles attaques, et elle est disponible pour Chrome et Firefox. Mais ils notent que cela peut avoir un impact sur les performances et n’est pas disponible pour tous les navigateurs.
Grâce à un processus de divulgation majeur à de nombreux services Web, navigateurs et organismes de normalisation Web, les chercheurs affirment avoir entamé une discussion plus large sur la manière de traiter le problème de manière globale. Pour le moment, Chrome et Firefox n’ont pas publié de réponses publiques. Et Curtmola dit que des changements fondamentaux et probablement irréalisables dans la conception des processeurs seraient nécessaires pour résoudre le problème au niveau de la puce. Pourtant, il dit que des discussions collaboratives par le biais du World Wide Web Consortium ou d’autres forums pourraient finalement produire une solution globale.
“Les fournisseurs essaient de voir si cela vaut la peine de résoudre ce problème”, dit-il. “Ils doivent être convaincus qu’il s’agit d’un problème suffisamment grave pour investir dans sa résolution.”
