Comment boucher un trou noir ?

A l’heure actuelle, l’exploitation de vulnérabilités dans une application légitime est une des méthodes les plus souvent utilisées pour infecter un ordinateur. Et d’après nos estimations, les attaques contre les ordinateurs les plus nombreuses sont celles organisées à l’aide de codes d’exploitation de vulnérabilités dans Oracle Java. Les solutions de protection modernes sont parfaitement en mesure de déjouer les attaques par téléchargement à la dérobée organisées à l’aide de kits d’exploitation. Nous allons étudier les différentes phases de l’infection d’un ordinateur à l’aide du kit d’exploitation Blackhole et présenter les mécanismes de protection correspondant.

Kits d’exploitation

En règle générale, les individus malintentionnés n’utilisent pas qu’un seul code d’exploitation, mais bien des ensembles de codes prêts à l’emploi : les kits d’exploitation. Ceci permet d’accroître sensiblement l’efficacité de l’offensive car un ou plusieurs codes d’exploitation peuvent être activés pendant l’attaque, chacun d’entre eux exploitant une vulnérabilité présente dans une application installée sur l’ordinateur de la victime.

Alors que par le passé les codes d’exploitation et les programmes malveillants utilisés pour les introduire étaient développés par les mêmes individus, cette branche du marché noir fonctionne désormais selon le modèle SaaS (logiciel en tant que service). Suite la répartition du travail, chaque groupe d’individus malintentionnés remplit une fonction propre : certains développent et vendent des kits d’exploitation et d’autres attirent les victimes sur les pages d’entrée des codes d’exploitation (génération du trafic) ou créent les programmes malveillants propagés dans le cadre des attaques par téléchargement à la dérobée. De nos jours, l’individu malintentionné qui souhaite infecter des ordinateurs avec une des modifications du cheval de Troie ZeuS par exemple, peut tout simplement acheter un kit d’exploitation prêt à l’emploi, le configurer et orienter les victimes potentielles vers une page d’entrée (landing).

Les individus malintentionnés disposent de plusieurs moyens pour attirer les victimes sur la page d’entrée. Le plus dangereux est l’infection de pages sur des sites légitimes à l’aide de scripts ou de iframe. Dans ce cas, la victime visite de sa propre initiative un site connu et cela suffit pour déclencher l’attaque par téléchargement à la dérobée et l’activité du kit d’exploitation à l’insu de la victime. Les cybercriminels peuvent utiliser également des systèmes de publicité légitimes et introduire des liens vers des pages malveillantes dans des bannières ou des teasers. Une autre méthode privilégiée des individus malintentionnés consiste à diffuser les liens vers la page d’entrée dans du courrier indésirable.

 
Schéma traditionnel de l’infection d’ordinateurs à l’aide de kits d’exploitation

Il existe actuellement sur le marché une grande variété de kits d’exploitation : Nuclear Pack, Styx Pack, BlackHole, Sakura, etc. La diversité des noms ne doit pas faire oublier que le but poursuivi est le même : il s’agit d’une sélection de divers codes d’exploitation associés à un panneau d’administration. De plus, toutes les sélections de codes d’exploitation fonctionnent pratiquement toutes selon le même schéma.

BlackHole est un des kits d’exploitation les plus connus du marché. Il contient des codes d’exploitation qui visent des vulnérabilités dans Adobe Reader, Adobe Flash Player et Oracle Java. Pour garantir une efficacité maximale, les codes d’exploitation repris dans le kit sont remplacés en permanence. Au début de l’année 2013, nous avons étudié trois codes d’exploitation pour Java qui figuraient dans BlackHole et c’est BlackHole que nous avons sélectionné pour illustrer les principes de fonctionnement des kits d’exploitation dans cet article.

Dans le trou noir

Avant toute chose, il faut signaler que les informations relatives aux codes d’exploitation contenus dans les pages d’entrée et toutes autres informations que nous avons analysées (notamment les noms des méthodes, des catégories, les valeurs des constantes) étaient d’actualité au moment où l’étude a été organisée. Le fait est que les individus malintentionnés poursuivent le développement actif de BlackHole : afin de compliquer la tâche des solutions antivirus, ils introduisent souvent des modifications dans le code d’un code d’exploitation ou autre ; il modifie par exemple l’algorithme de chiffrement utilisé.

Page d’entrée du kit d’exploitation

