DNSpooq : des vulnérabilités Cache Poisoning et RCE découvertes dans dnsmasq
Lorsque l’on fait des requêtes vers un site par son nom, le nom doit être traduit en adresse IP. La correspondance est stockée par un serveur DNS, et le navigateur pose la question à ce serveur. Le serveur répond, mais en réalité, n’importe qui pourrait répondre, et l’utilisateur se retrouverait à aller sur le mauvais site web (malveillant). Pour pallier cette vulnérabilité, un identifiant de question est envoyé au serveur DNS, et le serveur répond en fournissant cet identifiant. Ainsi, il faudrait que l’attaquant ait connaissance de cet identifiant pour pouvoir forger une réponse valide. En 2008, Dan Kaminsky proposait une attaque dans le genre paradoxe des anniversaires : si l’on voit passer beaucoup de trafic, et à cause de la taille assez courte de cet ID, statistiquement, en répondant systématiquement à de potentielles questions DNS, même au hasard, un attaquant finira par fournir une réponse que la victime va considérer comme valide. La vulnérabilité a été corrigé, les identifiants sont désormais plus longs et aléatoires…Mais. Il a été constaté par une équipe de chercheurs du JSOF Research Lab que l’identifiant, qui devait être long, aléatoire, et correctement vérifié des deux côtés, n’était peut-être pas bien implémenté. Par conséquent, cet identifiant aléatoire, qui doit être une valeur parmi 2^32, est en fait vérifié parmi un ensemble de 2^19 possibilités, ce qui a l’air de rendre à nouveau possible cette "birthday attack" (dans une moindre mesure tout de même). Au passage, les chercheurs qui ont remarqué la vulnérabilité ont également identifié d’autres vulnérabilités de type exécution de code à distance sur l’implémentation de DNSSEC par pas mal de produits dont le logiciel Dnsmasq, utilisé par défaut pour quasiment toutes les distributions Linux et donc une bonne partie des équipements type routeurs/pare-feu commercialisés (DNSSec étant un protocole de DNS sécurisé, servant justement à empêcher un attaquant de lire/modifier/répondre le trafic de question/réponse dont il est question).
Un contournement du verrouillage de session via le clavier virtuel
Une belle histoire : "Il y a quelques semaines, mes enfants voulaient pirater mon ordinateur fonctionnant sous Linux, alors ils ont tapé et cliqué partout, pendant que je me tenais derrière eux en les regardant jouer … quand, soudain, j’ai vu l’économiseur d’écran crasher et qu’ils ont finalement réussi à déverrouiller ma session !". Comment ces enfants ont-ils réussi à faire cela ? En 3 étapes : 1) verrouiller la session, 2), Ouvrir le clavier virtuel, 3) Taper, en même temps, sur le plus de touches possible du clavier physique et du clavier virtuel. Et voilà ! La vulnérabilité a fait l’objet d’une CVE-2020-25712.
Une attaque très sophistiquée exploitant plusieurs 0-day sur plusieurs environnements
Les équipes de Google Project Zero et de Google Threat Analysis Group (TAG) ont publié un post de blog détaillant une attaque dont la sophistication a retenu leur attention – ce qui indique en soi le niveau de complexité de l’attaque. Les chercheurs ont découvert deux serveurs ayant servi à activer plusieurs chaines d’exploit via une attaque dite watering hole, qui consiste à piéger un site Internet légitime afin d’infecter les machines des visiteurs du domaine d’intérêt pour l’attaquant. Un des serveurs visait les utilisateurs Windows, le second les utilisateurs Android. « Les serveurs Windows et Android ont tous les deux utilisé des exploits Chrome pour permettre des attaques d’exécution de code à distance. Les charges utilisées pour Chrome et Windows incluaient des 0-day. Pour Android, les chaînes d’exploit utilisaient des vulnérabilités connues. Sur la base de la sophistication de l’acteur, nous pensons qu’il est probable qu’ils aient eu accès à des failles Android 0-day, mais nous n’en avons découvert aucun dans notre analyse », expliquent les chercheurs dans leur blog. Leur découverte a permis de mettre à jour 4 vulnérabilités pour Chrome, dont une exploitant une 0-day, 2 vulnérabilités de type "bac à sable" exploitant 3 failles 0-day dans Windows, des vulnérabilités de type "élévation de privilèges" connues pour Android. Selon les équipes de Google, les attaquants ont utilisé leur arsenal avec plusieurs approches : soit "en douceur", afin d’infiltrer les systèmes des cibles, d’adopter une attitude de "reconnaissance" pour éventuellement extirper des informations, soit une approche "directe" par laquelle les attaquants exploitaient les systèmes cibles, directement, dans leur intégralité. Tant les ressources que les modes opératoires laissent penser que les attaquants sont proches de structures étatiques, mais les équipes de Google n’ont pas pu le démontrer.
Microsoft donne davantage d’éléments sur la chaîne d’attaque de SolarWinds
Il n’y a pas que SolarWinds dans la vie, mais étant donné l’ampleur de l’attaque, les retours d’expérience sont toujours intéressants. Microsoft continue à analyser les mécanismes et le mode opératoire de cette attaque qui a fait frémir les États-Unis. Les équipes présentent cette fois-ci le chainon manquant dans la chaîne d’attaque complexe de Solorigate, qui est le transfert de la backdoor DLL Solorigate à la charge active Cobalt Strike, comprenant la charge baptisée TEARDROP par FireEye et une variante nommée Raindrop par Symantec. Une explication détaillée et illustrée, à lire.
Y’a plus, je laisse ?
Après Adobe Flash, un autre grand acteur de la cybersécurité n’est plus. On attend avec impatience de voir de quelles qualités son successeur va faire preuve.