Mais c’est quoi un rootkit ?

Malware, rootkit, trojan, virus, ver … Une multitude de noms et vocabulaire qui deviennent durs à assimiler. Dans ce billet, nous allons étudier un peu le concept du rootkit. Le nom “rootkit” est un nom anglais qu’il est possible de traduire en français par “Outil de dissimulation d’activité”. Ce qui est un peu moins classe mais plus parlant pour expliquer de quoi l’on parle.


Un terme né sous UNIX

Il faut savoir qu’à la base, le terme rootkit était exclusivement dédié à un ensemble d’outils qui permettait de gagner un accès administrateur (“root”) sur les machines UNIX, cet ensemble d’outils contenait par exemple des outils de supervision (ps, nestat, ls) modifiés afin de leur faire exécuter d’autres actions que celles d’origine. Un utilisateur non autorisé pouvait alors remplacer les outils de supervision par ceux modifiés afin de ne pas éveiller les soupçons du propriétaire du système. Le terme “rootkit” était alors à prendre au pied de la lettre, un “kit” permettant de devenir “root”, c’est à dire d’avoir les privilèges les plus élevés sur la machine.

Plus tard, le terme rootkit vint peu à peu s’intégrer aux systèmes Windows également et sa définition a également évolué. Cependant, la plupart des rootkits Windows ne permettent pas de gagner un accès administrateur et l’utilisateur doit avant leur exécution avoir autorisé l’exécution du programme infecté avec les droits administrateurs.

Le principe du Hooking

Le hooking est une méthode utilisée par les rootkit pour contourner le fils d’exécution d’un programme pour lui faire exécuter du code et des actions qu’il n’est pas censé exécuter dans sa conception d’origine. Le principe de l’API hooking (hook signifie “crochet”) est donc de contourner l’exécution d’une application afin de profiter de ses droits et son environnement pour effectuer d’autres actions, le tout à un moment bien précis et visé de cette exécution d’origine. On peut résumer ce fonctionnement, encore valable aujourd’hui comme suivant :

Lors d’une exécution et d’un appel de fonction normal :

Rootkit_1

fig1. Schéma d’exécution d’une fonction sans rootkit

Lors d’une exécution et d’un appel de fonction d’un poste ou d’une application infectée :

Rootkit_2

fgi2. Schéma d’exécution d’une fonction avec rootkit

Plus concrètement, on pratique l’API hooking lors de l’appel d’une fonction par le programme principal ou par une autre fonction. Au lieu de faire appelle à une fonction A, on modifie le programme pour qu’il appelle la fonction B que nous avons construit pour exécuter des actions autres ou alors on change le cours d’exécution de la fonction A pour qu’elle fasse d’autres actions que celles prévues.

La notion principale à comprendre lorsque l’on parle d’un rootkit est que cela ne définit pas forcément un logiciel particulier mais plutôt le fait de se dissimuler, lui même ou un ensemble d’objet ou d’application. Un rootkit s’apparente en effet plus à une technique et un principe de dissimulation afin de passer inaperçu qu’à un logiciel à part entière et donc la dissimulation est la fonction principale. Le principe de qualification d’un rootkit est que celui-ci est particulièrement difficile à détecter par les moyens conventionnels (de types antivirus …) et cela à cause de plusieurs facteurs que nous verrons par la suite.

Bien que la fonction principale d’un rootkit, comme tous les “malwares” est d’infecter un poste utilisateur, le rootkit va en général avoir pour seconde fonction de donner un accès distant à un pirate dans le but de prendre le contrôle à distance d’une ou plusieurs machines, de récupérer des informations sur ces postes, etc … Comme la plupart des malware ! Un “cheval de Troie” est d’ailleurs un “type” de rootkit et constitue une application qui semble légitime mais qui va exécuter des actions à l’insu de l’utilisateur au travers de l’application dans laquelle il se cache.

Quel intérêt pour l’attaquant ?