La page d’entrée du kit d’exploitation permet de définir les paramètres d’entrée et les décisions sur les actions ultérieures du kit d’exploitation. Les paramètres d’entrée désignent la version du système d’exploitation de l’utilisateur, la version du navigateur et des plug-ins installés, la locale du système d’exploitation, etc. En règle générale, les paramètres d’entrée influencent la sélection des codes d’exploitation correspondant pour les attaques contre le système. Si l’application indispensable au kit d’exploitation n’est pas installée sur l’ordinateur de l’utilisateur, l’attaque n’a pas lieu. Une attaque peut également ne pas avoir lieu quand les individus malintentionnés souhaitent éviter que le contenu d’un compte d’exploitation tombe entre les mains d’experts d’éditeurs de logiciels antivirus ou d’autres chercheurs. Ainsi, les cybercriminels peuvent ajouter les adresses IP des centres de recherche (araignées, robots, serveurs proxy) à leurs listes noires et bloquer l’exécution des codes d’exploitation sur des machines virtuelles ou autres.

La capture d’écran ci-dessous illustre le code d’une page d’entrée du kit d’exploitation BlackHole.

 
Capture d’écran du code de la page d’entrée du kit d’exploitation BlackHole

Un simple survol de cette capture d’écran permet de voir que le code JavaScript est obfusqué et qu’une grande partie des informations est chiffrée.

La requête envoyée à la page d’entrée déclenchera l’exécution du code qui était chiffré à l’origine. Pour compliquer la détection, les individus malintentionnés adoptent des techniques spéciales (entourées en jaune sur l’illustration).

En outre, une multitude de petites modifications sont introduites dans le code afin de perturber la détection à l’aide de signatures. Bien que notre moteur antivirus, par exemple, intègre un émulateur de script et que de simples modifications au niveau d’une constante ou d’opérations n’ont aucun impact sur l’efficacité de la détection, les quelques astuces décrites ci-dessus suffisent à compliquer la tâche de l’émulateur.

Une fois que le code a été déchiffré dans la mémoire vive, un code, que nous appelons le « script déchiffré », apparaît. Il est composé de deux parties.

La première partie est un module de la bibliothèque gratuite PluginDetect qui permet de définir la version et les capacités de la majorité des navigateurs modernes et de leurs plug-ins. Les individus malintentionnés utilisent diverses bibliothèques, mais ce module est un des éléments clés de n’importe quel kit d’exploitation. BlackHole utilise PluginDetect afin de pouvoir sélectionner les codes d’exploitation qui conviennent en fonction des applications installées sur l’ordinateur de la victime. Par « codes d’exploitation qui conviennent », nous voulons dire les codes d’exploitation qui ont le plus de probabilité de fonctionner et de lancer un programme malveillant sur un ordinateur en particulier.

La deuxième partie du « script déchiffré » est un code chargé du traitement des résultats de l’exécution des fonctions de PluginDetect et du téléchargement des codes d’exploitation sélectionnés, suivi de leur exécution.

En mars 2013, BlackHole utilisait des codes d’exploitation pour les vulnérabilités suivantes :

  1. Java de la version 1.7 à 1.7.х.8 – CVE-2012-5076 ;
  2. Java antérieur à 1.6 de la version 1.6 à 1.6.х.32 – CVE-2012-0507 ;
  3. Java de la version 1.7.х.8 à 1.7.х.10 – CVE-2013-0422 ;
  4. Adobe Reader antérieur à la version 8 – CVE-2008-2992 ;
  5. Adobe Reader version 8 ou de la version 9 à 9.3 – CVE-2010-0188 ;
  6. Adobe Flash de la version 10 à 10.2.158 – CVE-2011-0559 ;
  7. Adobe Flash de la version 10.3.181.0 à 10.3.181.23 et antérieur à la version 10.3.181 – CVE-2011-2110.

Nous allons nous pencher sur les codes d’exploitation de vulnérabilités Java (pour une analyse technique détaillée, consultez la version anglaise de l’article).

Trois en un

Le mécanisme de fonctionnement de ces trois codes d’exploitation Java est pratiquement identique : ils obtiennent des privilèges et lancent une charge utile qui télécharge et exécute le fichier cible. Le fichier class Java, généré par chacun de ces trois codes d’exploitation, est identique. Cela démontre que ces trois codes d’exploitation ont été développés par le même groupe d’individus ou par la même personne. La seule différence se situe au niveau de la méthode utilisée pour obtenir les privilèges illimités pour le fichier class.

Ce fichier class est capable de télécharger et d’exécuter des fichiers tout en déchiffrant les paramètres transmis depuis le script déchiffré. Afin de compliquer la détection, le fichier malveillant téléchargé est chiffré et par conséquent, il ne commence pas par l’en-tête PE. Le fichier téléchargé est déchiffré dans la mémoire à l’aide de l’algorithme XOR.

