Lors d’une interview accordée en 2013 à The Telegraph, Eric Schmidt, alors PDG de Google déclarait : « Vous devez vous battre pour votre vie privée ou la perdre. »
Cinq ans plus tard, alors que le scandale ‘Cambridge Analytica’ fait encore des remous, cette déclaration résonne comme une évidence. Aujourd’hui, la nature du « combat » est tout aussi claire : il s’agit de lutter pour la transparence et la responsabilité des entreprises, et la victoire passe exclusivement par la vigilance individuelle.
Dans cette optique, Imperva partage dans un nouvel article les détails d’un nouveau bug de navigateur que son équipe a découvert, bug susceptible d’affecter la majorité des utilisateurs du Web. De ce fait, des tiers malveillants pourraient jouer aux devinettes pour découvrir des données personnelles stockées par Facebook, Google et, probablement, de nombreuses autres plates-formes Web.
Le bug en question touche tous les navigateurs qui exécutent le moteur Blink utilisé par Google Chrome et constitue une menace pour les utilisateurs qui n’exécutent pas la dernière version du navigateur. Actuellement, plus de 58 pour cent de tous les utilisateurs d’Internet se servent de Google Chrome. Une fois la vulnérabilité identifiée, Google l’a corrigée dans la nouvelle version Chrome 68. Imperva recommande à tous les utilisateurs de vérifier qu’ils ont la dernière version du navigateur.
Récupération de données personnelles
Le bug en question utilise les balises HTML audio/vidéo pour générer des requêtes à destination d’une ressource cible.
La surveillance des événements de progression générés par ces requêtes permet d’avoir une visibilité de la taille réelle de la ressource interrogée. Notre équipe de recherche a découvert que cette information peut ensuite servir à poser une série de questions du type oui et non sur l’utilisateur du navigateur, en trompant les fonctions de filtrage disponibles sur les plates-formes de réseaux sociaux telles que Facebook.
Par exemple, un tiers malveillant peut créer des publications Facebook volumineuses pour chaque âge possible, en utilisant l’option de restriction d’audience, afin que le réseau social reflète l’âge de l’utilisateur à travers la taille de la réponse.
La même méthode peut servir à extraire le sexe de l’utilisateur, ses goûts et de nombreuses autres propriétés que nous avons pu obtenir à travers des publications créées ou des points d’extrémités Graph Search de Facebook.
Une réponse de grande taille indiquera que la restriction ne s’est pas appliquée, tandis que les réponses de petite taille indiqueront une restriction du contenu. Cela signifiera, par exemple, que l’utilisateur a un âge ou un sexe non autorisé. En exécutant plusieurs scripts simultanément, chacun testant une restriction distincte unique, le tiers malveillant peut récupérer relativement facilement une bonne quantité de données personnelles sur l’utilisateur.
Dans un scénario plus grave, le script de l’attaque pourrait s’exécuter sur un site nécessitant un enregistrement par courrier électronique, par exemple un site de commerce en ligne ou SaaS. Dans ce cas, les pratiques précitées pourraient permettre au tiers malveillant de corréler les données personnelles et l’adresse électronique de connexion, afin d’établir un profil plus complet et intrusif.
Déroulement de l’attaque
Lorsqu’un utilisateur visite le site du tiers malveillant, le site injecte plusieurs balises audio et vidéo masquées qui interrogent un certain nombre de publications Facebook que l’attaquant a préalablement publiées et restreintes via différentes techniques. L’attaquant peut alors analyser chaque requête pour connaître, par exemple, l’âge précis de l’utilisateur, tel qu’il est enregistré sur Facebook, indépendamment de ses paramètres de protection de la vie privée.
Comment ce bug a-t-il été découvert ?
Il y a quelques mois, Ron Masas, membre de l’équipe de chercheurs d’Imperva, examinait le mécanisme CORS (Cross-Origin Resource Sharing) en vérifiant les communications d’origines multiples de différentes balises HTML. Pendant sa recherche, il constatait un comportement intéressant dans les balises audio et vidéo. Il lui semblait que la définition de l’attribut ‘preload’ sur ‘metadata’ changeait le nombre de fois que l’événement ‘onprogress’ était appelé, d’une manière apparemment liée à la taille de la ressource demandée.
Pour vérifier son hypothèse, Ron Masas a créé un serveur NodeJS HTTP simple, qui génère une réponse de la taille d’un paramètre donné. Il a ensuite utilisé le point d’extrémité du serveur comme ressource pour le script JavaScript illustré ci-dessus.
Le script crée un élément audio masqué qui :
- Interroge une ressource spécifiée ;
- Suit le nombre de fois que l’événement ‘onprogress’ est déclenché ;
- Retourne la valeur du compteur dès que l’analyse audio échoue.
Il a commencé à faire des expériences en demandant différentes tailles de réponses, tout en recherchant une corrélation entre la taille et le nombre de fois que l’événement ‘onprogress’ était déclenché par le navigateur.
Comme le montre le graphique ci-dessous, lorsque la taille de la réponse est zéro, un seul événement ‘onprogress’ est appelé. Pour une réponse de près de 100 ko, l’événement est appelé deux fois, et ce nombre continue d’augmenter, ce qui me permet d’estimer la taille de la majorité des pages Web.
A partir de là, nous voyons que le nombre d’événements ‘onprogress’ et la taille de la réponse sont corrélés, d’où la possibilité d’indiquer si les critères de restriction ont été respectés.
Conclusion
Après avoir confirmé la vulnérabilité, Imperva l’a signalée à Google avec une démonstration du concept, et l’équipe Chrome a corrigé la vulnérabilité dans la version 68.
Imperva est honoré d’avoir contribué à protéger la vie privée de toute la communauté d’utilisateurs, comme elle le fait constamment pour les utilisateurs de ses solutions et services.
