Quelques questions en l'air sur le live forensique...

Quelqu'un a-t-il déjà essayé de faire un reverse de i802ptr.sys ?

Le truc serait de voir la tête de l'appel système qui entraine le reboot dans la procédure nommée par les frenchies : Crash_dump_avec_tes_doigts et par nos amis étatzuniens : Crsh_On_Ctrl_Scroll. Le rêve serait d'obtenir un outil pour lancer le processus sans avoir à ajouter une clé au registre et redémarrer la machine (impossible à faire dans la réponse à un incident).

Quelqu'un a-t-il une solution pour ne pas avoir à digérer l'un des pavés de Russinovich & Solomon pour comprendre la structure interne de la mémoire physique des systèmes MS Windows ?

Il faut vraiment en vouloir pour déchiffrer des hiéroglyphes d'un autre âge pour découvrir les adresses virtuelles des blocs _EPROCESS.

Quelqu'un connaît-il la sortie de FATKit de l'équipe de 4tphi.net et de KnTList de George Garner ?

FATKit a vraiment l'air sympa sur le papier (bien qu'un peu scolaire...) tandis que KnTList promet de résoudre les problèmes de restriction sur la mémoire physique en mode utilisateur avec les derniers MS Windows de sortie.

Voila. C'est dit !

Le cauchemard du svchost.exe résolu par l'exécutable tlist du débogueur !

Lorsqu'un administrateur système appelle notre équipe IR pour rendre compte du comportement suspect d'une machine MS Windows, nous réalisons avec lui l'étape Réponse Initiale de notre procédure de réponse aux incidents.

En quelques mots, cette étape consiste à faire recueillir par l'administrateur les premiers éléments de preuve sur la machine suspecte toujours en fonctionnement. Lors de ce recueil, les administrateurs nous ont souvent fait part de leur inquiétude vis à vis des processus visibles dans le Gestionnaire des Tâches Windows, notamment, sur le nombre inquiétant d'instances du processus svchost.exe.

En effet, plusieurs codes malveillants - dont les chevaux de Troie toujours actifs : Agobot et Backdoor.XTS - adorent se camoufler sous ce nom de fichier. Le fait est que les systèmes MS Windows possèdent toujours un certain nombre de ces processus. J'en ai compté deux sur un système WIN2K, six dans un WINXP et même sept dans un WIN2K3 !

En parcourant la prose de Microsoft rapidement, on peut lire que svchost peut être considéré comme un super processus générique qui lance des services à partir de librairies liées de manière dynamique (DLL). Chaque instance de svchost fait donc tourner un ou plusieurs services. Il nous reste à pouvoir examiner ces services !

Lorsqu'il est lancé, svchost lit la clé de registre suivante pour lancer les groupes de services qu'il doit lancer (une ligne par groupe):
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Svchost

Sur un système vivant (c'est le cas dans l'étape Réponse Initiale), on peut afficher ces services à l'aide de la commande :
- tlist -s
Il ne s'agit pas de l'exécutable tlist.exe fourni avec les Ressources Kits, mais de celui fourni avec les débogueurs Noyau Microsoft. Nous avons tout d'abord rajouté cet exécutable dans un répertoire nommé add On à la racine du cédérom HELIX. Les fichiers contenus dans un tel répertoire sont alors visibles par les deux parties d'HELIX (Linux et Windows).

Par la suite, les exécutables intéressants du débogueur Noyau Microsoft, dont tlist, ont été intégrés nativement dans HELIX (de mémoire, dans le répertoire /IR/windbg/). Ce cédérom est à la base de notre procédure de Réponse Initiale...

Pour détecter rapidement les instances suspectes de svchost, nous utilisons le même exécutable tlist.exe du débogueur Microsoft. Normalement, svchost.exe doit être lancé par le processus services.exe. Pour afficher l'arbre d'affiliation des processus en cours, on utilise le drapeau -t de tlist comme dans l'exemple suivant :
Une instance suspecte de svchost.exe aura généralement pour père le processus cmd.exe.

Le plus sympa avec tlist.exe est que son drapeau -c permet d'afficher la ligne de commande qui a lancé chacun des processus en cours :
Si, comme ici, notre administrateur trouve un svchost.exe lancé par une ligne du type : C:\svchost.exe -L -p 21 -e cmd.exe, nous avons soulevé un nouveau lièvre !

Présentation d'HELIX

Il existe un certain nombre d'outils forensiques permettant de mener une enquête dans les règles de l'art. Les principaux atouts de ces outils sont de faciliter la certification de l'authenticité de preuves récoltées (Chain-of-Custody) et de mettre à disposition des moteurs de recherche de motifs (pattern-matching) pour un grand nombre de formats de fichiers et de méta-données. Les plus connus sont Guidance Software de la société EnCase, NetAnalysis de Paraben, Ultimate Toolkit d'AccessData et enfin la suite ProDiscover de Technology Pathways.