Le transfert des paramètres depuis le script déchiffré est une méthode pratique pour changer rapidement les liens utilisés pour télécharger la charge utile car il suffit simplement de modifier les informations sur la page d’entrée du kit d’exploitation sans devoir recompiler l’applet Java malveillant.

Les trois vulnérabilités étudiées visent des erreurs dans la logique. Il est impossible d’utiliser des méthodes automatiques qui vérifient par exemple l’intégrité de la mémoire ou la génération d’exclusions pour contrôler les requêtes adressées par ces codes d’exploitation aux vulnérabilités. Par conséquent, les technologies DEP et ALSR de Microsoft ou d’autres solutions automatiques similaires ne permettent pas de détecter ces codes d’exploitation. Il existe toutefois des technologies qui permettent d’éliminer ce problème. Il s’agit notamment de notre technologie Automatic Exploit Prevention (AEP).

Protection contre les codes d’exploitation Java

Malgré tous les efforts déployés par les individus malintentionnés, les solutions de protection modernes sont parfaitement en mesure de déjouer les attaques par téléchargement à la dérobée organisées à l’aide de kits d’exploitation. En règle générale, la protection contre les codes d’exploitation repose sur un arsenal de technologies complexes capables de déjouer de telles attaques à différentes étapes.

Nous avons présenté ci-dessus le principe de fonctionnement du kit d’exploitation BlackHole. Nous allons maintenant aborder la protection que les solutions de Kaspersky Lab peuvent offrir à chaque étape d’une attaque impliquant les codes d’exploitation Java de BlackHole. Dans la mesure où le fonctionnement d’autres kits d’exploitation est identique à celui de BlackHole, le modèle de protection que nous allons présenter ici peut être considéré comme universel.

 
Modèle de la protection étape par étape
contre les attaques par téléchargement à la dérobée

Nous allons donc nous pencher sur les modules de la protection qui interagissent avec le code malveillant, sur la forme de cette interaction et sur le moment où cette interaction a lieu.

Etape 1 : blocage de l’accès à la page d’entrée

L’attaque débute dès que l’utilisateur accède à la page d’entrée du kit d’exploitation. Toutefois, le module Internet de l’Antivirus peut déjouer l’attaque même avant son déclenchement, à savoir avant l’exécution du script de la page d’entrée. Ce module de la protection analyse l’URL de la page Web sollicitée. Il s’agit d’une simple recherche de l’URL dans la base des liens malveillants mais elle permet de bloquer l’accès de l’utilisateur à la page d’entrée du kit d’exploitation si l’URL correspondante figure déjà dans la liste des adresses malveillantes.

Le rôle des éditeurs de logiciels antivirus dans ce contexte consiste à ajouter les liens malveillants le plus rapidement possible à la base. Ces bases d’URL malveillantes peuvent se trouver sur l’ordinateur de l’utilisateur ou dans le Cloud (sur un serveur distant). Dans ce dernier cas de figure, les technologies dans le cloud permettent de réduire au minimum l’intervalle entre la détection de nouveaux liens malveillants et le blocage de ceux-ci. Le temps de réaction est réduit car le logiciel de protection installé sur l’ordinateur obtient les informations relatives à la nouvelle menace dès que les entrées relatives à ces liens sont ajoutées à la base. Il n’est donc pas nécessaire d’attendre la prochaine mise à jour des bases antivirus.

De leur côté, les individus malintentionnés tentent de changer rapidement les domaines des pages d’entrée des kits d’exploitation dans l’espoir d’éviter le blocage de celles-ci par les solutions de protection. Au bout du compte, cela réduit la rentabilité de leur activité.

Étape 2 : détection par l’antivirus de fichiers