L’intérêt peut être variable pour le pirate (ou l’attaquant, cela dépend de ce qu’il fait de son malware). Généralement, le rootkit va infecter le PC puis se contenter de recevoir et d’exécuter les ordres du pirate à travers sa station que l’on qualifiera de “maître”. Par exemple dans le contexte d’une attaque DDOS, le pirate va donner l’ordre à tous les postes utilisateurs infectés via son rootkit d’aller établir des communications vers une seule et même cible.

Dans d’autres cas, le but peut être simplement l’espionnage d’un poste en particulier à travers la dissimulation de spyware, de keylogguers qui vont enregistrer les informations saisies au clavier, prendre des captures d’écrans pour les envoyer à son maître … L’intérêt et les possibilités sont aussi larges que celles de tout autre malware, le rootkit peut d’ailleurs n’avoir pour unique fonction que de cacher d’autres malware qui auront eux même leur propre rôle dans l’attaque. Dans tous les cas, le principe est de maintenir l’accès à la machine infectée pour pouvoir y revenir plus tard et à distance.

Le pirate pourra également, depuis une machine infectée se situant dans un réseau d’entreprise, se mettre à l’écoute du trafic réseau et alors récupérer des informations sur les échanges qui se font à l’intérieur du réseau en question depuis un accès distant que son rootkit lui aura mis en place :

Ecoute de réseau via un rootkit

Schéma d’une écoute de réseau via une machine infectée par un rootkit

Mode utilisateur et mode noyau

Les rootkits, depuis leur création, peuvent avoir deux modes de fonctionnement avec chacun leurs actions et leurs effets.

Mode utilisateur

Les schémas (fig1 et fig2) mis un peu plus haut sur l’article expliquent précisément le fonctionnement des rootkis dit en mode “utilisateur” qui agissent sur des couches de haut niveaux et utilisent les applications et leurs privilèges pour s’exécuter. Ils s’exécutent comme une application standard sur le système d’exploitation. Leur méthode de fonctionnement est alors d’aller essayer de contourner le déroulement d’exécution des autres applications, par exemple en modifiant le contenu de la mémoire qu’ils utilisent.

Mode noyau

Les rootkits en mode noyau sont eux beaucoup plus dangereux et également beaucoup plus discrets et durs à déceler car ils sont capables de corrompre le noyau du système d’exploitation intervenant ainsi dans des couches basses du traitement de données. Ils permettent au pirate de faire absolument tout sur la machine car il en contrôle la base. Il pourra alors non seulement détourner les applications de leur fonctionnement standard comme en mode utilisateur mais pourra également avoir un accès total au système d’exploitation afin d’en détourner les actions, tout en restant le plus discret possible.

Méthodes de dissimulation commune

Comme dit précédemment, les rootkits se caractérisent quasi exclusivement par le fait qu’ils ont une fonction principale et parfois uniquement de dissimulation de son propre code ou de celui d’autres programmes et codes malveillant. Nous allons ici brièvement voir comment les rootkits s’y prennent la plupart du temps pour déjouer l’analyse des antivirus et anti-malware.

Pour rappel, les antivirus ont une base de données d’empreinte des virus connus et qu’ils mettent à jour régulièrement avec les serveurs mondiaux. Lors d’une analyse antivirus ou de l’installation d’un nouveau programme, l’antivirus va construire l’empreinte du nouveau programme et la comparer à sa base de données, s’il trouve un hash identique, c’est que le programme en question a déjà été remonté plusieurs fois comme étant un virus ou un programme malveillant.

L’une des méthodes de dissimulation les plus efficaces et initialement utilisée sous les systèmes UNIX est celle illustrée par les figures 1 et 2 en haut de l’article. Le code malicieux va en effet se cacher dans une fonction d’une application ou même du système semblent bénigne et effectuera son code à son exécution puis effectuera un retour qui semblera normal aux yeux des utilisateurs.

Une seconde méthode qu’utilisent les rootkits pour se cacher des antivirus est la réécriture constante de leurs codes. En effet, leur capacité à modifier leur propre code permet de changer leur hash produit par les antivirus constamment et ainsi les faire passer pour des nouvelles applications qui n’ont pas été reportées par des experts en sécurité ou des utilisateurs.

Plus simplement, les rootkits se cachent aussi souvent de la vue des utilisateurs et administrateurs du système et cela par des techniques plus basiques comme le fait de cacher leurs processus des gestionnaires de processus ou des commandes monitoring, de cacher leurs clés de registre (sous Windows) et leurs fichiers d’exécution, cet ensemble de pratique les rendent quasiment invisible par l’utilisateur qui met donc du temps à déceler un problème

Suppression et détection

Étant donné que le rôle principal d’un rootkit est la dissimulation, leur détection et donc leur suppression peuvent être assez ardues, il existe des “kit anti-rookit” qui sont spécialisés dans la détection de ce genre  de malware. Comme expliqué précédemment, la méthode de détection la plus utilisée est l’analyse de l’empreinte des différentes applications de la machine analysée, des utilitaires plus avancés auront également ce qu’on appelle une “analyse comportementale” qui est donc le fait d’analyser un comportement connu d’une application et de voir si celui-ci est retrouvé. On cherchera par exemple à savoir si le code d’une application change régulièrement pour détecter un rootkit qui se réécrit tout seul.

Comme utilitaire pour détecter et supprimer des rootkits, on peut citer le très connus TDSSKiller, développé par Kaspersky et spécialisé dans la détection des rootkit de type Rootkit.Win32.TDSS (comme Tidserv ou Alureon), aucune installation n’est requise et l’outil permet également de générer des rapports.

Sous Linux, il existe également la commande chkrootkit qui vérifie plusieurs éléments :

  • Si la carte réseau est en mode “promiscious”, ce qui pourrait avertir l’utilisateur sur le fait qu’un rootkit est présent sur son PC et procède à des écoutes réseau comme illustré dans notre figure 3.
  • Que les commandes UNIX basiques (comme ls, echo, netstat) n’ont pas été modifiée depuis l’installation de la machine, ce qui pourrait mettre en avant une commande infectée par un rootkit (de type Cheval de Troie par exemple).
  • Si des vers sont présents dans des modules du kernel installé (LKM – Loadable Module Kernel), ce qui mettrait en avant un rootkit fonctionnant à peu près comme un cheval de Troie sur une commande.

Rootkit connus

Pour avoir quelques exemples, nous allons étudier le fonctionnement de quelques rootkits connus. Les rootkits dont on a le plus entendu parlé récemment sont bien entendu Flame, Zeus et Stuxnet (ce dernier étant le premier à s’attaquer à des systèmes SCADA). Bien qu’ils ne soient pas uniquement des rootkits car leur actions malveillantes concernent également d’autres domaines du vocabulaire des virus, ils sont qualifiés de rootkit car une partie de leur fonction consiste à se cacher et à passer inaperçu auprès de l’utilisateur et des systèmes de sécurité. On parlera donc plus généralement de “Virus” lorsqu’on lira des articles à propos de ces malware, ce qui n’est pas forcément un fausse appellation.

 

Il existe des sites web qui répertorient tous les rootkits détectés à ce jour comme celui-ci : Liste des rootkits sur bleepingcomputer

 

You may also like...

3 Responses

  1. neuronyk says:

    bonjours et merci de tous ces partages ! apres avoir essayé un chkrootkit j’ai ceci :
    Checking `sniffer’… lo: not promisc and no packet sniffer sockets
    wlan0: PACKET SNIFFER(/sbin/wpa_supplicant[5155], /sbin/wpa_supplicant[5155], /sbin/dhclient[5305])
    aurai-je un rootkit sur ma wlan ?

  2. neuronyk says:

    bon, il semblerai que non car WPA_supplicant a besoins d’un mode promicuitous et cela alerte chkrootkit, j’ai lu egalement qu’il était conseillé de faire un hash de ses fichiers pour verifier qu’ils n’aient pas étés infectés entre deux analyses.
    des conseils a ce propos ?

  3. Fatiha says:

    Article très intéressant et surtout très clair. Juste une précision, je ne mettrai pas ls dans les outils de supervision Linux. Mais bon peut-être que je me trompe.

Leave a Reply

Your email address will not be published. Required fields are marked *