Parfois les questions sont plus importantes que les réponses...

Les images de mémoire physique, recueillies auprès de systèmes MS Windows compromis, constituent une source de renseignement importante sur les dernières générations de codes malveillants qui visent ces systèmes d'exploitation.

Cependant, en raison de sa complexité structurelle et de la volonté de Microsoft de rendre inaccessible la connaissance du coeur de ses systèmes d'exploitation, l'analyse d'une telle image est actuellement une tâche trop rédhibitoire pour être complètement intégrée dans une procédure IR où chaque minute est comptée.

Ma première question est la suivante :

La mise au point d'un outil d'analyse de la mémoire physique des systèmes Windows est-il un objectif valable pour reprendre l'initiative face aux nouvelles armes dont disposent nos adversaires ?

Se retrancher derrière les procédures forensiques traditionnelles, qui mettent de côté le recueil de la mémoire physique, jugée trop intrusive, n'est pas une solution satisfaisante. Mais, avant de sauter le pas, il nous faut encore obtenir un outil performant et opérationnel qui nous permette de reprendre l'avantage tactique face à des adversaires disposant d'outils offensifs anti-forensiques, comme le meterpreter de la plate-forme Metasploit ou encore les plates-formes d'industrialisation de génération de rootkits.

Développer un outil from scratch pour l'analyse d'images de la mémoire physique de systèmes MS Windows peut devenir rapidement un véritable cauchemar, en raison de l'instabilité de la structure interne du noyau Windows NT. Cette instabilité se situent principalement au niveau des signatures d'objet et des offsets correspondants. Ceux-ci sont complètement différents selon la version du système d'exploitation Windows NT (NT 4.0, Windows 2000, Windows XP, Windows 2003, sans parler de Vista et Windows Server "Longhorn"), selon l'architecture du système et au sein même d'une version selon le service pack et la présence de certains hotfix.

Ma deuxième question est la suivante :

Vaut-il mieux développer un outil d'analyse complet, mais difficile à maintenir, ou alors s'appuyer sur les symbols fournis en ligne par le serveur dédié de Microsoft et sur l'analyseur d'espace mémoire du débogueur noyau Windows ?

Les outils s'appuyant sur les symbols et le débogueur noyau sont par construction limités à l'analyse d'une image générée à partir d'un crash dump (.dmp), alors que les premières procédures IR concernant le recueil de la mémoire physique s'appuient sur l'outil dd.

L'analyseur du débogueur noyau ne peut travailler qu'à partir d'un crash dump. Une telle image se différencie d'une image générée par dd par des informations supplémentaires sur l'état du CPU au moment de la photographie. D'où l'idée consistant à rajouter ces informations à une image de type dd pour la transformer en en image de type dmp.

Ma dernière question est la suivante :

La transformation d'une image dd en crash dump (.dmp) est-elle réaliste ?

Retour sur la routine KeBugCheckEx

Suite à la réponse d'Andréas Schuster à ma question sur la possibilité d'obtenir un crash dump sans préparation, j'ai essayé de me documenter sur cette fameuse routine KeBugcheckEx. Voila les informations que j'ai pu rassemblées, n'étant pas du tout un développeur de drivers en mode noyau...

Windows divise la mémoire physique en séries de pages de taille 4KB sur les architecture x86, bien que cette taille puisse être modifiée par la constante PAGE_SIZE. Windows divise également l'espace d'adressage virtuel en pages de taille équivalente.

Une erreur de pagination survient lorsqu'un driver en mode noyau rapporte au système que ce dernier n'est pas autorisé à accéder à la page demandée ou qu'il ne peut pas traduire une page virtuelle en page physique. Ce compte rendu d'erreur du driver est réalisé au travers la routine noyau KeBugcheckEx. A priori, cette erreur est exclusivement causée par une malfonction du driver dans la pile de stockage.

Pour obtenir le fameux BSOD (Blue Screen Of Death) à l'aide de cette routine, il suffit donc de réaliser un driver en mode noyau qui réalise une opération illégale, du genre lecture d'une adresse mémoire interdite (cela doit être possible à l'aide d'un pointeur NULL...). Mais, pour générer un crash dump complet de la mémoire physique, il faut avoir préparé le système pour cela. Par défaut, seules les pages mémoires de l'objet ayant entrainé l'écran bleu seront copiées dans le fichier MEMORY.DMP.

Pour revenir au crash dump généré par la routine noyau KeBugcheckEx, il s'agit d'une simple copie du contenu de la mémoire physique poussée dans un fichier du disque dur. On a vu que cette copie est réalisée par KeBugcheckEx après une exception fatale d'un driver en mode noyau. Mais, j'ai observé que KeBugcheckEx n'écrit pas immédiatement le contenu de la mémoire dans le fichier cible. Ceci est peut-être dû au fait que le système n'est alors pas vraiment en mesure de réaliser cette copie !

Au lieu de cela, l'image est copiée dans le fichier de stockage de pagination qui fait partie du gestionnaire système de la mémoire. L'une des conséquences de ce mécanisme de copie est que pour réaliser un bon crash dump et ne pas perdre les informations concernant la moitié des processus en fonctionnement, il faut disposer d'un fichier de pagination de taille au moins double à celle de la mémoire physique. En effet, pour réaliser une copie sur le disque dur, le système va devoir utiliser de la mémoire virtuelle d'une taille équivalente.

