24
Août 05

Les fonctionnalités des rootkit et comment les contrer

24 août 2005 | Non classé

Les auteurs de virus ont toujours fait face à  un sempiternel problême : comment conserver la présence des codes malicieux le plus longtemps possible à  l’insu des utilisateurs et des solutions antivirus? Cette question est d’autant plus actuelle que ces derniers temps, l’écriture de programmes malfaisants n’est plus tellement une affaire de développement personnel mais de business. Effacer ces traces est donc le thême en vogue pour les pirates hommes d’affaires. Par quels moyens peut-on cacher un programme voleur de données bancaires ou encore un serveur proxy illégal destiné à  la diffusion de spams depuis l’ordinateur d’une victime?

Les cyber escrocs d’aujourd’hui rêglent ce problême de la méme façon que les réglaient les cyber hooligans il y a 10-15 ans. Un des premiers virus connus pour PC se nommait (Virus.Boot.Brain.a) – un virus du secteur de boot qui s’octroyait les fonctions d’accês au disque et lors de la lecture du secteur de démarrage (par exemple du programme antivirus), substituait les données originales par des données infectées. Avec le temps, ces mémes mécanismes furtifs (l’interception des fonctions systême et substitution des données) ont continué d’étre utilisés dans les virus Windows (Virus.Win32.Cabanas.a).

Dans le monde Unix, les programmes malicieux n’ont pas encore été diffusés à  une aussi large échelle que dans DOS et Windows, c’est pourtant de là  que vient le terme rootkit, terme qui est désormais utilisé en référence aux technologies furtives utilisées par les auteurs de Trojans sous Windows.

Le terme rootkit désigne une série de programmes qui permettent au pirate de s’installer sur une machine et d’empécher sa détection. Pour se faire, les fichiers exécutables (login, ps, ls, netstat etc.) ou bien les bibliothêques (libproc.a) sont modifiés, ou encore, un module noyau est installé. Dans tous les cas, le but est d’empécher que l’utilisateur ne reçoive des informations indiquant la présence d’activités nuisibles sur son ordinateur.

Ces derniers temps, l’utilisation des technologies de rootkit pour masquer la présence de logiciels malfaisants est de plus en plus populaire comme le montre le graphique ci-dessous (fig 1):


Fig 1. Fréquence d’utilisation des technologies rootkit dans les logiciels malfaisants.

Notons bien que la popularité des rootkit est liée à  la libre diffusion sur le réseau Internet de textes sources de nombreux rootkit et, y apporter des changements n’est pas une tache três compliquée pour les auteurs de logiciels malicieux. La croissance des rootkit est également favorisée par le fait que la majorité des utilisateurs de systême d’exploitation Windows travaille sous les droits d’un administrateur, ce qui facilite grandement l’installation de rootkit dans les ordinateurs.

Les auteurs de virus ainsi que les développeurs de spyware « légaux » font l’éloge de ces programmes du fait qu’ils sont invisibles pour l’utilisateur et impossibles à  détecter par les solutions antivirus.

Voyons de plus prês la situation sous Windows et sous Unix.

Technologie de Rootkit sous Windows
Masquage de présence dans le systême

A l’heure actuelle, on peut diviser en deux sections les méthodes utilisées par les rootkit pour cacher leur présence dans le systême:

  1. modifications du chemin des programmes exécutables;
  2. modification des structures du systême .

Ces méthodes sont utilisées pour masquer l’activité dans le réseau, les clés de registre, différents processus c’est-à -dire tous les éléments qui permettent à  l’utilisateur, dans une certaine mesure, d’identifier un programme malveillant sur son ordinateur.

La premiêre méthode pour masquer l’information peut étre réalisée aussi bien sous le mode utilisateur que sous le mode noyau. Sous mode utilisateur c’est relativement simple. Le plus souvent, une méthode basée sur l’interception de fonctions API est mise en oeuvre pour modifier le chemin d’accês vers ces exécutables (fig 2):


Fig. 2. Interception des requétes vers les fonctions API.

Cette méthode exploite le fait que les fonctions API sont sollicitées par des applications qui soit utilisent des champs de données spéciaux (tableaux d’import/export), soit qui contactent une adresse reçue par la fonction GetProcAddress API. Le code du programme s’installe dans les modules DLL, qui par la suite s’introduisent dans l’espace d’adresses existantes dans le gestionnaire des tà¢ches, ce qui donne au malfaiteur la possibilité de contrà´ler toutes les applications de l’utilisateur. Le procédé des modifications des chemins d’accês aux exécutables est bien documenté et facile à  installer, favorisant l’utilisation de telles technologies par les rootkit.

Cependant, les réalisations de rootkit en mode utilisateur ont un gros défaut, à  savoir le faible niveau de masquage de l’information. En d’autres termes, la présence dans le systême en mode utilisateur peut étre détectée sans difficultés à  l’aide d’utilitaires spécifiques. En conséquence de quoi, on constate une hausse d’intérét majeure envers les rootkit en mode noyau, méme si ces derniers sont beaucoup plus complexes à  développer.

Penchons-nous sur les méthodes en mode noyau, ces derniêres se caractérisant par un bien meilleur camouflage de l’information. Une forte majorité de rootkit en mode noyau utilise des structures de systême d’exploitation non documentées. Par exemple, l’interception de services de KeServiceDescriptorTable est três largement utilisée, et la quantité de services dans ce tableau peut varier d’une version de systême d’exploitation à  une autre. Cela oblige les développeurs de rootkit à  effectuer rapidement une analyse supplémentaire du code du systême d’exploitation pour déterminer les indicateurs du tableau susmentionné. Cette approche, dans son principe, n’est pas sans rappeler l’interception des fonctions API.

La méthode de modifications de la liste systême PsActiveProcessList est un exemple des modifications des structures du systême. Cette méthode est utilisée par le rootkit FU qui permet de cacher tout processus de la majorité des utilitaires systêmes (fig. 3,4).

http://www.viruslist.com/fr/imagesfr/vlpub/0507_rkits_pict3.png

Fig. 4. Liste des tà¢ches aprês installation rootkit.

Sur l’illustration 3, le rédacteur de texte Notepad est visible dans la liste des tà¢ches en cours sous le nom de notepad.exe (le nom est surligné en rouge). La capture d’écran réalisée sur l’illustration 4 a été effectuée aprês le lancement de rootkit FU, ce dernier ayant pour mission de cacher la tà¢che. Sur le dessin, il est nettement visible que, alors que le rédacteur est démarré, son nom a disparu de la liste des tà¢ches actives (indiqué à  l’aide de la flêche rouge). Détection des rootkit

La premiêre étape à  franchir pour combattre les rookit est de les détecter. Cette situation est réelle si l’on considêre la constante apparition de nouvelles technologies, et que les développeurs de technologies antivirus ont besoin de temps pour analyser et développer des moyens de détection. Cependant, malgré l’apparente difficulté de détecter les rootkit, des méthodes efficaces sont déjà  développées et éditées dans la version 6.0 de nos logiciels qui sont en test beta au sein de notre laboratoire. Etudions la réaction de notre logiciel sur l’apparition de rootkit FU dans un systême.

L’installation d’un rootkit dans un systême signifie le camouflage d’une tà¢che en cours. Le sous-systême anti-rootkit détecte cette action et envoie à  l’utilisateur les notifications correspondantes (voir figure 5):


Fig.5. Détection de tà¢ches cachées et inconnues.

Ce sous-systême permet de déterminer la présence non seulement des rootkit ajoutés dans la base antivirus sur la machine d’un internaute, mais également ceux qui sont encore inconnus, comme le montre l’illustration 5.

Un sous-systême identique officie pour la détection de rootkit en mode utilisateur, rootkit qui ont été analysés au début de notre étude et qui injectent des DLL à  d’autres procédés.

Dans ce cas-là , le sous-systême de protection notifie à  l’utilisateur qu’un procédé spécifique est en train d’infiltrer un code dans un espace d’adresses étranger (voir figure 6):


Fig.6 Détection d’infiltration de code dans une espace d’adresses étranger.

Rootkit – technologie pour Unix
Masquage de présence dans le systême

La situation dans Unix rappelle fortement celle de Windows. L’attaquant installe le rootkit sur l’ordinateur une fois qu’il a obtenu les accês privilêges (accês root). Les accês root, indispensables pour installer la majorité des rootkit, sont accessibles via des vulnérabilités bien connues si le malfaiteur a accês au systême avec les mémes droits qu’un utilisateur ordinaire. Dans ce cas-là , il peut utiliser un exploit local ou un utilitaire pour forcer les bases protégées par mots de passe. Si le malfaiteur ne dispose pas des droits nécessaires pour s’infiltrer dans le systême, alors il peut utiliser un exploit à  distance ou, par exemple, un sniffeur de claviers pour obtenir les mots de passe. L’interception de mots de passe peut étre utilisée pour de nombreux services (ftp, telnet etc.) du fait que ces derniers transmettent les mots de passe sur le réseau non crypté.

En fonction de ces capacités, le rootkit peut contenir divers programmes malicieux trojan-DDoS, backdoor et autres qui s’installent sur la machine compromise, et attendent de la part de l’attaquant un ordre à  exécuter. De plus, les rootkit peuvent contenir un patch qui colmate la brêche dans le systême afin d’éviter l’infiltration d’un attaquant tiers.