HELIX constitue une alternative Open Source à ces outils.

Draw Fahey, de la société e-fense, a créé et maintient la distribution Linux Live HELIX, qui est bâtie sur la célèbre distribution Knoppix. HELIX est disponible sur le site de la société e-fense. Cette distribution contient un très grand nombre d'outils forensiques et d'outils de restautation système. HELIX est particulièrement utile lors de la collecte et l'analyse de preuves numériques sur un système en fonctionnement (live forensics) ou hors tension (dead forensics).

Comme HELIX provient de Knoppix, elle permet nativement d'analyser les systèmes de fichiers Linux comme Ext2/Ext3, et même des systèmes plus exotiques comme ReiserFS, JFS et XFS. Par contre, ce qui la différencie des autres distributions est qu'elle a été conçue pour préserver le contenu des disques durs et des partitions du système qu'elle examine.

En effet, un des problèmes récurrents, que j'ai rencontré avec les cédéroms de type Linux live, est qu'ils montent par défaut des partitions d'échange (swap) sur le disque dur au démarrage. Cela entraine un écrasement potentiel de preuves et une modification inacceptable (du point de vue forensique) d'une partie non négligeable du disque dur (la taille de la partition d'échange est fixée par défaut à celle de la mémoire physique du système).

HELIX monte les partitions du système en lecture seul et n'utilise aucune partition d'échange. Cette configuration préserve les données, leurs timbres-dates (MAC : Modified, Accessed, Changed/Created) et les méta-données du système. L'un des grands avantages techniques est que l'examinateur n'est plus obligé de recourir à un équipement de blocage en écriture, souvent problématique lors de l'examen d'un serveur monté en rack dans une baie technique...

HELIX possède également une partie dédiée au systèmes MS Windows. Elle contient des binaires et des exécutables permettant de recueillir des données volatiles, comme la mémoire physique par exemple...

La majorité des outils d'HELIX est Open Source. Ils peuvent être lancés à partir de la ligne de commandes d'un shell Linux (session X), à partir d'un environnement Cygwin ou à partir de l'interface graphique de sa partie MS Windows.

Le seul point noir que je lui concède est que je ne connaisse pas d'affaire judiciaire dans laquelle cet outil, assez récent, ai été utilisé.

Equipe forensique, équipe IR, quelle différence ?

Le forensique est souvent confondu avec la réponse aux incidents (abrégé dans la suite par IR pour Incidents Response). Mais, leurs objectifs sont fondamentalement différents.

Toute entreprise doit pouvoir mettre sur pied une équipe IR, lorsqu'un évènement suspect survient ou lorsqu'il faut stopper une activité malveillante. Monter une équipe forensique répond à d'autres besoins :

Une équipe forensique doit bien sûr posséder des connaissances techniques poussées, mais également un background légal conséquent. La différence fondamentale avec une équipe IR classique est la suivante :

L'équipe forensique doit maitriser la manipulation et la préservation de preuves numériques et doit savoir les présenter à un tribunal.

Ses membres doivent bien sûr être choisis parmi les techniciens systèmes et réseaux. Mais il faut également des spécialistes dans les domaines des ressources humaines, des affaires juridiques et même, parfois, des relations publiques...

Après avoir rédiger des procédures détaillées pour :
- identifier les systèmes critiques et la manière de les inspecter en cas d'incident (par exemple, certains systèmes ne pourront pas être mis hors tension, car trop critiques pour la conduite des opérations...)
- définir une certification d'authenticité (chain-of-custody pour les anglo-saxons) pour la collecte des preuves
- rédiger les modèles des documents forensiques
Il faut encore munir l'équipe forensique d'une trousse à outils conséquente.

Monter une équipe forensique est loin d'être à la porter de toute les entreprises. L'une des meilleures solutions consiste à fournir un bagage forensique à une équipe IR, en l'associant à un consultant forensique spécialisé, si on décide qu'un incident nécessite une poursuite judiciaire.

L'équipe forensique mène alors l'enquête, collecte et analyse les preuves. Le consultant vérifie que l'enquête est menée dans les règles de l'art et s'assure surtout que les preuves sont admissibles par un tribunal.

L'anti-anti-anti-forensique... Le live est-il déja dead ?

Les rootkits de troisième génération, tels FU, He4Hook, Klog, Adore, Suckit, utilisent les techniques DKOM (Direct Kernel Object Manipulation) pour manipuler les objets en mémoire physique. Ces rootkits agissent en mode noyau.

Lors du BlackHat 2005, James Butler et Sherri Sparks ont présenté Shadow Walker, un prototype de rootkit - dit de quatrième génération - qui manipule directement les pages de la mémoire physique : un rootkit non-persistant.

Ces rootkits ont en commun de résider et d'agir uniquement en mémoire physique, afin d'éviter les détections des antivirus et de contrer les techniques forensiques traditionnelles. Ils se font ainsi une spécialité de manipuler les objets en mémoire ou directement les pages mémoires (quatrième génération).

La question du jour est la suivante :
Doit-on abandonner les procédures forensiques traditionnelles et s'investir entièrement dans le live forensique pour résoudre les incidents de sécurité informatique ?

En 2005, trois évènements ont boosté l'analyse des dumps de mémoire physique des systèmes MS Windows :
- Chris Betz a publié memParser un outil qui énumère les processus actifs et peut également réaliser un dump de leur pages mémoires.
- George M. Garner Jr. et Robert-Jan Mora ont publié kntlist qui est une liste conséquente de processus, thread et autres objets nécessaires à l'analyse d'un dump mémoire des systèmes MS Windows.
- Mariusz Burdch a publié une extension pour le débogueur noyau de Windows : hidden.dll qui permet d'énumérer les processus camouflés et pourtant présents dans un dump mémoire.

Des outils d'investigation de la mémoire physique, notamment de celle des systèmes MS Windows, sont en court d'élaboration. Ces outils vont nous permettre de détecter et prouver la présence des derniers codes malveillants en circulation.

Le meilleur outil dont nous disposons actuellement pour collecter la mémoire physique d'un système non préparé, est dd de George Garner Jr. Cet outil n'est pas transparent du point de vue forensique, car il a besoin d'être chargé en mémoire pour fonctionner. Mais c'est le lot de tous les outils utilisés dans une investigation live.

Cependant, la lecture d'un article, datant de quelques mois, m'a fait réfléchir. La deuxième question du jour est la suivante :
dd peut-il devenir notre point faible, par l'utilisation qu'il fait de l'API Windows MapViewOfFile ?

L'article en question a été rédigé par le suédois Arne Vidstrom et est disponible sur son site ntsecurity.nu. Ce chercheur en sécurité informatique a ainsi développé un driver sous Windows XP pour bloquer dd sous certaines conditions. Un code malveillant qui exploite cette faiblesse de dd n'est donc pas irréalisable !

En attendant, le live forensique nous permet d'analyser des incidents à distance de manière très satisfaisante, bien que je ne connaisse personne, en France, ayant eu à présenter une analyse de la mémoire physique devant un tribunal...

De toute manière, avec la généralisation des disques durs de plusieurs teraoctets, les systèmes de fichiers chiffrés, les clés USB bon marché dépassant le gigaoctet de stockage, le forensique traditionnel est condamné à mort. Mais bon, c'est son domaine après tout !!

Quelques leçons apprises sur la réponse aux incidents

Dans le traitement de n'importe quelle crise, l'expérience montre que seuls deux facteurs sont réellement fondamentaux : l'expérience et la préparation.

Après de long mois passés à résoudre (ou tenter de résoudre...) des incidents sécurité informatique, j'en suis venu à la conclusion que la réussite ou l'échec d'une équipe IR ne provenaient pas du nombre d'IDS, IPS, pare-feu, antivirus, proxy et même honeypots qu'elle pouvait aligner, mais tout simplement de son organisation et des rapports humains qu'elle avait su tisser avec ses partenaires.

En fait, savoir répondre à un incident sécurité informatique se résume à respecter les trois principes suivants :
- la perception de l'incident
- la mobilisation des acteurs
- l'organisation de la réponse

Et oui, cela ne demande a priori aucune connaissance technique ! Il suffit pour s'en convaincre d'aligner cinq ou six hackers de haut vol dans une salle de crise... De plus, il faut avoir conscience que, contrairement à l'idée reçue, la gestion d'un incident majeur ne constitue pas une épreuve de vérité, mais un réel savoir-faire qui se construit essentiellement avec l'expérience.

La gravité d'un incident est une notion éminemment relative. Il faut pour cela se préserver de tous les éditeurs de logiciels de sécurité (les éditeurs d'antivirus en tête) qui rivalisent de sensationnalisme. Parfois même, les CERTs les plus sérieux se laissent prendre au piège...