Au final, au travers la lecture de la documentation cryptique de msdn, j'ai eu l'étrange impression que Microsoft désirait rendre extrêmement difficile la connaissance de ses noyaux. Ce qui n'a fait qu'exacerber ma curiosité !

Livraison en cinquante minutes chrono...

Un petit texte d'ambiance, pour nous changer de la technique pure...

Bien que le combat en milieu urbain l'ai mis au rencard au profit du trinôme, mon opinion est que le binôme constitue la structure de base la plus efficace pour une équipe IR :
- un opérateur IR aux manettes : interlocuteur unique de l'administrateur distant en première ligne (souvent, le premier intervenant sur l'incident)
- un opérateur IR : tenant le cahier de bord et veillant au respect de la procédure

Ce binôme IR est composé, de préférence, du grand classique Mentor/Scarabé. Cette configuration permet d'éviter les éternels conflits de générations (ou de diviser pour régner selon les points de vue) et surtout de former en un rien de temps les nouveaux venus.

Voila pour la mise en situation...

L'objectif de toute investigation IR sur un évènement suspect consiste à déterminer si un incident sécurité informatique est survenu et - dans l'affirmative - comment il s'est produit. Un binôme d'opérateurs IR a cinquante minutes pour bâtir une hypothèse plausible et dix minutes pour la présenter au coordinateur de l'équipe IR. Ce dernier devra alors l'expliquer, en termes non-techniques, au responsable du système suspect (cas classique) ou au responsable de la cellule conduite (crise ou incident majeur).

Cinquante minutes peuvent être terriblement courtes, surtout avec un administrateur qui en passe quinze à trouver les clés de la baie technique... Le meilleur allié de l'équipe IR reste un simple cédérom d'investigation. Ce dernier peut contenir la distribution HELIX ou une petite compilation d'outils maison. Il doit bien sûr être détenu par l'administrateur du système suspecté ; sinon, nous avons encore perdu de précieuses minutes pour monter une autre manip' ! (vive la planification)

La quasi-majorité des systèmes d'extrémité actuels (serveurs et stations de travail) possèdent un lecteur de cédérom ou compatible. Ce qui n'est d'ailleurs plus le cas du lecteur de disquette. Parce qu'un cédérom ne peut pas être réécrit une fois gravé, il est théoriquement invulnérable à la corruption des codes malveillants (certains diront que les drivers ne le sont pas...).

Il reste au binôme IR à récupérer les données collectées : le réseau - via ce vieux netcat ou son petit frère cryptcat - reste le meilleur moyen, mais d'autres options doivent être planifiées.

Un fois le dispositif en place, le binôme IR doit s'assurer de collecter ou faire collecter assez d'informations pour déterminer si l'évènement rapporté est un incident sécurité informatique (et non une simple panne ou un bogue logiciel). Il doit collecter autant d'informations volatiles que possible sur le système suspect, en s'efforçant de ne pas piétiner l'éventuelle scène du crime. Le choix des outils d'investigation est alors primordial.

En comptant une moyenne de vingt minutes pour les préparatifs et un minimum de vingt minutes pour l'analyse, cela laisse moins de dix minutes pour réaliser la collecte ! Selon les informations déjà à disposition, l'OS et surtout la fonction du système suspecté, plusieurs options techniques s'offrent au binôme IR (de la plus lente à la plus rapide) :
- dialogue interactif avec l'administrateur qui exécute un certain nombre d'outils de recueil dont les résultats sont analysés à la volée par le binôme IR (choix préféré des opérateurs confirmés)
- récupération de la totalité de la mémoire physique du système
- lancement d'un script de recueil regroupant le résultat de plusieurs outils de collecte

Outre le temps qui reste au binôme pour fournir son diagnostique, l'autre facteur à prendre en compte est le principe d'échange d'Edmond Locard Ce principe fondateur des sciences forensiques stipule (de mémoire) : "lorsque deux objets viennent en contact, un transfert matériel a lieu entre eux." Ce principe peut également s'appliquer au monde numérique : "Lorsqu'un système se connecte à un autre via le réseau, il s'opère un échange d'informations entre eux".

Les rootkits et les intrus expérimentés s'évertuent toujours à effacer ce type d'informations. L'expérience d'un intrus tient d'ailleurs d'avantage à cet effacement qu'au choix de la méthode d'intrusion utilisée (on voit toujours les mêmes choses, mais ceci est une autre histoire...). Quant aux rootkits noyau, il faut développer pour chacun d'entre eux une méthode de détection spécifique, bien que je pense tester bientôt les outils de Joanna Rutkowska.

L'objectif de la collecte consiste à recueillir ce qui reste de ces informations à l'aide d'un large panel d'outils. Dans ce domaine, si un simple netstat est comparable à la vérification du registre d'un hôtel borgne, l'analyse de la mémoire physique peut, quant à elle, être comparée à l'analyse ADN de l'ensemble des fragments organiques trouvés sur la scène du crime.

Et voila, je suis revenu à la technique pure...