Tout comme dans Windows, Unix fait face à  des rootkit aussi bien au niveau des applications qu’au niveau du noyau.

Voyons les rootkits en mode utilisateur. En général, les rootkit se composent de versions de programmes ordinaires ‘infecté par trojan’ masquant la présence de ses composants dans le systême, et de backdoor assurant un passage secret dans le systême. Comme exemple de rootkit en mode utilisateur, on trouve lkr, trOn, ark et autres.

Prenons tr0n comme exemple de rootkit en mode utilisateur. Pour cacher sa présence dans le systême, ce rootkit exécute une série d’actions. Au moment de son installation, il stoppe syslogd-demon, puis remplace par ses Trojans les utilitaires de systêmes suivants: du, find, ifconfig, login, ls, netstat, ps, top, sz. De plus, une version Trojan de syslogd-demon est rajoutée dans le systême. Enfin, un sniffeur est demarré en tà¢che de fond, le lancement des daemons telnetd, rsh, finger est rajouté dans inetd.conf, inetd est redémarré et syslogd est démarré à  nouveau.

D’ordinaire, tr0n se situe dans /usr/src/.puta mais grà¢ce au composant ls déjà  installé, le catalogue est invisible.

Voyons maintenant le rootkit au niveau du noyau. Les rootkit de ce type possêdent toutes les caractéristiques du type décrit précédemment, mais à  un niveau plus bas. Les rootkit en mode utilisateur doivent modifier chaque fichier binaire alors que les rootkit en mode noyau doivent modifier uniquement le noyau, ce qui augmente considérablement la « qualité » de camouflage de l’information.

Il existe plusieurs moyens d’introduire des rootkit dans le systême noyau:

  1. l’utilisation de LKM, le noyau Linux (comme dans beaucoup d’autres systêmes d’exploitation) permet de télécharger des modules (ou des pilotes systêmes ) â€œà  la voléeâ€?, ce qui permet au malfaiteur de modifier les requétes systême du noyau, et de donner des informations erronées (par exemple une liste rectifiée de fichiers). Il est possible d’empécher de telles attaques en recompilant le noyau systême sans le LKM, mais cette méthode présente un défaut – il est indispensable d’inclure tous les pilotes nécessaires dans le noyau;
  2. une entrée dans /dev/kmem qui accorde l’accês dans la zone mémoire occupée par le noyau. L’entrée réécrit le noyau ‘à  la volée’. De cette façon, pour modifier le noyau, il faut simplement trouver une place en mémoire, mais ce n’est pas un problême insoluble. Certaines modifications peuvent étre faites, interdisant d’écrire directement dans /dev/kmem. Cela est réalisable par mmap;
  3. l’infection de modules existants; se distingue de la premiêre méthode du fait que le rootkit ne contient pas de module à  part et utilise l’infiltration dans les modules existants. L’adoption d’une telle méthode permet de faire le rootkit stable lors du redémarrage, en infectant quelques modules qui seront téléchargés de toute façon (par exemple, le driver du systême fichiers).

La détection de Rootkit

Pour détecter des rootkit, il n’y a malheureusement pas de solutions miracles, mais les conseils exposés ci-dessous permettent de détecter la majorité des rootkit actuels:

  1. l’observation d’un comportement anormal des fichiers, utilisation des ressources du réseau, démarrage de tà¢ches selon un horaire défini et au moment du démarrage, gestion des comptes utilisateurs;
  2. l’utilisation des utilitaires suivants, qui aident à  mettre en évidence la présence de rootkit dans le systême: Saint Jude, Chrootkit, RkScan, Carbonite, Kstat, Rootkithunter, Tripware, Samhain etc.

Conclusion

Toutes les méthodes examinées pour détecter des rootkit actifs dans Windows exploitent le fait qu’ils perturbent le systême d’une maniêre ou d’une autre. Notre logiciel utilise ce facteur pour détecter les rootkit inconnus. Dans les derniêres versions de Windows, la tà¢che des développeurs de rootkit sera d’autant plus ardue que les derniêres versions de Windows interdisent d’apporter des changements dans le systême code et les structures systêmes. Cette disposition va permettre pendant un temps au moins, de freiner la croissance des nouveaux rootkit pour les nouvelles versions de ce systême d’exploitation.

Le fait qu’il y ait plus de logiciels malicieux pour Windows que pour Unix est le résultat de la diffusion plus importante de Windows. En cas d’élévation de la cà´te de popularité de Unix, la situation changera au fur et à  mesure, de nouveaux rootkit pour Unix apparaitront mais également de nouveaux moyens de lutte contre eux.

En conclusion, retenons simplement que la protection la plus efficace contre les rootkit est la prévention.


Les commentaires sont fermés.