Si l’utilisateur arrive malgré tout sur la page d’entrée, c’est au tour des modules de l’Antivirus Fichiers d’intervenir : le détecteur statique et l’analyseur heuristique. Ces deux modules recherchent la présence éventuelle d’un code malveillant sur la page d’entrée du kit d’exploitation. Arrêtons-nous un instant sur les principes de fonctionnement de chacun de ces modules ainsi que sur leurs avantages et leurs inconvénients.

  • Le détecteur statique procède à la détection du code malveillant sur la base de signatures statiques. Ces signatures fonctionnent exclusivement avec des extraits de code précis, sur des séquences d’octets concrètes. Cette méthode de détection des menaces remontent aux premiers logiciels antivirus et ses avantages sont bien connus : rapidité et simplicité de la conservation des signatures. Pour émettre un verdict, le détecteur doit simplement comparer la somme de contrôle ou une séquence d’octets du code analysé aux entrées correspondantes dans les bases antivirus. Les signatures utilisées n’occupent que quelques dizaines d’octets et peuvent être compactées. Leur conservation est donc très simple. Le principal inconvénient du détecteur statique est la simplicité avec laquelle cette protection peut être déjouée. Il suffit de modifier un seul octet pour que l’objet ne soit plus détectable. L’autre désavantage est que pour pouvoir couvrir un nombre important de fichiers, il faut disposer d’un volume important de signatures, ce qui entraîne une augmentation sensible de la taille des bases.
  • L’analyseur heuristique repose également sur des signatures, mais selon un principe tout autre. Il procède à l’analyse de l’objet reçu : collecte et traitement intelligent des informations relatives à l’objet, mise en évidence les tendances, calcul statistique, etc. Si les données obtenues suite à l’analyse répondent aux conditions de la signature heuristique, l’objet est considéré comme malveillant. Le principal avantage des signatures heuristiques est qu’elles permettent de détecter immédiatement un nombre élevé d’objets de type identique et qui ne diffèrent que très peu les uns des autres. Le désavantage de cette méthode est que l’analyseur heuristique peut fonctionner plus lentement que le traitement des signatures statiques et ralentir le système. Ainsi, quand une signature heuristique n’a pas été rédigée de manière efficace, le nombre d’opérations nécessaires à l’exécution de l’algorithme d’analyse augmente, ce qui peut avoir un impact négatif sur les performances du système où le logiciel antivirus est installé.

Pour empêcher la détection de l’objet à l’aide de la signature statique, les individus malintentionnés doivent introduire le plus souvent possible des modifications minimes dans le code de l’objet (script, fichier exécutable, fichier). Ce processus peut être automatisé dans une certaine mesure.

Pour éviter la détection heuristique, l’auteur du virus doit procéder à une analyse afin de comprendre comment l’objet est détecté. Une fois que l’algorithme a été partiellement ou complètement étudié, il faut introduire dans le code de l’objet malveillant des modifications qui vont empêcher l’intervention des signatures heuristiques.

Il est clair que l’individu malintentionné qui souhaite trouver la parade à la détection heuristique va devoir consacrer plus de temps dans ce cas que pour déjouer les détections à l’aide de signatures statiques. Cela signifie que la durée de vie d’une signature heuristique est supérieure. D’un autre côté, après que les auteurs du virus ont modifié l’objet à détecter pour déjouer l’analyse heuristique, l’éditeur du logiciel antivirus doit également déployer pas mal d’efforts pour créer une autre signature.

Pour cette raison, le logiciel antivirus utilise plusieurs sélections de signatures pour analyser les pages d’entrée. De leur côté, les auteurs de virus modifient les objets sur la page d’entrée du kit d’exploitation. Ces modifications permettent de déjouer la détection à l’aide des deux types de signature. Alors que pour déjouer les signatures statiques, les individus malintentionnés doivent seulement scinder les chaînes en caractères, ils doivent utiliser toutes les finesses du langage JavaScript pour déjouer l’analyse heuristique (fonctions inhabituelles, comparaisons, expressions logiques, etc.). Nous avons fourni un exemple de l’obfuscation dans la première partie de l’article. La détection a souvent lieu à cette étape en raison de l’obfuscation exagérée du code qui peut être identifiée comme un indice d’objet malveillant.

Outre les bases conservées sur le disque dur, il existe des signatures qui sont stockées dans le cloud. En général, ces signatures sont très simples, mais la durée de réaction extrêmement brève face aux nouvelles menaces (jusqu’à 5 minutes entre la création de la signature et son apparition dans le nuage) garantit une protection de qualité aux ordinateurs des utilisateurs.

Etape 3 : détection des codes d’exploitation à l’aide de signatures

Si la solution de protection n’a pas été en mesure d’identifier la page d’entrée du kit d’exploitation, celui-ci se met au travail. Il vérifie les plug-ins installés dans le navigateur (Adobe Flash Player, Adobe Reader, Oracle Java, etc.) et détermine ainsi les codes d’exploitation à charger et à exécuter. La solution de protection analysera chaque code d’exploitation chargé de la même manière que la page d’entrée, c.-à-d. à l’aide de l’Antivirus Fichiers et des signatures dans le Cloud. Les techniques adoptées par les individus pour éviter la détection à ce niveau sont identiques à celles décrites ci-dessus.

Etape 4 : détection proactive des codes d’exploitation

Si aucun des modules de la protection réactive (à l’aide de signatures) n’a découvert des anomalies pendant l’analyse du contenu du kit d’exploitation et que le code d’exploitation a été exécuté, les modules de protection proactive entrent en scène. Ils surveillent en temps réel le comportement des applications dans le système et isolent toute activité malveillante.

