Kaspersky a découvert une faille zero-day utilisée pour lancer des attaques via Google Chrome

Les internautes sont invités à effectuer une mise à jour de leur navigateur

Récemment, Kaspersky a découvert un nouvel exploit qui a ciblé une faille inconnue du navigateur Chrome de Google. Le spécialiste en sécurité en a rapidement informé l’équipe de sécurité de Google Chrome. Après avoir examiné la PoC qui lui a été fournie, Google a confirmé qu'il existait une vulnérabilité zero day dans son navigateur à qui a été attribuée le numéro CVE-2019-13720. Google a publié une mise à jour de Chrome qui vient corriger la faille sur Windows, macOS et Linux et il est recommandé aux utilisateurs de passer à cette version Chrome 78.0.3904.87.

Kaspersky indique que « nous appelons ces attaques Operation WizardOpium. Jusqu'à présent, nous n'avons pas pu établir de lien définitif avec les acteurs de la menace connus. Il existe certaines de très faibles similitudes de code avec les attaques de Lazarus, bien que celles-ci pourraient très bien être une opération sous fausse bannière. Le profil du site Web ciblé correspond davantage aux précédentes attaques de DarkHotel qui avaient récemment déployé des attaques similaires sous fausses bannières ». Les opérations sous fausses bannières sont des actions menées avec utilisation des marques de reconnaissance de l'ennemi.

Détails techniques

L’attaque utilise une injection semblable à une attaque de point d’eau sur un portail d’informations en coréen. Un code JavaScript malveillant a été inséré dans la page principale, ce qui charge à son tour un script de profilage à partir d'un site distant. Une attaque par point d'eau fait référence à un prédateur qui, au lieu d'aller chercher sa proie, préfère l'attendre à un endroit où il est sûr qu'elle viendra (en l’occurrence à un point d'eau pour s'abreuver).


La page d'index principale hébergeait une petite balise JavaScript qui chargeait un script distant à partir de hxxp://code.jquery.cdn.behindcorona[.]Com /.

Le script charge ensuite un autre script nommé .charlie.XXXXXXXX.js. Ce script vérifie si le système de la victime peut être infecté en effectuant une comparaison avec l’agent utilisateur du navigateur, qui doit s’exécuter sur une version 64 bits de Windows et ne pas être un processus WOW64. il essaie également d’obtenir le nom et la version du navigateur. La vulnérabilité tente d'exploiter le bogue dans le navigateur Google Chrome et le script vérifie si la version est supérieure ou égale à 65 (la version actuelle de Chrome est 78) :


Si la version du navigateur est validée, le script commence à exécuter un certain nombre de requêtes AJAX sur le serveur contrôlé de l'attaquant (derrière Corona[.]Com) où un nom de chemin pointe vers l'argument transmis au script (xxxxxxx.php). La première demande est nécessaire pour obtenir des informations importantes pour une utilisation ultérieure. Ces informations incluent plusieurs chaînes codées en hexadécimal qui indiquent au script le nombre de fragments du code d’exploitation réel qui doivent être téléchargés à partir du serveur, ainsi qu’une URL vers le fichier image qui incorpore une clé pour la charge finale et une clé RC4 pour déchiffrer des morceaux du code de l'exploit.


Après avoir téléchargé tous les morceaux, le script RC4 déchiffre et concatène toutes les parties, ce qui donne à l'attaquant un nouveau code JavaScript contenant l'exploit intégral du navigateur. Pour déchiffrer les pièces, la clé RC4 précédemment récupérée est utilisée.


Le script d'exploitation du navigateur est obscurci. Après avoir effectué le procédé inverse, Kaspersky a observé quelques particularités :

1. Une autre vérification est effectuée par rapport à la chaîne de l'agent utilisateur : cette fois, le script vérifie que la version du navigateur est 76 ou 77. Cela pourrait signifier que les auteurs de l'exploit ont uniquement travaillé sur ces versions (une étape d'exploitation antérieure vérifie que le script est en présence de la version 65 ou d'une version plus récente) ou que d'autres exploits ont été utilisés dans le passé pour les anciennes versions de Chrome.
   
   
   
   Code d'exploitation obscurci
2. Quelques fonctions opèrent dans la classe BigInt intégrée du navigateur, ce qui est utile pour effectuer l’arithmétique 64 bits dans le code JavaScript, par exemple pour travailler avec des pointeurs natifs dans un environnement 64 bits. Habituellement, les exploits des développeurs implémentent leurs propres fonctions à cet effet en travaillant avec des nombres 32 bits. Cependant, dans ce cas, BigInt est utilisé, ce qui devrait être plus rapide, car il est implémenté de manière native dans le code du navigateur. Les développeurs d’exploit n’utilisent pas les 64 bits ici, mais opèrent sur une plage de nombres plus petite. C'est pourquoi ils implémentent quelques fonctions pour travailler avec les parties hautes / basses du nombre.
   
   
   
   Extrait de code pour travailler avec des nombres 64 bits
3. De nombreuses fonctions et variables ne sont pas utilisées dans le code actuel. Cela signifie généralement qu'ils ont été utilisés pour le débogage du code et qu'ils ont ensuite été laissés lorsque le code a été déplacé en production.
4. La majorité du code utilise plusieurs classes liées à un certain composant vulnérable du navigateur. Comme ce bogue n’avait toujours pas été corrigé lors de la rédaction de son billet, Kaspersky a décidé de ne pas inclure les détails sur le composant vulnérable spécifique.
5. Il y a quelques grands tableaux avec des nombres qui représentent un bloc de shellcode et une image PE intégrée

L'exploit a utilisé un bogue de condition de concurrence entre deux threads en raison d'un manque de synchronisation correcte entre eux. Cela donne à un attaquant une condition Use-After-Free (UaF) très dangereuse, car elle peut conduire à des scénarios d'exécution de code, ce qui est exactement ce qui se produit dans ce cas.

L’exploit essaie d’abord de faire en sorte que UaF effectue une fuite d’informations sur les adresses 64 bits importantes (en tant que pointeur). Cela entraîne plusieurs choses : 1) si une adresse est divulguée avec succès, cela signifie que l'exploit fonctionne correctement; 2) une adresse divulguée est utilisée pour savoir où se trouve le tas / la pile et qui annule la technique de randomisation du format d'espace d'adresse (ASLR); 3) quelques autres indications utiles pour une exploitation ultérieure pourraient être localisées en cherchant près de cette adresse.

Après cela, il essaie de créer un groupe d'objets volumineux à l'aide d'une fonction récursive. Ceci est fait pour créer une disposition de tas déterministe, ce qui est important pour une exploitation réussie. Dans le même temps, il tente d'utiliser une technique de type heap spraying qui vise à réutiliser le même pointeur que celui qui avait été libéré précédemment dans la partie UaF. Cette astuce pourrait être utilisée pour semer la confusion et donner à l'attaquant la possibilité d'opérer sur deux objets différents (du point de vue du code JavaScript), bien qu'en réalité ils se trouvent dans la même région de mémoire.

L'exploit tente d'effectuer de nombreuses opérations d'allocation / libération de mémoire en même temps que d'autres techniques qui finissent par donner aux attaquants une primitive de lecture / écriture arbitraire. Ceci est utilisé pour créer un objet spécial qui peut être utilisé avec WebAssembly et FileReader pour exécuter le code pour la charge utile du shellcode incorporé.

Source : Kaspersky, Google

Et vous ?

Sur quel navigateur êtes-vous ?
À quelle fréquence faites-vous des mises à jour ?
La publication de problème de cet ordre constitue-t-elle un facteur vous poussant à faire des mises à jour ou vos décisions de faire des MàJ n'en sont pas tributaires ?