La perception d'un incident sécurité informatique s'affine avec l'expérience et l'on doit toujours s'efforcer d'éviter de nommer crise ce qui n'est qu'une simple urgence, sous peine de perdre une crédibilité si difficile à acquérir.

Le principe de mobilisation consiste à éviter de passer soudain du calme quotidien à l'alerte de mobilisation générale. Il s'agit donc d'accompagner graduellement les indices d'un incident potentiel. Mais, dans la sécurité informatique, tout peut aller très vite...

La règle est la suivante : lorsqu'un faisceau suffisant de présomptions est réuni, il faut placer son équipe en état de veille renforcée. L'objectif est d'accompagner le développement de la situation afin de pouvoir déclencher le dispositif de la résolution d'incident au bon moment. Là encore, l'expérience est reine.

Enfin, il faut pouvoir proposer au client-victime un dispositif organisationnel approprié pour répondre à l'incident. Un tel dispositif fait partie des savoir-faire que l'on ne dévoile pas facilement (et je ne dérogerai pas à cette règle, du moins pour l'instant !).

Toutefois, il faut savoir que la mise en place du dispositif dépend de la nature et de la dynamique de l'incident : on ne gère pas de la même manière un incident court et un incident de longue durée. Et c'est toujours l'expérience qui permet de deviner la durée d'un incident, bien qu'on la sous-estime la plupart du temps !

Un des petits trucs que j'ai appris auprès des spécialistes de l'urgence est l'importance des repères visuels en état de stress. Dans de telles situations, on risque rapidement de perdre ses repères, d'oublier son rôle ou tout simplement de conserver sa propre carte mentale de la situation avant l'incident. De plus, lorsque enfin arrive la relève de l'équipe IR, un compte-rendu oral décousu, sous le coup de la fatigue, n'apporte en général rien de bon, si ce n'est cet habituel : bon courage !

Un tableau blanc avec un organigramme à jour au format géant, un ou plusieurs cahiers de bord (en bon papier), forment encore ce que l'on fait de mieux pour ne pas perdre pied dans un incident majeur regroupant une bonne cinquantaine de sites. Les logiciels de type Trouble Tickets, même les plus sophistiqués, ne les remplaceront jamais...

Ce tableau blanc doit évidemment être placé de manière à permettre au "visiteur" - du type haut responsable - de jeter un oeil derrière l'une des vitres de la salle de crise, sans vous déranger pour vous demander un point de situation et en profiter pour vous raconter sa jeunesse, lorsqu'il était un opérationnel...

Faut-il débrancher ou pas ?

L'usage des techniques forensiques est en plein évolution. Pourtant, lorsqu'un expert forensique est mandaté pour un délit ou un crime, la procédure reste immuable :
- éteindre la machine suspecte en "arrachant" son cordon d'alimentation
- convoquer le suspect et le plaignant pour la saisie des preuves
- acquérir les données du disque dur
- prendre une image forensique (bit par bit) à l'aide de "dd" ou de EnCase
- analyser les données
- rédiger un rapport

Il y a encore quelques années, un employé ne disposait que d'un unique PC, doté d'un petit disque. Les réseaux étaient rudimentaires, voire inexistants. Les protections par mot de passe étaient simplistes et le chiffrement fort des données était interdit par la loi dans notre beau pays ! Un enquêteur forensique était sûr de ses outils et de ses résultats et se présentait sereinement devant n'importe quel tribunal.

Avec l'avènement de l'hyperconnexion des réseaux d'entreprise, suite aux diverses fusions, acquisitions et autres partenariats faisant vivre les heureux détenteurs d'un MBA ;-), les données d'un employé sont réparties sur toute la planète et sont de plus en plus chiffrés avec de bons algorithmes. Bien entendu, l'employé doit pouvoir les consulter et les modifier de partout et tout le temps, surtout lorsqu'il s'agit d'un membre du directoire. La conséquence est que les experts forensics se montrent de plus en plus impuissants face aux crimes des cols blancs.

Mon approche des techniques forensiques provient de la réponse aux incidents (abréviation courante : IR, pour Incident Response). Dans ce domaine particulier, si nous avons toujours en tête que toutes les preuves recueillies sont susceptibles d'être présentées un jour devant un tribunal, l'objectif prioritaire reste de découvrir le plus rapidement possible les artefacts clés de l'incident. C'est à partir de ces artefacts que seront établis une ou plusieurs hypothèses de travail.

La procédure forensique "classique" est inadaptée aux besoins d'une équipe IR, surtout lorsque l'on connaît les délais et la logistique qu'elle implique ! C'est pourquoi elle reste toujours une option exceptionnelle de l'IR. On y pense parfois pour bétonner la rédaction d'un compte-rendu de retour d'expérience...

Après cette longue introduction, voici la question du jour :

Faut-il encore recommander à l'administrateur système de mettre hors tension un système suspecté de contenir des preuves d'un incident sécurité informatique ?

L'enquêteur forensics expérimenté répondra par l'habituelle :

cela dépend de la situation, du système, des applications qui tournent (SGBD)...

Quoi qu'il en soit, une chose est sûre :

la mémoire volatile et l'état du système sont perdu lors de la mise hors tension.

En fait, quelles sont les informations potentiellement utiles pour l'IR qui sont localisées dans la mémoire physique d'un système suspect :
- mots de passe en cache (chiffrement, messagerie...)
- codes malveillants résidant uniquement en mémoire physique (SQLSlammer)
- processus en mode noyau camouflés des backdoors
- données en clair de disques chiffrés (PGP Disk Encryption, SafeBoot, Vista TPM...)
- données de navigation Web persistantes en mémoire, alors que le cache du navigateur et toutes les traces ont été nettoyés

Pour une équipe IR, la collecte de la mémoire physique d'un système suspect permet :
- de confirmer des alertes ou événements remontés par des IDS
- de collecter (et préserver) certains fichiers si le système doit continuer à fonctionner

Par contre, cette collecte est relativement intrusive et peut entacher une éventuelle poursuite judiciaire ultérieure (vice de forme...).

Le dernier argument de poids pour débuter l'investigation avant que le système soit mis hors tension est l'augmentation du chiffrement de données, qu'il soit réalisé au niveau du noyau, du système de fichiers ou bien d'une simple librairie d'application.

La résilience ou l'instinct de survie

Au lieu de se réfugier derrière le dernier test de pénétration en déclamant : "les défenses ont tenu trois minutes de plus que la dernière fois !" ou la dernière version de la politique de sécurité informatique (PSI) signée de la main même du PDG ! Mieux vaut se concentrer sur l'essentiel et se poser la bonne question :

"En cas de crise profonde, qu'est qui permettrait à notre organisation de survivre ?

La résilience est un concept d'urgentiste de la sécurité. Pour les sciences physiques, la résilience est une propriété des métaux (tels que l'acier ou l'aluminium) qui leur permet de retrouver leur forme originelle après un choc. En écologie, c'est la capacité d'un écosystème ou d'une espèce à récupérer un fonctionnement et un développement normal après un traumatisme. Enfin, pour nos chers psychologues, il s'agit d'un phénomène psychologique consistant à prendre acte de son traumatisme.

Les PSI des organisations doivent donc être récrites afin d'en finir une fois pour toute avec l'exhaustivité paralysante et le risque zéro imbécile. Ces documents doivent définir les actions permettant la survie des éléments opérationnels les plus précieux de l'organisation et s'en tenir là !

Une PSI peut dès lors être perçue comme une contribution à la capacité d'adaptation (la résilience) de l'organisation à un environnement toujours plus agressif et évolutif.

Utilité d'une image minidump pour le forensique

Tout système MS Windows est configuré pour réaliser un enregistrement de son état lorsqu'il se plante. En regardant dans les propriétés avancées du Poste de Travail, on constate qu'il existe trois niveaux d'enregistrement :
- image mémoire complète : contient la totalité de la mémoire physique au moment du crash.
- image mémoire du noyau contient uniquement les pages lecture/écriture du mode noyau présentes dans la mémoire physique au moment du crash. Elle ne contient donc pas a priori les processus du mode utilisateur.
- image mémoire partielle. Une petite image mémoire, appelée communément minidump, d'une taille fixe de 64KB (ou 128KB pour les systèmes 64 bits).

Par défaut, seule une image minidump est générée par un système MS Windows. Nous allons étudier l'utilité éventuelle d'une telle image pour le forensique.

Pour une analyse forensique à distance, une minidump semble idéale de part sa taille (64KB ou 128 pour les systèmes 64 bits) car elle peut facilement être envoyée par messagerie. Reste à pouvoir la générer après une éventuelle compromission. En effet, la machine suspectée n'a pas, a priori, été configurée pour se crasher à l'aide de la séquence de touches de l'article précédent (sinon on aurait également configuré une image mémoire complète).

Après quelques recherches, j'ai mis la main sur l'utilitaire Notmyfault.exe de Mark Russinovich (encore disponible ici, mais pour combien de temps ??). Il permet de lancer un driver "bidon" (myfault) qui fait crasher le système selon différentes méthodes.

Après le crash, il s'agit de récupérer la minidump dans le répertoire \Windows\Minidump\. Son nom est alors composé de la chaîne "Mini" suivie de la date et d'un numéro de séquence (par ex: Mini-121106-01.dmp).

Malheureusement, si l'analyse d'une minidump permet de comprendre ce qui a généré le crash, elle n'est pas vraiment exploitable pour l'analyse d'une éventuelle compromission.
En effet, le seul processus analysable est celui qui a provoqué le crash (la séquence clavier ou le driver spécialement corrompu myfault) ! Par conséquent, une recherche des processus cachés à l'aide de l'outil hidden.dll est impossible.

En décortiquant d'avantage cette mini-image, celle-ci ne contient que le code stop et ses paramètres, la liste des drivers chargés, le processus et le thread courant (EPROCESS et THREAD) et la pile noyau pour le thread qui a causé le crash.

Conclusion : lorsque le système suspect n'a pas été préparé pour générer un crash dump complet (via la séquence de touches spéciales du BugCheck Trap), il faut se rabattre sur l'utilitaire dd et ses images de mémoire physique non compatibles avec le débogueur noyau de Microsoft...

Début d'analyse d'une image mémoire générée par un crash dump Windows

Les objets \\.\PhysicalMemory et \\.\DebugMemory sont des données brutes bas niveau. Microsoft génère une image d'un de ces objets lors d'un crash dump sous un format propriétaire destiné au débogage. La structure de ces images a été décrite par Andréas Schuster dans l'article dmp_file_structure.html.

Contrairement aux images générées par l'outil dd, on peut les analyser à l'aide des outils de débogage de Windows disponibles ici et des symboles correspondants au système d'exploitation de l'image (que j'ai dû télécharger car je n'étais pas alors directement connecté à Internet... )

Pour trouver les processus camouflés par les outils anti-forensiques ou les derniers Troyans (afin de tromper les techniques DKOM : Direct Kernel Object Manipulation), le meilleur outil que j'ai trouvé est hidden de Mariusz Burdach.

Il faut le lancer dans le débogueur avec la commande !c:\chemin_de_hidden.dll\hidden.allprocesses après avoir lancer un enregistrement du résultat.

Par exemple, si, au cours d'une analyse, vous trouvez la dll d'un processus caché qui se nomme metsvr.dll ou extXXXXX.dll (où les X sont des caractères aléatoires), vous avez découvert une trace flagrante du Meterpreter de Metasploit ! Nous verrons cela dès que j'aurai remis la main sur une telle image...

Installation de SIRIOS : serveur de tickets d'incident sécurité informatique Open Source

Description de SIRIOS