Chaque application, sur la base des résultats de l’analyse, du Cloud et d’autres éléments est rangée dans une des catégories suivantes : « Trusted », « Low Restrictions », « High Restrictions » ou « Untrusted ». Le module Contrôle des applications limite l’activité de l’application sur la base de la catégorie à laquelle elle appartient. Les applications de la catégorie « Trusted » ne sont soumises à aucune restriction. Pour les applications de la catégorie « Low Restrictions », les restrictions portent par exemple sur l’accès au référentiel de mots de passe. Les applications de la catégorie « High Restrictions » ne peuvent pas modifier les dossiers système, etc. Toutes les applications en cours d’exécution sont analysées à l’aide d’un module baptisé « Contrôle des applications » dans nos solutions de protection. Ce module surveille l’exécution des applications dans le système à l’aide d’intercepteurs de bas niveau.

De plus, pour identifier un comportement dangereux, l’application utilise des signatures de comportement spéciales qui décrivent l’activité malveillante. Ces signatures sont créées par des experts de la lutte contre les virus et sont comparées au comportement de l’application en exécution. Ceci permet à la Défense proactive de détecter de nouvelles versions d’un programme malveillant qui ne figuraient pas dans les catégories « Untrusted » ou « High Restrictions ». Il faut dire que ce type de détection est le plus efficace car les données analysées sont relatives à l’activité réelle de l’application au moment de l’analyse. Il ne s’agit pas d’une analyse statique ou heuristique. Par conséquent, l’obfuscation ou le chiffrement du code malveillant sont privés de leur efficacité, car ces deux méthodes n’ont absolument aucun effet sur le comportement du programme malveillant.

Afin de réaliser une surveillance plus poussée des applications dont les vulnérabilités pourraient être exploitées par des codes d’exploitation, nous utilisons la technologie « Automatic Exploit Prevention ». Le module AEP surveille le lancement du moindre processus dans le système. Il recherche la présence d’anomalies dans la pile de requêtes, vérifie le code à l’origine du lancement du processus, etc. Cette technologie permet également de réaliser une analyse des bibliothèques dynamiques chargées dans le processus.

Toutes ces actions permettent d’éviter l’exécution de processus malveillants suite à l’exploitation d’une vulnérabilité. Il s’agit en fait de la dernière ligne de défense contre les codes d’exploitation quand les autres modules ont échoué. Si une application comme Oracle Java ou Adobe Reader manifeste un comportement douteux suite à l’exécution d’un code d’exploitation, le logiciel antivirus bloque l’application vulnérable, ce qui empêche l’exécution du code d’exploitation.

Vu que cette étape consiste à analyser le comportement de l’application, les individus malintentionnés qui souhaitent résister à la défense proactive doivent adopter des méthodes complexes qui demandent beaucoup de travail.

Etape 5 : détection des programmes malveillants téléchargés (charge utile)

Si le code d’exploitation a survécu jusqu’ici, il tente de télécharger et d’exécuter une charge utile sur l’ordinateur.

Comme nous l’avons écrit ci-dessus, afin de compliquer la détection, le fichier malveillant téléchargé par le code malveillant est chiffré et par conséquent, il ne commence pas par l’en-tête PE. Le fichier téléchargé est déchiffré dans la mémoire à l’aide de l’algorithme XOR. Ensuite, le fichier est soit exécuté depuis la mémoire (en général, il s’agit d’une bibliothèque dynamique), soit placé sur le disque et exécuté depuis celui-ci.

Le téléchargement d’un fichier PE chiffré permet de tromper l’Antivirus car pour ce dernier, le téléchargement ressemblera à un flux de données normal. Mais l’élément important est que le code d’exploitation lancera sur l’ordinateur de la victime un fichier exécutable déjà déchiffré. Et le logiciel Antivirus pourra alors s’attaquer à ce fichier à l’aide de toutes les technologies de protection décrites ci-dessus.

Conclusion

Un kit d’exploitation est un système complexe utilisé pour s’introduire sur l’ordinateur d’une victime. Les individus malintentionnés déploient de nombreux efforts pour maintenir l’efficacité des kits d’exploitation et déjouer les détections. De leur côté, les éditeurs de logiciels antivirus perfectionnent sans cesse leurs systèmes de protection. Les éditeurs de logiciels antivirus disposent actuellement d’une panoplie de technologies en mesure de bloquer les attaques par téléchargement à la dérobée à toutes les étapes, notamment lorsque les codes d’exploitation invoquent les vulnérabilités.

Posts similaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *