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?
Citation:
"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. Fréquence d'utilisation des technologies rootkit dans les logiciels malfaisants.)
Citation:
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. 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. Liste des tâches avant installation du 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.
(Fig. 4. Liste des tâches après installation rootkit.)
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.
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 des logiciels qui sont en test beta au sein du Laboratoire Kaspersky.
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.
Un sous-système identique officie pour la [b]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:
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 (porte ouverte) 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....
![[MàJ] Vulnérabilité dans Zimbra Collaboration Suite (17 juillet 2023)](https://images.unsplash.com/photo-1618005182384-a83a8bd57fbe?auto=format&fit=crop&w=800&q=80)
