0
Ce sujet est fermé
« News » de présentation du sujet -> Rootkit Unhooker 3.8
CITATION(DiabloNova @ traduction libre)
Rootkit Unhooker 3.8 ... C'est le Passé, le Présent et le Futur de la détection des rootkits Ntx86.
Traduction libre et partielle de la présentation faite par « DiabloNova » sur rootkit.com
« Il fallait d'abord répondre à l'existence ou la révélation récente de nouvelles techniques de rootkit implémentées par exemple dans "Rustock.C".
Longtemps, Kaspersky Labs a nié son existence . Après sa découverte par son rival DrWeb, il a bien entendu entamé une campagne médiocre, stupide, impuissante contre tous ceux qui ne s'alignaient pas sur sa passive position « proactive ». Il est connu que de nombreux crochets effectués par Rustock.C protègent ce rootkit contre sa détection et son éradication par les logiciels antivirus. Nous ne voulons plus parler de "Rustock" car c'est un thème évidemment mort. Trop d'argent des antivirus est en jeu et trop de merdes ont déjà été dites.
Il va de soi que nous ne pouvons pas faire un copier/coller de toutes les méthodes de détection des rootkits depuis la version VX de RkU vers la LE. Aussi, nous avons développé une nouvelle variante de détection basée sur la mise en évidence et la suppression des crochetages effectués par les rootkits.
La nouvelle version 3.8 LE ne détecte pas tous ces crochetages car il nous aurait fallu faire un trop important copier/coller du code de la version VX, ce que nous ne voulons pas du tout. Notre nouvelle cible est le "bootkit". Oui, c'est un assez ancien rootkit, déjà très connu, mais nous avons voulu ajouter quelque chose à sa détection, pas seulement un copier/coller comme le font certains antivirus ou ARKs (BlackLight, GMER (aswar) par exemple). L'idée pour détecter un "bootkit" n'est pas nouvelle, c'est un contrôle croisé des principaux secteurs de l'enregistrement de démarrage (généralement le 0) pour trouver les inadéquations entre deux scans différents. Le premier est effectué en « High Level API » et l'autre en lisant le disque à bas niveau. La plupart des ARKs utilisent pour ceci le "handler" original « ClassReadWrite » situé dans « classpnp.sys ». Nous trouvions cette méthode bonne mais elle n'est pas sûre car il existe plusieurs moyens de la contourner. Nous avons décidé de faire une petite expérience, et, comme nous ne pouvions rien utiliser des anciennes versions VX, nous avons décidé de créer une nouvelle méthode de détection. Nous avons choisi le « SCSI », actuellement le « SCSI_REQUEST_BLOCK ». Il est très bien documenté, mais pas très simple et pas très indépendant du matériel. Cependant, il fonctionne, tout au moins dans nos tests. L'éradication des "bootkits" aussi est basée sur la même méthode. Nous doutons de l'avenir des "bootkits" car ce qu'il faut chercher et où le trouver est bien connu et il importe peu que le "bootkit" change ou non la séquence de démarrage du BIOS.
Puis, nous avons vraiment commencé l'attaque des rootkits avec des méthodes ARK. Oui, ce genre de bébête existe et il y a de nouveaux flux dans le développement des rootkits. Parce qu'ils semblent incapables de contourner les ARKs, les concepteurs/codeurs de rootkits malveillants, dans leur manque total de professionnalisme et leur amour pour l'argent facile, ont commencé à attaquer les ARKs avec leurs produits merdiques. Ex : des filtres "FSD" qui empêchent les opérations "raw disk" des ARKs avec des crochets qui n'ont de sens que pour faire obstacle à leur bon fonctionnement. Dernièrement, nous avons vu les dangereuses méthodes d'un rootkit nommé « Siberia2 » qui endommage la « Object Directory » pour prévenir la détection des ARKS. Le côté amusant de ce rootkit est qu'il n'a rien d'intéressant à part sa défense agressive. D'autre rootkits disposant de cette technique viendront rapidement, nous n'en doutons pas.
Ensuite, il était nécessaire d'apporter une réponse à plusieurs nouveaux "POC" intéressants de l'année dernière. Cependant nous n'avons trouvé rien de remarquable (comme le « raw filtering ») dans plusieurs d'entre eux. Il n'y a pas eu de bonne réalisation pour le camouflage des secteurs du disque, seulement des générations de "BSoD" comme concept de mort. Il est très probable que ce type de technologie existe ailleurs puisque nous avons les mêmes pour des rootkits privés, de démonstration, non malicieux. Par conséquent, nous ne pouvons et ne voulons pas lutter avec des ombres dépourvues de sens.
Nous avons trouvé un moyen simple et efficace pour détecter les "processus" cachés dans les systèmes Windows 2003/Vista/2008. Rien de vraiment nouveau puisque Klister (ndlr : de Johanna Rutkowska) fournit depuis longtemps une analyse des « scheduler lists ». Mais depuis la version 2003, et le nouveau cœur de NT, aucun détecteur de rootkit avec les fonctionnalités de Klister n'a été développé. Le « scheduler » a été changé avec 2003 et il est appliqué à Vista et 2008.
Les « scheduler lists » sont maintenant accessibles depuis la « Processor Control Region » (KPCR) où le « scheduler » les traite à travers les zones spéciales des structures « PCRB » (Process Control Block) des processeurs.
Nous continuons le développement des deux versions LE et VX car, même si les sources de VX ont été vendues l'année dernière, les droits sur ce code nous appartiennent toujours. De nouvelles techniques seront implantées pour améliorer leur facilité d'utilisation, leur stabilité et leurs méthodes de détection/éradication. »
Les mots entre " " ont une explication dans le lexique du Windows furtif.
.../...