SIRIOS est un logiciel Open Source destiné à répondre aux besoins d'un CERT ou d'une équipe de réponses aux incidents. Le CERT-Bund (Le CERT de l'office fédéral de la sécurité informatique allemand) a commandé ce projet à la société OTRS fin 2003.

SIRIOS est basé sur le système de gestion de tickets d'incident OTRS (écrit en Perl), qui permet de réaliser et d'enregistrer toute la correspondance de la résolution d'un incident (e-mail, téléphone, note interne...).

SIRIOS est constitué d'une série de modules pour OTRS :
* module Incident : permet de gérer des incidents à base du format XML IODEF
* module Advisory : permet de générer des recommandations sous le format XML EISPP/DAF
* module Vulnerability : une base de données de vulnérabilités pouvant être enrichies par des bases existantes
* module Artefact : permet de sauver (valeur de hachage) et de gérer les artefacts (exploits, logs...) à analyser
* module WebWatcher : surveillance de site Web.

Installation de SIRIOS sur un serveur Debian.

La documentation de SIRIOS est essentiellement en langue allemande. Mais son installation est relativement simple.

La première étape consiste à installer un serveur LAMP traditionnel. Nous avons choisi ici un système d'exploitation Debian Linux.

Une fois ce dernier paramétré, nous allons télécharger l'avant dernière version stable du gestionnaire de tickets OTRS, disponible sur le site Internet : www.otrs.org. Pour ce message, il s'agit de la version otrs-2.0.4-01.tar.gz. SIRIOS possède actuellement un problème de compatibilité avec les versions 2.1.X d'OTRS.

Installation du logiciel OTRS

Nous allons copier cette archive et la décompresser dans le répertoire /opt à l'aide de la commande suivante :
# tar -xzvf otrs-2.0.4-01.tar.gz
OTRS nécessite un certain nombre de modules Perl. Nous allons les installer à l'aide de la commande suivante :
# apt-get install libapache2-mod-perl2 libapache2-request-perl libCGI-perl libapache-dbi-perl libgd-gd2-perl libmd5-perl libgd-graph-perl libgd-text-perl libnet-dns-perl libxml-parser-perl libdbd-mysql-perl libauthen-sasl-perl libpdf-api2-perl libcompress-zlib-perl
Pour vérifier que tous les modules perl nécessaires à OTRS sont présents, nous utilisons la commande suivante :
# ./otrs.checkModules
CGI ... ok
Date::Pcalc ... ok
Date::Format ... ok
DBI ... ok
DBD::mysql ... ok
Digest::MD5 ... ok
Crypt::PasswdMD5 ... ok
LWP::UserAgent ... ok
IO::Scalar ... ok
IO::Wrap ... ok
MIME::Base64 ... ok
MIME::Tools ... ok
Mail::Internet ... ok
Net::DNS ... ok
Net::POP3 ... ok
Net::LDAP ... not installed! (for directory authentication - not required)
Net::SMTP ... ok
Authen::SASL ... ok
GD ... ok
GD::Text ... ok
GD::Graph ... ok
GD::Graph::lines ... ok
GD::Text::Align ... ok
XML::Parser ... ok
PDF::API2 ... ok
Compress::Zlib ... ok

Une fois ces modules installés, nous allons créer l'utilisateur sirios et son groupe d'utilisateur (également nommé sirios) :
# groupadd sirios
# useradd ­-g sirios ­-d /opt/otrs/ ­sirios

Nous allons désormais mettre en place les fichiers de configuration de otrs en les tirant des fichiers-exemples (*.dist) :
# cd /opt/otrs/
# cp Kernel/Config.pm.dist Kernel/Config.pm
# cd Kernel/Config/
# for foo in *.dist; do cp $foo `basename $foo .dist`; done

L'étape suivante consiste à mettre en place les permissions nécessaires à l'utilisateur sirios et à l'utilisateur www-data (utilisateur du serveur Apache) :
# /opt/otrs/bin/SetPermissions.sh /opt/otrs sirios www-data www-data www-data

Les deux scripts Perl suivants permettent de vérifier que l'ensemble des pré-requis nécessaires aux pages de connexions des utilisateurs de SIRIOS sont vérifiés :
# perl ­-cw /opt/otrs/bin/cgi­bin/index.pl
/opt/otrs/bin/cgi­bin/index.pl syntax OK
# perl ­-cw /opt/otrs/bin/PostMaster.pl
/opt/otrs/bin/PostMaster.pl syntax OK

Reste à modifier le fichier de configuration du fichier /etc/apache2/sites-available/default. Pour cela nous allons l'éditer avec notre éditeur de texte préféré (ici nano) :
# nano /etc/apache2/sites-available/default

Nous allons rajouter les éléments suivants dans les répertoires virtuels :
Alias /otrs-web/ "/opt/otrs/var/httpd/htdocs/"
ScriptAlias /sirios/ "/opt/otrs/bin/cgi-bin/"

AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all

Il faut désormais relancer le serveur Apache, à l'aide de la commande suivante :
# /etc/init.d/apache2 reload

Installation graphique de la base de données

Pour cela, il suffit de lancer son navigateur favori avec l'adresse : http://localhost/sirios/installer.pl
A l'invit. de connexion, utilisez les éléments suivant :
- nom de connexion : root@localhost
- mot de passe : root(qu'il faudra changé dès que possible)
La première étape concerne la licence d'utilisation d'OTRS :
La deuxième étape consiste à rentrer les informations nécessaires à la création de la base.

Les informations clés sont les suivantes :
- administrateur de la base Mysql : root
- son mot de passe
- hôte : locahost
- type : Mysql
- nouvel utilisateur de la base : sirios
- son mot de passe : mot-de-passe-super-costaud (existe un script dans otrs pour le chiffrer)
- l'hôte de la base : localhost
- nom de la base de données : sirios
- action : créer

La dernière étape importante consiste à rentrer les derniers paramètres :
- le nom complet (FQND) du système : incident.société.com
- l'adresse de messagerie de son administrateur : admin@société.com
- le nom de l'organisation : CELLULE REPONSE INCIDENTS
- les paramètres des fichiers d'audit (log) doivent être laissés comme tels
- caractères par défaut : iso-8859-15
- langue par défaut : français
- CheckMXRecord : No

Paramètrage des tâches cron du serveur OTRS

Le serveur OTRS nécessite un certain nombre de tâches cron pour fonctionner correctement. Ces tâches doivent être lancé sous l'utilisateur sirios. Tous les scripts contenant ces tâches sont contenus dans le répertoire : /opt/otrs/var/cron.
# cd /opt/otrs/var/cron
# ls
aaa_base.dist pending_jobs.dist session.dist
fetchmail.dist postmaster.dist unlock.dist
generic_agent-database.dist postmaster_pop3.dist
generic_agent.dist rebuild_ticket_index.dist

Tous ces scripts possèdent un nom se terminant par .dist. Vous devez les copier dans des fichiers sans ce préfixe :
# for foo in *.dist; do cp $foo `basename $foo .dist`; done
Il faut désormais les intégrer dans les tâches de l'utilisateur sirios :
# cd /opt/otrs/bin/
# su sirios
$ ./Cron.sh start
Cron.sh - start/stop OTRS cronjobs - <$Revision: 1.4 $>
Copyright (c) 2002 Martin Edenhofer
(using /opt/otrs) done
$ exit
exit

La commande crontab -l -u sirios exécutée en tant que root permet de vérifier que ces tâches sont bien attribuées à l'utilsateur sirios :
# crontab -l -u sirios
...

Installation des modules SIRIOS

Les modules de SIRIOS à ajouter au serveur OTRS doivent être téléchargés à partir du site : www.sirios.org
Un fois ces modules copiés sur votre poste de travail, lancer une session du serveur otrs (via votre navigateur préféré) en tant qu'administrateur et, dans le menu, cliquez sur le lien : Package Manager :

Si cela ne fonctionne pas, il s'agit certainement d'un problème de permissions. Relancez alors l'utilitaire qui fixe les permissions du serveur otrs :

# /opt/otrs/bin/SetPermissions.sh /opt/otrs sirios www-data www-data www-data
...

Acquisition forensique des données volatiles d'un système MS Windows

L'acquisition Live est un sujet en pointe dans le domaine du forensique. Grâce à Andreas Schuster et ses comparses, nous possédons désormais des outils plus ou moins userfriendly pour analyser la mémoire physique collectée sur un système.

Pour les systèmes MS Windows, cette acquisition est réalisée au travers l'objet \\.\Device\PhysicalMemory ou l'objet \\.\DebugMemory\ qui permettent d'accéder à la mémoire physique en mode utilisateur, si l'on dispose des droits administrateurs.

Malheureusement, cet accès a été bloqué dans Windows XP 64-bit, Windows 2003 Server SP1 et Windows Vista. Il faut désormais utilisé des moyens lourds pour extraire la mémoire vive de ces systèmes, de type développement d'un driver spécialement conçu (effet de bord inévitable lors de son installation sur une machine compromise) ou le port firewire qui n'est présent que sur les machines les plus récentes.

Pour pouvoir étudier les codes malveillants qui sont injectés dans la mémoire physique d'un système Windows compromis, une solution acceptable du point de vue forensique (engendre un minimum d'effets de bord) consiste à collecter cette mémoire physique. Cette mémoire contient alors toutes les méta-données nécessaires à l'analyse des processus tournant sur la machine. On peut également y trouver des traces de processus ayant été lancés jusqu'à dix jours précédents une collecte !

Pour cette collecte, deux méthodes sont habituellement employées :
- avoir au préalable préparer la machine pour pouvoir réaliser un crash dump
- utiliser l'outil dd pour copier octet par octet cette mémoire physique non figée.

Préparation d'un système au crash dump : méthode du "BugCheck trap"

L'article 244239 de la base de connaissances de Microsoft, décrit cette manipulation, qui est uniquement faisable à l'aide d'un clavier standard (non USB et pas de Virtual PC non plus).

Voici un résumé de cette procédure :

1. Démarrez l'Éditeur du Registre (Regedt32.exe).
2. Recherchez la clé suivante dans le Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
3. Dans le menu Edition, cliquez sur Nouveau, Valeur DWORD :
- Nom : CrashOnCtrlScroll
- Type de donnée : REG_DWORD
- Valeur : 1
4. Quittez l'Editeur du Registre et redémarrez le système.
5. Une fois le système redémarré, choisissez un "crash dump" complet :
- Cliquez-droit sur "Poste de travail", puis cliquez sur "Propriétés"
- Cliquez sur l'onglet "Avancé", allez dans la rubrique "Démarrage et récupération", cliquez sur le bouton "Paramètres"
- Allez dans la rubrique "écriture des informations de débogage" et sélectionnez "Image mémoire complète" dans le menu déroulant.

Après le redémarrage de l'ordinateur, vous pourrez créer un fichier Memory.dmp en maintenant la touche CTRL droite enfoncée et en appuyant deux fois sur la touche ARRÊT DÉFIL. Une fois le célèbre écran bleu obtenu, il faut attendre la fin du décompte pour redémarrer le système. L'image de la mémoire physique sera alors récupérable dans le répertoire \%Systemroot\Windows\ sous l'appellation usuelle memory.dmp

Utilisation de "dd" du cédérom HELIX

Dans la partie Windows du cédérom HELIX, une page user friendly permet d'utiliser facilement dd :

Une fois entrer tous les paramètres, vous pouvez presser le bouton Acquire. Une fenêtre d'édition de commande (Shell) apparaît alors. Vous pouvez alors copier la ligne de commande dd dans cette fenêtre à l'aide d'un clic droit et en sélectionnant copier dans le menu contextuel. Pressez entrée pour exécuter la commande.
Une fois la commande finie, vous obtenez trois fichiers dans le répertoire de destination :
- nomfichier.dd– le fichier image
- nomfichier.dd.md5 – un fichier contenant la somme de contrôle MD5 du fichier image.
- Audit.log – un fichier contenant la commande et la sortie du programme.