Le PenTest est un sport de combat comme un autre

C'est la fin...

2009-04-22T07:50:00.000Z

Je m'envole vers d'autres cieux, car :

l’or de tous les climats qu’entouré l’Océan
Peut-il jamais payer ce secret d’importance ?

Et nan, cela n'a rien à voir avec mon pentest de la semaine prochaine en Polynésie...

Adieu donc !

Retour aux sources

2009-02-07T12:44:00.128Z

Déjà dix-huit mois à trimer sur toutes les techno' web. Je fais une pause. Pour chaque système audité, ce n'est pas moins de 8 techno' différentes à maîtriser. C'est épuisant, mais passionnant.

Au détour d'un gros pentest système pur, réalisé sans aucune préparation (merci le collègue consultant senior qui se dégonfle à la dernière minute), j'ai repris pied brutalement dans le petit monde des PoC, que j'avais abandonné sur un coup de tête.

Que de temps écoulé, depuis que l'on retravaillait à la main un PoC pour trouver une adresse de retour stable dans nos chers systèmes Krosoft frenchies. Nous disposons aujourd'hui de boîtes à outils vraiment performantes, qui, heureusement, ne coûtent pas toutes 5*.000$ pièce...

Afin de pouvoir justifier auprès de mes clients l'impact d'un pentest, je m'efforce de toujours choisir des outils opensources. Il est vrai qu'il est agassant durant la présentation des résultats de se faire interroger sur ses outils : "vous avez fait ça avec un outil spécialisé ou avec des logiciels libres ?" Comme si les outils opensources n'étaient pas aussi affutés qu'une suite pro' en python qui coûte plus d'un mois de prestation ?

C'est vrai, il ne faut pas vous cacher que les modules externes pour ratproxy et burp dans msf3 ne sont pas étrangers à mon soudain intérêt pour la programmation ruby (bibliothèque jruby pour le lien avec les appli' web) et la génération de rapports avec wmap.

Pour info, le readme du module pour burp possède une erreur : il faut remplacer les ";" par des ":" dans l'invocation des librairies java... Je vais essayer de soigner mon aversion maladive pour la lumière des projecteurs et peut être faire un petit track chez msf avec un nouveau pseudo, car celui là est un peu percé. (ou alors, j'y enverrai mon apprentit ;-)

Ce retour au sources m'a d'ailleurs permis de parcourir rapidement la prose et les traductions courageuses de notre Jérome Athias national. Ce dernier a le mérite d'y croire et d'essayer de faire bouger les lignes de notre scène hexagonale endormie. C'est vrai que quinze ans d'encadrement par les OPJ de la DS* sans moustaches, ça ne donne pas envie aux anciens de former la jeunesse (on a des mômes maintenant...). Dormez braves gens, et consommez sur nos portails d'achat pourris en priant tout de même que votre numéro de carte soit bien stockée sur une base antédéluvienne et sur un OS frenchie oublié de tous (i.e., une sous-version boguée et expurgée des algo crypto trop difficiles à péter : cela coûte cher le temps de calcul au CEA... alors qu'avec une serviette éponge et un kilo d'oranges, nos pro' de l'HUMINT font des merveilles)

La semaine prochaine, un nouveau pentest (de nuit !!) démarre. Je n'aurais vraisemblablement pas le temps de faire vivre ce blog...

Au fait, si vous avez des "jmp esi" stables pour la librairie WS2HELP.DLL de win2k3 sp2 (sans dep) version française (bien entendue), vous me ferez gagner quelques heures de sommeil. ;-)

La gravité est le bonheur des imbéciles

2009-01-10T12:22:00.002Z

Je vous préviens tout de suite, ce billet illisible est bourré de disgressions proustiennes...

Parce que le monde est imparfait et que je connais pas encore d'industriel (même ceux qui vendent sur leurs sites web des pièces détachées à plus de 2.000.000 euros !!) qui ait réalisé une analyse de risques à la sauce 27.005 pour ses appli' web, il sera toujours difficile de qualifier le niveau d'impact du risque potentiel (trop classe comme appelation, nan ?) de la petite centaine de vulnérabilités qui forment votre rapport d'audit.

On a beau marteler durant la réunion de lancement, qu'il vous faut au minimum un classement par niveaux de criticité des différentes applications à auditer (et oui, je ne parle même pas d'actifs primaires et secondaires, car je ne veux pas brusquer le chaland toujours ignare en matière de SSI), tout ce que le chef de projet surchargé vous sortira après deux semaines de harcèlement quotidien, c'est un pov' schéma visio (avec un fond noir pour raisons de sécurité...) avec les noms des appli', ou deux noms ont été soulignés car : "ce sont les appli' dont les bases sont sauvegardées toutes les demies journées...alors ce doit être les plus importantes !!"

Tout ça pour dire, qu'il ne faut pas tomber dans le FUD complet (ça, c'est pour la citation de Montesquieu dans le titre) comme le pratiquent certains concurrents (vous savez, une de ces grosses boîtes de la région parisienne qui utilisent Nessus pour auditer des services web !), mais choisir soigneusement les vulnérabilités à mettre en avant lors de la réunion de restitution (vous savez la réunion programmée à 14h00, après le repas arrosé où les commerciaux, qui payent l'addition, ont gonflé le client avec un étalage indigeste de chiffres et de succes story... et d'où il ne faut pas repartir sans avoir fait signer le sacro-saint PV de recette).

Le plus simple, pour choisir les bonnes vuln' à mettre en avant, consiste à utiliser le ratio "facilité d'exécution"/"gain attendue" du délinquant moyen (ratio qui a fait la prospérité de l'ancien maire de New York et de nos chers ministres de l'intérieure, avec la cèlèbre politique de la tolérance zéro, mais ceci est encore une autre histoire...).

Le fait est, que ce sont ces vulnérabilités qui sont les plus simples à expliquer lors de la réunion/sieste de l'après-midi, surtout lorsque vous avez un auditoire composé de littéraires (là, je veux parler des RSSI de toutes les filliales du client qui se sont donné le mot pour la bouff' gratos, et non du consultant sénior qui a insisté pour vous accompagné, car il veut vendre au client une analyse de risques 27.005 ou une politique de sécu de 400 pages... encore que !!) qui considèrent tout sigle anglosaxon comme une grossière insulte à leur intelligence...

En fait, mon message était tout simple : je m'interrogeais sur le ratio vuln' critiques/vuln' hautes qu'il faut glisser dans un rapport d'audit ?

Ah, j'oubliais : "bonne année toi-même !" pour mes six lecteurs.

La nouvelle version de Burp Suite est énorme !!!

2008-12-19T16:21:00.000Z

Argh ! Enfin les vacances. Je suis sur les genoux.

Bientôt deux mois sans rien poster ! La honte...Pour ma défense, il faut savoir que les fins de semestre sont toujours super chargées pour les pov' p'tits pentesteurs. A croire que nos prestations ne sont commandées qu'avec des queues de crédit ou des fonds de tiroir. Et enfin, ma fille ainée est rentrée en maternelle cette année. Elle rapporte donc toutes les maladies infantiles du continent à sa p'tite soeur. Mes nuits sont bientôt plus fatiguantes que mes jours...

Nous avons terminé aujourd'hui, zaz idan et moi-même (bizarre ce pseudo, cela ressemble un peu à Zapp Brannigan ! Un parent ?) un audit marathon d'une quarantaine d'applications Web. Dur de réussir à vendre une prestation de qualité lorsque vos concurrents (apparemment, en place chez le client depuis des années) se contente d'un simple scan Nessus ! Bref, il a fallu s'aligner et casser les prix et faire en 15 jours ce qui aurait du être vendu en 40. La galère !

Mais, bon la pêche a été super bonne. Il faut dire que dix ans de scans Nessus sur des portails extranet, cela laisse tout un tas de vulnérabilités super critiques. Un vrai festival du hack. On s'est régalé !

Ces trois dernières semaines nous ont donc permis de tester sur un grand nombre de technos et de plates-formes la version béta, puis la version finale de Burp Suite, nouvelle mouture. Un seul regret, c'est la sortie tardive de sqlmap qui prend désormais en entrée les log de burp. Cela devient de la tuerie...

Pour revenir à Burp, même si les deux premières versions béta étaient plutôt instables, nous avons pu comparer nos tests habituels sous Burp, aux résultats du scanner de vuln' web GrosCulnetix (figure imposée par le client, qui insistait pour avoir du scan !!!). Il n'y a vraiment pas photo, surtout lorsque l'on passe au travers un SiteMinder dernier cri (mais avec des cookies mal gérés par les appli') et des portails extranet WebLogic montés à l'ancienne (mod_rewrite et iframes bidons à la Apache Coyotte vers des vieux Tomcat, Domino et IIS-ASP), alors qu'ils devraient normalement s'appuyer sur leurs fonctionnalités d'hubs de connexions en T3 vers les seules bases de données !!

Bon. Je dois y aller. Si vous avez des trucs à partager sur Burp ou autre chose. N'hésitez pas... Cela me donnera peut être envie de réécrire durant mes vacances (si je trouve une connexion wifi pas trop éloignée et hackable sans antenne externe près de ma location ! Pas évident...)

La connaissance engendre la peur... ou bien ça fatigue...

2008-10-31T16:48:00.000Z

Un billet de mauvaise humeur, pour chasser les miasmes :

J'ai rien à écrire d'interressant. Ou bien est-ce la flème ? Toujours est-il que ma verve s'épuise peu à peu entre les copier-coller des rapports d'audit et autres propales. Il faut vraiment ramer pour alimenter son boulot de pentester. Ce boulot est synonyme de missions courtes de moins de 20 jours. Quand j'en aurais marre, je deviendrais Consultant Orga' qui passe l'hiver au chaud avec une mission de plus de 100 jours. Une bonne politique de sécurité Coorporate. Voila ce qu'il me faut pour reprendre pied !

Si j'avais le courage, je vous parlerais de la faille de conception trouvée aujourd'hui : la bonne vieille faille qu'aucun scan de vuln' web, même un à 4000$, n'aurait pu trouvé. Mais bon, cela serait trop compliqué de décrire un script d'authentification, à la sauce Ajax, scotché sur une vieille base Domino aux ACL super-aiguisées. De toute manière, je ne sais même pas si je retrouverai un jour le même type de faille chez un autre client...

Bon, je soigne ma mauvaise grippe ce weekend et je me remotive. Promis !

Fukuyama n'a jamais été un homme révolté

2008-08-30T01:32:00.000+01:00

Bien qu'il soit sympa de vérifier chaque jour combien le petit père Francis s'est lamentablement planté en jouant les prophètes, je vous rassure, je ne vais pas tenter de vous démontrer ici en quoi l'éternel retour hégélien peut s'appliquer au Pentest web2.0 !

Quant à la notion de révolte, il faut simplement faire un diff entre l'œuvre de Camus (le révolté) et celle de Sartre (le révolutionnaire) pour comprendre l'allusion, mais je ne vais pas faire ici l'étalage de mes lettres (d'autres Pentesteurs se complaisent à le faire quotidiennement !) '];alert('Troll');//.

Les frameworks de Pentest ont révolutionné notre métier en nous délestant, entre autres, de l'énorme travail de veille-techno/adaptation-opcodes-frenchies que tout pentesteur digne de ce nom doit fournir. Bien qu'ayant trouvé un employeur qui reconnaisse enfin cette tâche en tant que "travail à part entière" (vive le code de pointage "Formation_Perso" !), je peux vous avouer, qu'en ce moment, je me fie énormément aux mises à jour de Metasploit pour tout ce qui touche au domaine Client-Serveur, afin de mieux me concentrer sur les appli' Web et en particulier le Web2.0. (Chacun son domaine de prédilection)

Les frameworks de Pentest pour appli Web sont apparemment à la mode parmis mes confrères. Pourtant, je suis resté fidèle à l'Open Source (ou est-ce ma parano/prudence habituelle ?) en m'appuyant sur le trio Burp/Wapiti/w3af plutôt que sur un framework comme Accunetix, Appscan ou Web Inspect.(oui, je sais, Burp n'est pas vraiment de l'Open Source...)

En fait, les frameworks propriétaires actuels sont très décevants lorsqu'il s'agit de réaliser un pentest d'une appli sous Ajax. Les meilleurs d'entre eux arrivent péniblement à passer en revue ("parser" dans le jargon) les objets Thick Clients (Applets Java, Controles ActiveX, ObjectsFlash...) et restent sans voix face à un appel XHR.

En raison de l'extrême transparence des techno Ajax (tout passe en clair), je ne pense pas qu'un parseur web2.0 très poussé soit actuellement indispensable. En effet, la reconnaissance d'une appli sous Ajax est tout à fait réalisable aujourd'hui à l'aide d'un furieux mélange d'interruptions sous Firebug et de scripts Greasemonkey et Chikenfoot. Avec la pratique, on arrive en quelques minutes à obtenir la liste de toutes les requêtes XHR et à extraire les fonctions intéressantes correspondantes.

En parlant de scripts Greasemonkey, je vous déconseille vivement le script WebPageFingerprint d'Aung Khant qui n'est rien d'autre qu'un cheval de Troie sur pattes ! Celui-ci rapatrie toutes les failles potentielles directement au site de yehg. L'étude de ce script est cependant très enrichissante, bien que les fonctions d'analyse restent inaccessibles sur le site de son auteur. ;-)

Pour revenir à l'idée d'un parser Ajax, un tel outil va devenir indispensable lorsque les techno' Ajax vont gagner en maturité et commencer à chiffrer/masquer toutes les XHR. En fait, un petit nombre de développeurs web2.0 semblent avoir déjà entammer ce travail d'obfuscation à l'aide des différents outils d'anonymisation de variables à leur disposition (à moins que je soit tombé sur des développeurs off-shore indiens qui protègent leur gagne-pain ??)

En dépit de l'apparente complexité d'Ajax, un tel parser n'est pas monstrueux à coder. Pour démarrer, on peut se baser sur le parser rudimentaire proposé par Sheeraj Shah : scanajax.rb et l'enrichir peu à peu au fil de ces découvertes. A savoir que cet outil ne fonctionne correctement qu'une fois toutes ces dépendances respectées : gem install rest-open-uri openuri-memcached urirequire jrexml rexml-expansion-fix

Cependant, dès que l'on rencontre des techniques d'obfuscation, il faut se raccrocher aux interruptions de Firebug et à une analyse approfondie sous WebDevelopper pour s'y retrouver. Je doute que les parser d'Acunetix ou de Web Inspect aient un quelconque avenir en la matière. Bref, il nous faut construire l'ollydbg du JavaScript/XHR.

CQFD pour la digression hégélienne...

PenTest2.0 : le pourquoi avant le comment !

2008-07-12T17:52:00.011+01:00

Il suffit de faire un peu le tour des magasines, listes de diffusion, conférences/symposiums et autres blogs pour se rendre compte que la scène française (de la profession ou pas) est fortement concentrée sur les failles systèmes et tout ce qui tourne autour du Ring 0. Il semble bien que la Patrie des Lumières snobe ouvertement tout ce qui ne fournit pas un accès direct au Saint Graal du siècle dernier, à savoir le compte administrateur/root.
Fort de cette constatation, je ne suis pas étonné que l'OWASP soit si peu représentée dans notre cher pays et que ces membres en soient réduits à prêcher dans le désert numérique...
Lorsque j'ai l'occasion de lire d'anciens rapports d'audit (lors de mon arrivée chez un nouvel employeur ou bien chez des clients qui me les fournissent sous couvert du classique : "Essayez de nous trouver quelque chose de nouveau"), je remarque assez souvent que le Pentester Frenchy, après quelques copies d'écran de pop-up "XSS", concentre tout son talent à décrire le magnifique OpCode qu'il a pu "coller" au service SNMP du serveur Web afin d'obtenir son "Saint Graal". Reste que ce type de technique est improductive, voire contre-productive, dans les Pentests d'architectures Web2.0...
Après cette intro' ayant presque rien à voir avec notre sujet (digne d'un pisseur de copie à la Hackin9), j'en reviens à ce qui nous interesse : les Pentests2.0 et les différentes méthodes d'exploitation des techno' Ajax; Flash, SOAP, REST, XML-RPC et autres utilisations bizaroïdes des feed RSS/Atom...Non, je ne vais pas vous faire ce soir un cours magistral sur ce sujet à l'étendu conséquent, mais simplement discourir sur le fait que ces techno' demandent autre chose qu'un wget -r www.hackme.com | grep "executeQuery"...
Le fait est qu'il est pratiquement impossible de réaliser un Pentest d'appli' Web bâtie sur ces techno à partir de la procédure de crawling habituelle (exploration de l'appli avec son proxy préféré : Burp ou WebScarab, puis analyse de l'arborescence obtenue).
Quelle soit bâtie sur de l'AJAX ou du Flash, une page 2.0 peut être l'unique page de votre belle arborescence apparaissant dans votre proxy, mais pourtant elle sera le support d'une bonne vingtaine d'applications métiers (les appels DOM à ne pas louper) reliées à autant de serveurs d'application et de bases de données, souvent sur des systèmes n'appartenant pas à votre client (du moins à son service).
C'est ce que nos chers architectes nomment les architectures SOA ou les applications mashups (une application d'applications) dans lesquelles une page web lancée dans notre navigateur se transforme en client léger virtuel pour toutes les appli du client et ses partenaires/filiales/clients/fournisseurs.
Si votre système de facturation de Pentest est bâti sur le nombre de pages à traiter, vous allez y être de votre poche... Amis Pentester, ne rigolaient pas avec ce type d'archi', nos copains les développeurs (les petits jeunes qui sortent d'école) en pondent une dizaine chaque mois pour nos chers clients...
Les appli web2.0 s'échangent toutes sortes de formats d'information de manière asynchrone, tels que XML, du JSON (JavaScript Object Notation), du JS-array (une sorte de tableau en JavaScript) et des flux d'informations temps réel en RSS (cotations...) en provenance de différents domaines. Réaliser un diagramme simple de toutes les interactions possibles de cette appli web (la modélisation des menaces comme on aime à appeler le bô schéma visio de nos rapport d'audit) peut prendre des heures, surtout avec l'outillage dont nous disposons actuellement (Firebug...).
La clé du PenTest web2.0 réside en fait dans ces communications Cross-Domain au sein de cette page unique, ouverte à ces sources diverses et plus ou moins sûres. La boite de Pandore des XSS et autres XSRF est ouverte. Il nous reste à pouvoir analyser toutes ces données asynchrones écrites en XML, le langage le moins user-friendly de la planète.
Si cela intéresse mes quatre lecteurs, je vais essayer d'écrire quelques bafouilles la-dessus dans les prochains jours. S'ils s'en foutent, cela me servira de pense-bête, comme le reste...

Ratproxy un parser de vulnérabilités passif pour les Web Services

2008-07-02T20:27:00.009+01:00

N'étant pas un furieux de la prog' (chacun son boulot), j'avoue avoir passé pas mal de temps à tester des scanners passifs de vuln' web à base des différents parser www dispo' ; que cela soit les vieux parser Perl, le bizaroïde hpricot (en Ruby) ou un bricolage de Python (ça c'est pour le troll). Bref, un passe-temps beaucoup plus sympa que la rédaction de propales.

Après avoir pratiquer, puis écarter le célèbre nikto, w3af avec son code source super bien documenté et l'étonnant sts-scanner, en raison de leur trop grande agressivité, j'ai finalement jeté mon dévolu sur l'outil Ratproxy de Michal Zalewski qui semble de loin le plus prometteur.

Le fait est qu'il devient de plus en plus difficile de dénicher des Pentests d'appli Web qui soient sur plate-forme de test ou de pré-prod'. De toute manière, lorsque l'on insiste un peu trop lourdement pour disposer d' un environnement hors prod', on s'en tire souvent avec une base boguée datant de 2 ans et des versions d'appli du type 0.1.0.27 qui semblent sorties tout droit d'un mauvais trip de pisseur de code stagiaire.

De toute façon, on a l'air crétin au kick-off en face du gros malin de développeur en chef qui n'arrête pas de vous contrer en affirmant que la nouvelle version n'est plus vulnérable... A moins d'avoir deux jours complets à passer sur l'appli (cela arrive encore) ou bien être assez cinglé pour utiliser un Canvas ou un Core Impact sur de la prod' (même en passant toutes mes nuits sur les sources, je n'aurais pas d'avantage confiance en leurs rootkit-maison) on est parfois tenté d'utiliser un scanner de vuln' Web pour ne pas rater son RER (Ivry la bataille, ça fait loin de la Défense...).

Mais voila, en prod, l'utilisation d'un de ces scanners est un véritable suicide. Sans compter les dénis de service sur les répartiteurs de charge poussifs, un tel outil génère toujours un nombre incalculable de XSS qui sont autant de nano-bombes à fragmentation vertes fluo portant votre dédicace... D'où ma recherche d'une solution pouvant soit être utilisée en proxy passif lors de l'exploration de l'appli' avec détection à la volée des vuln' ou soit pouvant être utilisée à partir des logs d'un Burp Proxy, de WebScarab (ou même de Paros).

Sts-scanner avait l'air bien partie sur le papier, sachant qu'il prend les logs de Burp. Burp reste aujourd'hui mon outil préféré, bien qu'il soit beaucoup moins stable sous linux que sous Windows (si vous avez une astuce pour agrandir la RAM allouée à un processus java sous Linux je suis preneur). Cependant, j'ai vite déchanté lorsque je me suis aperçu que les logs de Burp lui permettaient uniquement de traduire le javascript et le java pour passer les mécanismes d'authentification (hpricot ne comprend ni le javascript, ni le java, et pour ce qui est des technos Web2.0...) et qu'il était finalement un pur scanner actif avec tout l'arsenal d'XSS qui va bien...

Ratproxy semble l'outil que j'attendais depuis longtemps, il parle le JSON (avec un peu de bol on doit pouvoir également lancer les premiers tests sur les identifiants UDDI et DISCO) et surtout son option -d permet de choisir finement les domaines à tester (ce qui est souvent indispensables avec les appli' métier de nos chères fusions/acquisition/filiales-à-15%_du_capital...)

N'ayant pas sous la main d'appli Web Services permettant de tester pleinement Ratproxy, je vous promets de vous faire une retour d'expérience plus complet dans les prochaines semaines (peut être la semaine prochaine si le client est au rendez-vous)...

BLOG 3.0

2008-07-01T21:46:00.004+01:00

"La chair est triste et j'ai lu tous les livres !"

J'avais le choix entre faire mourir ce blog (Erase.Submit !) ou le convertir à des domaines qui me motivent d'avantage.

Le vieil homme est mort et le NewBorn 3.0 apparaît à la lumière !!

Les prochains billets (il y en aura c'est promis) porteront donc sur les techniques Pentest qui exploitent les failles et défauts de logique des Web Services et peut être sur les audits de conf' à la sauce 27005 (il faut bien nourrir sa famille).

C'est tout pour ce soir...

Un dico corporate à 10 cents..

2008-04-05T01:07:00.003Z

Pas de grande envolée lyrique cette semaine. Un simple billet sous la forme de pense-bête suffira.

voici une petite recette pour constituer rapidement un dico regroupant le jargon du client. Cela peut être utile pour réaliser un brute force rapide de clé WPA (les gros dico ne sont pas vraiment taillés pour attaquer cette techno en un minimum de temps) :

Tout d'abord, avec httrack (mon préféré) aspirer la partie du site web du client (ou de son intranet si dispo) qui regroupe l'essentiel de son jargon (cela peut être la liste de ces produits ou les pages de son support technique) :

# httrack "http://www.leclient.com/jargon/" -O "/root/websites/leclient" "+www.leclient.com/jargon/*" -v

Une fois le site aspiré, passer le résultat à la moulinette avec l'excellent wyd.pl de Max Moser et Martin Muench :

# cd /usr/local/bin/wyd
# ./wyd.pl -b -e -f -v -o wordlistleclient.txt /root/websites/leclient/www.leclient.com/*

Faire un peu de tri :

# tr '[A-Z]' '[a-z]' <wordlistleclient.txt | sort | uniq > wordlistleclient-triee.txt

Puis, retirer les mots usuels du dictionnaire français :

# comm -23 wordlistleclient-triee.txt /usr/local/lib/aspell/french.words > dico-leclient.txt

Après un peu de dépoussiérage à la mano, cela fournit un complément sympa pour votre liste de mots de passe par défaut...

Enfin, n'oubliez pas les jeux de mot basés sur le nom du client. Les plus bidons fonctionnent toujours le mieux...

Le vieil homme doit mourir...

2008-03-23T01:47:00.002Z

Ce titre n'est pas un appel au meurtre, encore moins un pamphlet contre un quelconque consultant sénior (quoi que...) seulement la litanie favorite des tortionnaires coréens ayant réussi, grâce à la technique de l'autocritique, à retourner quelques majors de promo de West Point des années 49, 50 et 51...

Mais bon, je ne vais pas aujourd'hui disserter sur l'effet papillon de la coercition nord-coréenne sur la consommation de LSD dans les technivales d'Europe de l'Ouest (il y a pourtant un lien surprenant...). Nan, je vais vous parler de la condamnation de la vieille école de l'INFOSEC incapable de s'adapter à un nouvel environnement trop dérangeant, qui met allègrement au placard la quasi-totalité du savoir et des certitudes qu'elle a accumulés jusqu'au début de ce millénaire.

De savoirs obsolètes, je veux bien sûr parler des techno pare-feu, de la lutte anti-virale, des théories sur la défense en profondeur, de la prog' raw-sockets en C et, plus largement, de la majorité des sujets de discussion qui ont fait et font encore les choux gras des listes de diffusion INFOSEC.

Ça y est, vous vous dites : "encore un p'tit jeunot qui crache sa haine de la Old School et ne pense qu'à se faire une place auprès de ses ainés !" En fait, je vais avoir 36 ans le mois prochain, et je suis un pur produit de cette Old School !

Ce vieil homme doit mourir. Voici son autocritique :

Il y a quelques mois, j'avoue m'être jeté sur les systèmes SCADA, en pensant avoir trouvé un El Dorado pour mes connaissances obsolètes. Tout y était : de l'exploit raw-socket au ping of Death (exploit qui marque encore les esprits des consultants Orga-Sénior façon 27001). J'en étais à monter un pentest pur année 90 avec du hping et toute la panoplie du paquet-forgery (scapy) un vieux modem, des scripts pour du brute-force Telnet et même un sifflet Cap'tain Crunch... lorsque, devant l'interface web de connexion, j'ai essayé les 9 caractères (avec les espaces) connus de tous les scripts kiddies de moins de 16 ans qui n'ont rien à foutre des protocoles réseau : 1' OR 1=1. Argh...

bref, à l'heure où la majorité des plus de 30 ans se demande s'il faut faire du pentest avec un poste Windows ou la dernière BackTrack (je parle de ceux qui ne sont pas encore manager ou qui ne veulent plus l'être), ou encore s'il faut s'afficher aux réunions de l'OSSIR du lundi alors que ça plait pas aux copains anciens des écoles du Kremlin Bicêtre, qui sont des ayatollahs du BSD et des buveurs de bières d'Asie du sud-est... le monde a bougé sans vous !

Un professionnel Old School pourra survivre encore quelques années. L'informatique industrielle et ses SCADA d'un autre âge sont là pour ça. Pour ma part, j'ai décidé de tout balancer (et de claquer la porte de ma boite par dessus le marché...).

Ceci est donc mon autocritique : le vieil homme est mort !

Lecteur Old School, je te propose de venir ici faire toi aussi ton autocritique et de... signer une pétition pour faite péter l'OSSIR avec ces deux écoles d'un autre âge : Unix contre Windows (ça, c'est pour avoir un maximum de Trolls dans les commentaires)

Je ne vais pas vous faire le coup du 99,99% des flux passent au travers d'un pare-feu avec les ports 25 et 80 d'ouverts... Mais bon, il faut vous réveiller : on trouve désormais des langages de script pour drivers dynamiques ! Tout est logiciel et tout se passe au niveau de la couche application. Ce n'est pas la dernière coquille du Firewire qui va changer cela ! Tout se passe dans des applications qui se lancent dans et se partagent la mémoire vive des machines.

Bon. Il est tard. Au moins, ça s'est fait !

Burp Suite

2008-03-22T01:46:00.001Z

Juste un p'tit billet sur Burp Suite, qui est devenu en quelques journées mon outil préféré pour l'audit des applications web. PORTSWIGGER a réalisé un travail remarquable, et notamment le module Burp Intruder de la version pro qui vaut largement ses 99 pounds (en note de frais ;-).

Les attaques possibles via les payload Intruder en font l'outil de pentest web le plus abouti du moment. Par exemple, les injections SQL, permettant d'extraire des données d'une base, peuvent être forgées très rapidement en retravaillant l'injection à partir du message d'erreur (via regex), puis en les lançant un bon millier de fois pour dévaliser la base. Il faut tout de même faire attention aux architectures en pré-prod, dont le client vous a assuré qu'elles étaient totalement séparées de la prod... à l'exception des boîtiers Altéon complétement poussifs qui coincent à 1.000 sessions la minute !!! Trois minutes pour configurer le regex, c'est vraiment rapide à côté du temps que prenait la rédaction du script Perl.

Trouver des Race condition est une promenade de santé, bien que la dernière version de PeopleSoft Enterprise Human Capital Management nous a résisté durant près de 10 heures. Mais, avec seulement une dizaine de fonctionnalités utilisées (sur une centaine) et surtout aucun code-maison qui ne s'écarte des putains de variables liées à trois étages façon Dev-Oracle-Next-Generation, nous n'avions aucune chance. Heureusement que la clôture d'un compte suite à un brute force possédait une petite subtilité sur la page de résultat en cas de réussite... sinon, nous étions marrons pour cette appli. !

Heureusement que PeopleSoft et un Oracle 10g release 2 (qui se faisait passer pour du 9i, selon notre client et ses développeurs en tout cas) n'étaient pas les seuls plats au menu de ce pentest. Nous avons pu nous gaver de la partie Web de Business Object et d'appli partagées sur un cluster Domino de folie...

Au final, passer de l'autre côté du miroir est vraiment sympa. Si sympa, qu'il faudra me faire violence pour que je retourne faire de l'analyse forensic pour besogneux !

Jeu des 7 erreurs au Microsoft Technology Center de Paris

2008-02-11T17:56:00.000Z

En feuilletant le numéro de ce mois-ci d'IT Pro Magazine (fourni gratuitement aux visiteurs des TechDays 2008), je suis tombé (à la page 7) sur une pub d'EMC qui a pour illustration le Data Center parisien de Microsoft.

Un auditeur à l'œil exercé doit relever plus de 7 erreurs. Voici les trois premières :

le plus facile : un super exemple de câblage chaotique, façon spaghetti. C'est ce genre de détail qui rend les audits de conformité si rapides...
les dalles du plafond sont pas alignées avec celles du sol (les baies non plus...) : la pièce n'a pas dû être pensée pour un Data Center, mais plutôt pour de simples bureaux. Les problèmes d'infra doivent être sérieux.
les baies du fond ne sont pas alignées avec les autres : le système de climatisation ne doit pas être optimal. Affaire à creuser...

A vous de trouver les autres...

Un Tilda/yakuake pour Windows XP ?

2008-01-10T01:01:00.000Z

Vous en avez marre des adorateurs du Pingouin qui se trémoussent toute la journée devant leur magnifique console "super utile ki tue lorsque j'appuie sur F12" ?

Rabattez-leur le bec avec un mélange de console2 (en mode transparent) et AutoHotKey. Ce dernier aura un script AutoHotkey.ahk forgé spécialement pour les effets Quake-like.

Bon, si vous ne voulez pas passer une nuit là-dessus, visitez l'excellente page suivante : instructables.

Et voila. Il vous reste simplement à vous dégoter Power Desktop Manager pour les bureaux virtuelles et une dose résonnable d'utilitaires cygwin pour ne pas trop retourner sur votre Linux en double-boot durant les pentests rapides.

Bon, c'est vrai, je vois déjà certains me dirent que cela ne tourne pas sur lui-même en 3D avec des flammes... Mais, vous pourrez dormir durant le trajet du retour après avoir torché en une heure votre compte-rendu d'audit doté d'un magnifique plan au sol de data center en fausse 3D (merci Visio), alors que vos collègues essairont d'y inclure leur prose tordue sous OpenOffice avec des images kivio qui ressemblent à des planches de BD de l'école Franco-Belge des années 50 ;-)

Travailler plus pour d'avantage de Peur !

2008-01-09T18:00:00.001Z

Il y a quelques années, j'ai pris la sage décision de ne plus jamais prendre de résolution à cette période de l'année (et aux autres périodes à l'occasion !). Donc, rassurez-vous, je n'ai pas pris la résolution de faire revivre ce blog moribond... J'avais simplement envie de m'épancher un peu. Voila tout.

Newsoft m'a demandé le mois dernier de préparer une présentation sur un sujet exotique : la sécurité des systèmes SCADA. J'ai découvert ce domaine l'année dernière, à l'occasion de mon changement d'emploi. L'informatique industrielle est, d'après ma petite expérience, un monde quasi vierge pour la SSI (au sens qu'il n'a pas encore été pollué par des études savantes sur les menaces et par des usines à camemberts de gestion du risque).

Voila pourquoi, jusqu'à présent, je me suis toujours demandé si ce domaine pouvait intéresser quelqu'un d'autre qu'un SEC-geek en mal de nouveautés et qui n'avait pas envie de faire des audits de DSI bancaires consistant pour l'essentiel à vérifier la bonne séparation des tâches dans les immenses départements de ces monstres bureaucratiques...

J'ai donc été étonné, hier, en découvrant un article de MISC abordant ce sujet. Cette revue - bien que trop académique à mon gout (je n'ai pas eu le courage de continuer jusqu'au doctorat, mais mon voisin de bureau est l'un des heureux abonnés...) - est sans doute la plus méritante de la presse professionnelle française dans le domaine de la SSI.

J'ai généralement beaucoup de respect pour les auteurs d'articles de fond. Dans la presse française, ceux de MISC sont en fait de véritables ovnis comparés aux pisses-copies qui traduisent mal du tchèque ou font de la promotion-déguisée pour des feuilles Excel à 50.000 euros (sensées vous amener à la certification 27.001).

A l'occasion, je vous narrerai un jour mon amour immodéré des pseudo-logiciels SSI dont les questionnaires débuttent toujours par la célèbre ritournelle : "Possédez-vous une politique documentée qui...". Mais, dans notre milieu, il est très mal vu d'affirmer qu'un consultant sénior, qui s'évertue durant quatre jours à poser ce type de questions à un pauvre RSSI nouvellement promu, a en fait l'intention de passer l'hiver au chaud, à tricoter des politiques (F7+"nom de la boîte") chez ce client trop naïf ou trop imbu de son immense responsabilité...

Toujours est-il que j'aurais dû me méfier lorsque les auteurs ont commencé à disserter sur les affreux hackers sociopathes payés par la mafia qui ont créé une véritable industrie du malware ! L'analogie de l'usine pour parler de moins de 10.000 lignes de codes m'a toujours fait rire. Il faut dire pour leur défense que la vie de douze développeurs sans vie sociale, qui ne se sont peut être jamais rencontrés en chair et en os, peut difficilement déboucher sur un scénario oscarisable... Quant à un livre à sensation sur la cybercriminalité, il faut voir !!

Je n'ai plus l'article sous les yeux, donc je ne pourrais pas vous en faire une critique constructive. De mémoire, il continuait avec plusieurs pages de la même veine. Je me souviens d'anecdotes douteuses sur les marchés moscovites (où l'un des auteurs a dû se faire arnaqué après avoir acheté un dvd de Windows 2008, ou peut être l'un de ses amis journalistes d'investigation, qui sait...). Mais, là n'est par l'important.

La presse SSI regorge de ce type d'articles sans imagination, dont l'objectif premier est de disserter sur la Peur. Si ce blog était une tribune politique, je pourrais vous sortir un truc du genre : "dans nos sociétés, la peur est très bonne pour la consommation, qui elle même est le terreau du matérialisme, berceau de toute Peur."

Car, en fait, je peux désomais l'avouer à vous mes trois lecteurs qui se donnent la peine de lire tous mes posts jusqu'au bout : l'objectif caché de ce post faussement technique est de répondre à la question suivante : "Un français peut-il hébergé son blog chez google et nommé un post travailler plus pour d'avantage de Peur". La réponse dans quelques jours, peut être... ;-)

Pour revenir à cet article, le truc qui m'a finalement consterné est que les auteurs ont gardé la même approche pour aborder les systèmes SCADA. Apparemment, leur connaissance de ce domaine se limite à la projection du dernier Die Hard et un googling des présentations BlackHat commerciales (il faut dire pour un public d'opérationnels pour être à la page) appartenant aux quelques boîtes qui ont été grassement payées par Bush pour pondre des signatures SCADA. Vous me direz : tout ça pour vendre des scanners de vulnérabilités et des IDS aux industriels américains qui doivent également participer à l'effort de guerre contre le terrorisme ! Mais là, c'est vous qui commencez à faire de la politique. Attention !

Je ne vais pas vous faire un cours de géopolitique, mais si, ni les bedonnants de la CIA avec leurs valises de pétrodollars ni les satellites en platine de la NASA ne peuvent venir à bout d'un groupe de cinq post-doctorants chimistes ayant atteint le point de non-retour du dégout social, ce n'est pas une sonde IDS qui va les arrêter. Mais il faut avouer que les explosions d'usines passent beaucoup mieux à l'écran qu'un ERP sous AIX qui formate ses librairies.

Ce que je leur reproche le plus, c'est de ne pas avoir rassuré le public français sur la réalité des systèmes SCADA en Europe. Car, contrairement aux US où l'administrateur moyen à cinquante ans et est payé au tarif du consultant sénior français alors que les coms locales sont gratuites, les véritables systèmes SCADA en Europe sont quasiment inexistants, car non-rentables, et utilisent des réseaux vraiment dédiés.

D'après moi, les seuls systèmes contrôles-commandes européens qui présentent un attrait sont actuellement ceux des boîtes de maintenance qui sont en train, grâce aux techno DSL, de se rapprocher des réseaux où évoluent les systèmes critiques. Mais heureusement, peu d'entre eux sont administrés de manière nationale, encore que...

Cet havre de paix n'est pas le fruit de la grande sagesse des sociétés européennes, mais est simplement dû au coût de notre main d'oeuvre (les jeunes sysadmins) comparé à celui exorbitant de nos Télécoms. On peut donc remercier la non-gratuité de la téléphonie locale en Europe (et en particulier en France) pour nous éviter un scénario catastrophe à la Die Hard. N'en déplaise aux Cassandres de ce début d'année (et je ne parle pas de ma Cassandra qui se contre-fout de tout cela), tant qu'il y aura des jeunes sysadmins prêts à travailler plus, nous pourrons dormir tranquille .

Voila, bonne année tout de même.

Sur les publications en sécurité informatique et l'anonymat

2007-10-05T19:42:00.000Z

Pour raviver mon blog, voici un article des plus narcissiques. Je vous aurais prévenu...

Je tiens tout d'abord à contredire les rumeurs qui pèsent actuellement sur mon existence : Nan, je ne suis pas mort ! Et non, je ne suis pas tenu au silence par mon nouvel employeur...

C'est juste que la découverte de nouveaux domaines (SCADA et autres domaines de l'informatique industrielle) ne me permet pas, pour l'instant, de réaliser des articles satisfaisants qui puissent avoir un quelconque intérêt pour mes trois lecteurs référencés.

En tant que maître persiffleur, je rajouterais d'ailleurs que je ne suis pas payé, moi, à faire de la veille ou de la R&D... (calme toi News0ft, c'est juste un effet de manche pour avoir des remarques dans mon blog)

J'en profite pour réagir à la réponse d'Hervé à Cédric au travers la lettre mensuelle de sa société (mes trois lecteurs comprendront. Les autres ne me lisent pas de toute façon !! Je tiens à devenir de plus en plus cryptique au fil de mes articles. C'est un moyen de passer à la prospérité dans quelques siècles parait-il ! ;-))

Bon, je reprends. Je disais que j'étais d'accord avec Hervé sur le mythe bidon de la double-vie des professionnels de la SSI. Il alimente depuis des années les légendes à la greyhats qui pourrissent notre profession et l'empêche de devenir véritablement adulte.

Alors, me direz-vous, pourquoi écrire sous un pseudo et ne pas m'afficher librement et assumer mes écrits ??

Bonne question n'est-ce pas ! Ma réponse est toute simple : tout article, aussi savant et brillant soit-il fournit des renseignements précieux sur les domaines que ne maîtrise pas son auteur ! Lorsque cet auteur est responsable SSI ou acteur SSI majeur d'une entreprise, il s'agit d'informations de première main pour tout assaillant.

Dans le même registre, Il m'arrive encore d'aller chercher (sur google ou auprès du client avec une technique de relation sociale pour ingénieur [j'adore cette traduction littérale, vue sur intranet !!]) la liste des sociétés de la profession qui se vantent d'avoir auditer ou sécuriser un futur client. J'aime alors prendre le temps de référencer les systèmes et les thèmes qui semblent ne pas être la tasse de thé des dites sociétés. Vous devez avoir déjà essayer, le recoupement est souvent édifiant...

D'ailleurs, lorsque l'on connait les penchants risibles de certaines écoles en SSI pour d'étranges systèmes d'exploitation supposés ultra-sûrs, mais absolument pas déployés dans le monde réel (je ne donne pas de nom, les cibles sont trop évidentes...), il y a de quoi s'amuser de nombreuses années encore, en écoutant les réunions des professionnels de la profession. Ce n'est pas News0ft qui va me contredire...

Voila, pour ce soir. C'est court, mais c'est un blog et j'ai plein d'autres trucs à faire (récupérer des heures de sommeil, par exemple). J'espère simplement que mes trois lecteurs comprennent désormais mieux la raison de mon semblant d'anonymat. Et oui, ce n'est peut être pas uniquement de la pure schizophrénie (tiens, un mot de plus de trois syllabes. Je m'améliore ;-))

La "récente" évolution des systèmes SCADA

2007-07-15T01:18:00.000Z

Jusqu'au milieu des années 90, les systèmes SCADA n'ont que peu évolués. Présents dans toute l'industrie, surveillant les chaînes de montage, les centrales électriques, les systèmes de production et de distribution d'eau, gaz ou pétrole, les installations portuaires... ces systèmes spécialisés étaient bâtis à partir de mini-calculateurs dédiés (les PLC : programmable Logic Controler) chargés de récolter l'information et de l'envoyer sur des liaisons de 1200 bauds à des terminaux distant RTU (Remote Terminal Unit), eux même controlés par un MTU (Master Terminal Unit). Ces RTU ne possédaient alors aucune intelligence et n'avaient aucune interaction avec d'autres systèmes d'information.

Alors, que s'est-il passé pour que ces systèmes isolés, compartementalisés deviennent des architectures réseaux classiques qui utilisent des liaisons T-1, de l'Ethernet, du wifi et même des liaisons Internet non-protégées ?

Ma théorie est que ces systèmes ont souffert des mêmes causes qui ont permis à nos SI de la Défense de devenir vulnérables aux maux de l'Internet : la réduction des coûts et la volonté des hauts responsables d'avoir une vue temps réel du terrain (le tableau de bord avec des camemberts qui clignotent en continu) !!

L'évolution technologique majeure s'est passée au niveau des RTU. Ces équipements dédiés et monofonctions se sont peu à peu transformés en logiciels multifonctions chargés sur des systèmes d'exploitation grand public (MS Windows, Linux). Ce changement a permis de réduire considérablement l'implémentation de ces RTU qui se sont dotés des éléments logiciels suivants :
- les DPA (Data Processing Applications) permettant la reprogrammation du RTU et l'ajout d'une GUI possèdant un accès utilisateur.
- les DCA (Data Collection Applications) permettant l'intégration de données collectées sur de nouveaux contrôleurs
- une base de données...

Cette évolution a cependant eu un cout caché phénoménal : ces systèmes de contrôle industriels, hier isolés et utilisant des équipements propriétaires, sont désormais vulnérables à tous les maux qui visent nos simples PC.

Et oui, l'une des premières surprises que j'ai eu en découvrant les systèmes SCADA a été de contempler le célèbre logo "TUX" sur un boitier RTU qui surveillait les vibrations de la pompe d'un système de refroidissement ultra-sensible. De tels boitiers sont généralement disséminés sur l'ensemble d'un site et sont interconnectés via un réseau Ethernet partagé ou un réseau wifi.

Même si je suis loin d'être un adepte de la grande peur de l'après 9/11, j'ai quand même eu quelques sueurs froides lorsque j'ai commencé à étudier la dizaine de protocoles utilisés par les systèmes SCADA : ces protocoles n'ont pas du tout été pensés pour partager un réseau d'entreprise avec d'autres systèmes d'information. Je me suis alors pencher sur les RTU, et la situation m'a paru désespérée : ces systèmes, bien que bâtis sur du MS Windows classiques ou du Linux, ne sont jamais patchés et il existe même des clauses constructeurs qui interdisent toute mise à jour du système d'exploitation !

Mais, je garde le meilleur pour la fin : la "mentalité particulière" des ingénieurs de l'industrie. En tant que consultant Infosec, on trouve parfois difficile de persuader un ingénieur IT de mettre en place un système de bascule de serveurs afin de pouvoir patcher (et rebooter pour MS Windows) un système critique. Avoir la même démarche avec un ingénieur industriel est une mission impossible. En effet, la mise à jour d'un RTU signifie souvent l'arrêt d'une pompe d'une central électrique ou la fermeture d'un pipeline. Vous imaginez les centaines de millier d'euro perdus à chaque Black Tuesday !!

Bref, la sécurisation d'un système de contrôle industriel passe essentiellement par la conception du système lui-même et surtout par une énorme campagne de sensibilisation des ingénieurs industriels. Et là, nous avons du boulot pour une bonne dizaine d'années...

Voila pour une petite mise en situation de l'infosec pour systèmes SCADA. Si cela intéresse l'un de mes trois lecteurs, je vais continuer et réaliser des descriptions plus détaillées. ;-)

Changement de disciplines en vue...

2007-06-27T01:46:00.000Z

Ayant changé de job au début du mois, je n'ai actuellement plus la possibilité de pratiquer le live forensique et la réponse aux incidents. D'où ce silence assez long...

J'avoue qu'il m'est même venu à l'esprit de fermer ce blog après le SSTIC (évènement qui a sonné le glas de mon anonymat... pour ceux, bien sûr, qui se donnent la peine de lire un papier jusqu'à sa 26e page !)

En fait, je ne désespère pas de trouver un jour une mission intéressante dans ces domaines et je vais d'ailleurs m'y employer dès la semaine prochaine (reste à faire une prés' sur le sujet ce weekend)

En attendant cet heureux jour, je vais m'adonner aux missions classiques des consultants Infosec : audit, pentests, stratégie de sécu, architectures, plans de progrès ou de changement... Rien de bien passionnant, encore que cela faisait des années que je n'avais pas pratiqué. Je m'efforce tant bien que mal de placer de temps à autre mes idées et ma touche personnelle, bien que pas grand chose puisse être inventé dans ces disciplines usées jusqu'à la corde.

Après quelques discussions, je crois avoir trouvé un domaine intéressant dans le domaine de l'audit et du pentest : les systèmes SCADA. Nous touchons là un territoire qui m'était complètement inconnu voila encore quelques semaines. C'est en fait à des kilomètres du serveur Oracle en back-office qui semble faire saliver les premières années Epitec (ils se reconnaitrons).

Après avoir pris quelques avis, il semble qu'il s'agisse d'un territoire quasiment vierge pour l'Infosec. Le fait est qu'un certain nombre d'expériences en la matière se sont mal déroulées. Il coure sur le sujet des légendes très croustillantes : redémarrage complet des chaînes de production d'une usine automobile après un scan nmap mal ficelé, infrastructures critiques isolées pour l'éternité de toute téléadministration et de toute mise à jour, suite à un simple connect' mal placé...

Les systèmes SCADA se révèlent être un sujet super épineux, que cela soit par la difficulté des pentests ou encore par la paranoïa outre-atlantique dont ils font l'objet (Homeland Security...). Il convient donc de les aborder avec un oeil neuf. Cela tombe bien, je me suis écarté des pentests et des audits depuis suffisamment longtemps pour essayer de tenter d'autres approches.

La pratique du forensique et la chasse aux hackers m'ont appris la furtivité, qualité qui manque trop souvent aux pentesteurs de base qui ne jurent que par les scans de vulnérabilités et la grosse artillerie... (je vais encore me faire des amis ;-))

Pour débutter en la matière, il faut que je trouve du temps pour la mise au point d'un scanner passif (sniffer+reconnaissance de motifs sur bannières et autres infos clés) qui me coute moins de 10.000$, afin de répertorier rapidement, mais grossièrement les systèmes les plus vétustes.

Le plus difficile, sans doute, sera de trouver des clients pour ce genre de manip', d'autant qu'en Europe ces systèmes ne soient pas légions. Il est vrai que les techniciens européens coutent beaucoup moins chers que leur homologues étasuniens et que, par conséquent, la téléadministration de systèmes critiques n'est pas très répandue.

Au final, cela reste tout de même un beau sujet pour un stagiaire désirant s'essayer aux micro-controleurs et aux protocoles SCADA ou encore un sujet exotique pour le prochain SSTIC ! Avis aux amateurs...

Deux pistes sérieuses pour le live forensique

2007-04-22T23:16:00.000Z

Chose promise, chose due, voici enfin un article faisant la preuve de mon intérêt constant pour le live forensique.

Le RFC 3227 - Guidelines for Evidence Collection and Archiving recommandait, dès février 2002, que le premier élément de preuve à récolter dans le cadre d'une enquête forensique était la mémoire physique (la RAM) du système suspecté. Si le recueil de cette mémoire physique est peu à peu rentrée dans les procédures forensiques et de réponse aux incidents (IR), son analyse, quant à elle, reste problématique.

Lorsque j'ai quitté mon équipe IR voilà trois mois, cette analyse n'était réalisée qu'en cas de besoin impérieux de retrouver des mots de passe, adresses IP, adresses de messagerie ou URL, permettant de confondre un suspect contre lequel de fortes présomptions existaient. Pour cela, le binôme IR utilisait les outils strings et grep pour retrouver de tels éléments de preuve. L'analyse la plus "poussée" consistait alors en une exploration rapide sous bintext des mégaoctets de l'image de cette mémoire physique, afin de relever les chaînes de caractères ASCII pouvant avoir une quelconque utilité.

L'été 2005 avec son challenge forensique du DFRWS (Digital Forensic Research Workshop) a marqué une révolution pour les chercheurs INFOSEC de la planète qui se sont pris d'intérêt pour le live forensique. Sur le terrain, c'est en fait la tendance lourde des codes malveillants (virus et rootkits et autres malwares de dernière génération) à empêcher leur analyse statique via les techniques anti-forensiques qui ont amené les équipes IR et les enquêteurs forensiques à vouloir se doter d'outils puissants pour analyser efficacement cette mémoire physique, seule détentrice d'éléments non chiffrés (non-cryptés, pour utiliser un anglissisme) de ces malwares.

L'année 2006 a vu l'apparition publique des premiers outils d'analyse live fonrensique. Les uns bâtis sur l'accès à l'objet \Device\PhysicalMemory, les autres s'appuyant sur le contenu du fichier crash dump généré par les systèmes Windows après un BSoD (Blue Sreen of Death). Deux problèmes techniques sont actuellement à prendre en compte pour le choix d'une de ces familles d'outils :
- à partir de la sortie du service pack 1 de MS Windows 2003 (printemps 2005), l'objet \Device\PhysicalMemory n'est plus accessible à partir du mode utilisateur
- à l'exception de Windows 2003, les systèmes MS Windows génèrent par défaut un crash dump de taille insuffisante (il en est de même pour Windows Vista RC1)

Après avoir fait le tour de quelques outils, ma préférence va à la famille bâtie sur les crash Dump. Il est vrai qu'elle convient d'avantage à une équipe IR qui peut se permettre d'imposer de grandes images crash dump aux serveurs MS Windows sous sa responsabilité, plutôt qu'à un enquêteur forensique envoyé auprès d'un quelconque système suspect. Voir pour cela l'article de la base de connaissance Microsoft ici.

Afin d'affiner mon expérience en la matière, je pense à très court terme (dès la semaine prochaine) travailler sérieusement sur les deux pistes suivantes :
- l'outil Kernel Memory Space Analyzer de Microsoft
- une extraction à l'aide de l'outil LiveKD.exe et sa commande .dump /f fichier-dump.dmp à partir d'un système distant ou d'un système dont la fonction ou la fragilité le rendent impossible à crasher.

D'ici là, il me reste à préparer le TOEIC que je passe à la fin de cette semaine ! ;-)

Sur la perception

2007-04-20T01:57:00.000Z

Ayant quitté mon équipe IR depuis plus de trois mois, je me prends à philosopher par manque de cas croustillants à me mettre sous la dent (une des raisons pour lesquelles je délaisse ce blog, sans aucun doute). La vieillesse me gagne peut-être ou serait-ce l'ennui ??

Devant rapidement trouver un nouveau job pour nourrir ma petite famille, j'ai dû réviser mes classiques INFOSEC, afin de ne pas sécher bêtement devant une question basique. En effet, après une vingtaine d'entretiens, je n'ai eu aucune question relative au live forensique ou à la réponse aux incidents ! Il faut dire que ces sujets semblent d'avantage faire partie de la recherche expérimentale que des bonnes pratiques ITIL ou autre standard à la mode... Toujours est-il qu'en révisant ces fameux classiques, j'ai eu soudain un doute vertigineux vis à vis des fondements même de l'INFOSEC tels qu'on me les a enseignés voilà plus de dix ans.

Lorsque j'étais encore étudiant en mathématiques appliquées (voila deux éternités...) j'ai subi la torture mentale infligée par un spécialiste de la logique formelle. Outre de violentes migraines, je me souviens essentiellement du théorème de Gödel, qui démontre l'assertion géniale suivante : "Au sein même d'un système, il est impossible de démontrer logiquement les points de départ."

Pour l'INFOSEC, cela peut signifier que les définitions de base (la sécurité, l'équation du risque, les menaces...) sont uniquement de simples perceptions et des valeurs arbitraires !

Or, lorsque l'on connait la part non négligeable qu'ont pris les spécialistes de l'assurance financière dans la genèse de l'actuelle doctrine INFOSEC, notamment dans la gestion des risques, il y a lieu de s'inquiéter. Pour s'en convaincre, il suffit de passer en revue les méthodologies d'analyse de risque à notre disposition. En France, EBIOS et Mehari sont des exemples flagrants de systèmes pseudo-scientifiques - si courants dans l'analyse financière - qui sont bâtis sur du vent et dont le résultat ne repose que sur l'expérience et le pragmatisme de celui qui les met en oeuvre. Ce qui requiert une compétence très poussée en programmation neuro-linguistique. ;-)

Je connais une bonne dizaine de définitions du concept de sécurité appliqué à l'INFOSEC. Cependant, celle que je préfère n'est préconisée ni par les instances de standardisation, ni par notre très haute autorité française : la DCSSI. Il s'agit tout bêtement d'une définition utilisée depuis une trentaine d'années dans le monde du renseignement qui, contrairement au monde de l'assurance financière, possède un encrage évident dans la réalité. Cette définition est la suivante :

La sécurité est le processus du maintien du risque perçu à un niveau acceptable.

Rien de bien nouveau me direz-vous, il fait simplement de l'esbroufe, sachant qu'il n'a plus grand chose à dire sur le sujet du live forensique. Peut-être, bien que je garde encore quelques cartes dans ma manche... Mais, il y a une notion qui peut paraître anodine au premier abord dans cette définition, mais qui change pourtant toute la donne. Il s'agit de la perception.

Pour un esprit français, baigné depuis sa plus tendre enfance dans la logique carthésienne, la dialectique et le raisonnement, la perception reste un élément secondaire de la réflexion. La pensée critique reste le nec plus ultra en Occident, et surtout dans notre beau pays. Il suffit pour cela d'écouter, même d'une oreille très discrète, les derniers discours de la présidentielle...

La perception est pourtant une clé, et même la clé, pour comprendre le concept de sécurité. Pour un analyste INFOSEC, la perception est la partie la plus importante de sa réflexion. En fait, toutes les erreurs que j'ai rencontrées avec mon équipe IR provenaient d'erreurs de perception, dues très souvent au stress, au manque de sommeil et surtout à une trop grande précipitation. En pratique, les erreurs de logique sont rares dans l'analyse INFOSEC. Malgré tout, nous avons appris en tant que fiers enfants de Descartes que réfléchir consiste uniquement à éviter les erreurs de logique.

Ainsi, si l'on s'attache à la perception du risque et non simplement au risque dans un système absolu, on peut alors se concentrer sur les menaces et non plus uniquement sur les vulnérabilités. Lorsque l'on observe les listes de diffusion INFOSEC que cela soit dans notre pays ou encore dans les pays anglosaxons, on voit que la majorité de notre attention est focalisée sur les vulnérabilités découvertes par les chercheurs INFOSEC.

Pour ne pas ajouter un troll à mon actif (et surtout pour ne pas blesser la susceptibilité d'un de mes uniques lecteurs), je tiens simplement à dire qu'il est vain de courir après toutes les vulnérabilités que l'on nous sert chaque semaine. Il faut en fait se concentrer sur les menaces qui nous concernent, comme le font les professionnels du renseignement depuis des années.

Mon expérience en la matière est que l'étude des groupes possédant la capacité et l'intention de nuire à une organisation est bien plus importante (et bien plus utile) que d'essayer de patcher toutes les vulnérabilités qui apparaissent. Il suffit pour s'en convaincre, de faire une pause en reconsidérant les dernières vulnérabilités zéro-days qui viennent d'être publiées à la veille de nombreuses mises à jour de produits de sécurité et des conférences INFOSEC printanières (Oups, j'ai encore trollé :-).

L'étude de tels groupes reste très confidentielle. J'ai relevé dernièrement un post assez proche de cette thématique ici. Si vous en connaissez d'autres, je suis preneur.

Faut-il se préparer à la "dématérialisation des malwares" ?

2007-03-16T00:20:00.000Z

Si le recueil de la mémoire physique nous permet d'obtenir un élément de preuve solide de la présence d'un malware, encore faut-il pouvoir l'étudier avec précision afin de répondre aux éternelles questions que sont les Quoi, Quand, Où, Comment et même les Pourquoi et Qui.

En l'état actuel de mes connaissances, je reste dans l'attente d'un outil de live forensique vraiment opérationnel, mitonné par l'un de nos chercheurs INFOSEC (et oui, je les adore, en dépit de mon odieux troll précédent !!). En ce moment même, je me surprends à scruter avec anxiété les programmes des futures conférences INFOSEC, à la recherche de la perle rare. Je me suis même inscrit sur fond propre au SSTIC, afin de ne pas manquer une présentation très prometteuse sur le sujet. Il faut dire que j'ai loupé les deux dernières éditions...

J'ai la conviction que le recueil de la mémoire physique va devenir la méthode la plus puissante et surtout la plus rapide pour vérifier la présence d'un malware sur une machine suspecte. Le seul bémol est qu'il nous faut aujourd'hui trouver un moyen d'accès à l'objet \\Device\\PhysicalMemory sur les nouveaux systèmes MS Windows (post 2003 SP1).

En fait, beaucoup critiquent le live forensique en affirmant que rien ne vaut le RCE (Reverse Code engineering) en compagnie d'Ida et d'Olly et de tous leurs copains plugins, et que, de toute manière, l'image obtenue par le recueil de la mémoire physique est tellement déformée, qu'elle est inexploitable dans la vrai vie.com !

J'utilisais essentiellement le recueil de la mémoire physique dans le cadre de procédures IR, et non pas pour étudier à fond un malware. Mon objectif, alors, était uniquement de confirmer sa présence (on ne fait pas dans la dentelle, lorsque l'on ne dispose que de 50 minutes). Je ne pratique plus l'IR depuis plus d'un mois et me limite aujourd'hui à l'étude de spécimens "en dur" à l'aide de bonnes vieilles techniques de RCE. C'est déjà pas si mal, et cela me permet surtout de me tenir informé des nouvelles tendances.

Mais, il me vient toujours en tête le cas hypothétique du "malware tout en mémoire", forgé spécialement pour une victime particulière et qui surtout n'a jamais été diffusé à grande échelle ! Vous me direz qu'un tel animal si dématérialisé ne coure pas les rues et que, de toute façon, tout ce qui est en circulation provient de POC connues et reconnaissables (Proof of concept et non Point Of Contact...).

Mais, imaginez que cela devienne la norme ! on ne pourrait plus en attraper un dans un honeypot ou dans l'enregistrement d'une cession TCP non chiffrée réalisé par son IDS favori (Snort et Sguil le font très bien, même si Sguil est une véritable galère à installer sur Linux). Nous n'aurions plus alors que son image en mémoire physique pour l'étudier, à la condition que nous disposions des procédures IR adéquates. Ce qui est encore loin d'être le cas partout...

De la guerre de l'information

2007-03-05T01:17:00.000Z

La sécurité n'existe pas dans la nature. Aucun animal ne serait assez fou pour se sentir hors de tout danger. Nous sommes l'unique espèce connue qui pense être en mesure de trouver le bien-être à travers la technologie ! Quelle gloire...

J'ai trop souvent rencontré de ces professionnels de l'INFOSEC - adeptes forcenés de cette croyance - qui investissaient des sommes folles dans les derniers équipements INFOSEC à la mode, à la joie des équipementiers de tout bord. Il est vrai que les gourous de la prospective technologique ne connaissent aucune limite, tant la loi de Moore est ancrée dans nos mentalités.

Cependant, concernant l'INFOSEC, je suis de plus en plus agacé par cet engouement idiot de la nouveauté ! Mon opinion est que nos chers spécialistes de la prospection INFOSEC - connus en France sous la superbe appelation : Chercheur en sécurité informatique - devraient d'avantage se pencher sur l'engouement inquiétant pour les pratiques de la guerre de l'information que sur les toutes dernières technologies que sont actuellement la virtualisation (le nième retour du mainframe) et les VoIP-ToIP (la convergence ratée par le RNIS/ISDN voilà quelques années, faute d'un leader gargantuesque comme Cisco).

L'explosion des activités d'intelligence économique masque mal des comportements douteux rappelant d'avantage une Sale Guerre qu'une mission de casques bleus... La transposition des techniques guerrières à l'économie n'a malheureusement pas été suivie du code éthique qui doit les accompagner pour ne pas tomber dans une application littérale de la loi du Talion. Et ce n'est pas la lecture de Sun Tzu par nos capitaines d'industrie qui va inverser la tendance !

La guerre nous apprend que la véritable force ne réside pas dans notre capacité à accroître le degré de violence, mais dans celle de la maîtriser.. Au delà du cliché de la frappe chirurgicale, pratiquer une guerre de l'information raisonnée pourrait simplement signifier savoir répliquer en limitant au maximum notre degré de violence.

Pour ne pas être une victime, le mieux est de ne pas paraître vulnérable. C'est le vieux concept de la dissuasion. Une bonne sécurité passive est ici l'un des meilleurs moyens que je connaisse. Encore faut-il avoir mener une analyse de ses vulnérabilités et un changement drastique des mentalités.

Concernant cette dernière tâche, mon axiome préféré - appartenant à la guerre de l'information - est le suivant : "Si vous ne pouvez pas protéger vos informations, vous ne pouvez pas les partager." Il est vraiment simpliste, mais je suis intimement persuadé que s'il était vraiment mis en pratique par nos armées d'opérationnels, on compterait moins de cyniques ou de dépressifs dans les rangs des pro de l'INFOSEC...

En dernier ressort, reste la loi. Les délinquants en col blanc réflechissent à deux fois avant de vous attaquer, si vous avez fait la preuve que vous êtes en mesure de saisir la justice avec efficacité ! Et voila, je suis retombé sur les thèmes de la réponse aux incidents et le forensique - cqfd...

De l'initiative dans la résolution d'une crise

2007-03-05T00:48:00.000Z

Chaque individu possède une dose de créativité, fonction de sa personnalité (inné) et de son adaptation au terrain (acquis). Cette créativité s'exprime dans les initiatives de chacun et forme, selon mon expérience, la source de la performance de toute équipe.

Or, j'ai trop souvent observé des chefs d'équipe - généralement aguerris - tuer dans l'oeuf une initiative au nom de la sacro-sainte urgence de la crise. Il est vrai que les initiatives doivent être régulées pour ne pas mettre en péril une mission. Mais, il convient de ne pas confondre crise et urgence !

Ce qui caractérise une crise, c'est justement le fait que les solutions "classiques" ne fonctionnent pas et qu'il est vital d'être créatif pour pouvoir s'en sortir. Pour ma part, je pense qu'il faut toujours encourager une initiative relevant d'une tâche individuelle (ou relevant du binôme IR). Elle atteste généralement de la qualité de son auteur, et doit être relevée pour le debriefing de fin de crise.

Par contre, je pense qu'une initiative relative à la procédure générale de l'équipe IR ne doit généralement pas être tentée directement au cours d'une crise. Mais, elle mérite également d'être notée et surtout de faire l'objet d'une évaluation approfondie lors du debriefing. Si elle s'avère pertinente, elle devra être mise à l'actif de son auteur, faisant la preuve que chacun peut améliorer le fonctionnement de l'équipe. Dans le cas contraire, le debriefing devra démontrer les difficultés de sa mise en oeuvre.

J'entends ici par debriefing, ou retour d'expérience, l'analyse d'un évènement dans lequel l'équipe IR a été impliquée ou non. L'objectif est de décortiquer l'évènement, généralement complexe, pour en comprendre toutes les facettes. Le debriefing fait partie des bonnes pratiques à mettre en place, et pas uniquement dans les équipes IR. Cette mise en place ne doit cependant pas s'accompagner de la fin du cycle des examens de situation, qui doivent intervenir très régulièrement au cours de la résolution d'une crise.

Tout l'art du coordinateur IR revient à savoir assoir son autorité sur le partage de l'information et faire déboucher son équipe sur une solution qui recueille l'assentiment général, tout en étant la mieux adaptée aux circonstances. Or, il n'est pas rare en cas de crise - lorsque les informations se multiplient et le doute s'installe - de voir disparaitre le dialogue constructif au profit d'un autoritarisme des plus primitifs !

Là encore, le coordinateur IR expérimenté saura simplement mettre en oeuvre son autorité pour entendre les arguments de ses collaborateurs, identifier les arbitrage à prononcer et surtout obtenir l'adhésion de tous autour de la décision prise.

A titre de conclusion, j'affirme que rien n'est pire que l'absence de décision en cas de crise ! La prise de décision est la justification de la qualité du coordinateur, l'expression ultime de sa compétence. Mais, encore faut-il ne jamais oublier que prendre une décision ne signifie pas imposer sa propre vision du problème.

Au-delà de l'écran bleu

2007-01-22T00:48:00.000Z

L'examen de la mémoire physique reste, à l'heure actuelle, une pratique marginale du forensique numérique. Pourtant, nous pouvons constater chaque jour que les codes malveillants utilisent de plus en plus de techniques, dites anti-forensiques, afin de ne laisser aucune trace sur les disques durs... Au grand malheur des investigateurs forensiques !

Les équipes de réponse aux incidents ont récemment intégré le recueil de la mémoire physique des systèmes Microsoft Windows dans leur procédure de réponse immédiate. Mais les informations obtenues par ce recueil semblent bien dérisoires, face à la somme de données que détient cette mémoire.

Nous sommes actuellement dans une situation similaire à celle des premiers égyptologues qui essayèrent de déchiffrer des milliers d'idéogrammes dont la logique leur échappait. La seule différence est, peut être, que leur auteurs (les développeurs Microsoft) sont bien vivants, mais tenus par des clauses de non divulgation draconiennes. Pour obtenir des brides de savoir, il nous reste à écouter les petits malins qui ont, par exemple, la chance d'avoir sous la main un développeur millionnaire retraité (non, ce n'est pas vrai ! Je ne parle pas de David Cutler) qui adore s'épancher le soir autour d'un verre...

Gestion de la mémoire virtuelle sous Windows

L'une des raisons pour lesquelles il est actuellement extrêmement difficile d'analyser la mémoire physique de tout système d'exploitation moderne est l'incroyable complexité de l'abstraction utilisée pour gérer cette mémoire. La plupart du temps, les données appartenant à un processus sont distribuées de manière complètement aléatoire sur la totalité de la mémoire physique, et également sur le disque dur. Ce qui rend extrêmement difficile la restauration des informations utiles.

En fait, il faut savoir que la gestion de la mémoire est un problème aussi vieux que l'informatique. Depuis plus de quarante ans, les systèmes d'exploitation s'escriment à résoudre le problème de l'allocation de la mémoire physique. Nous allons donc nous concentrer sur les meilleures usines à gaz du moment : les systèmes Microsoft Windows.

Outre leur effroyable complexité interne, les systèmes MS Windows ont l'avantage de constituer l'écrasante majorité des systèmes étudiés durant une investigation forensique. Le véritable challenge dans leur étude réside dans la volonté évidente de leurs développeurs de ne rien documenter sur leur fonctionnement interne. Est-ce d'ailleurs vraiment un bon calcul au niveau sécurité ? Vous n'êtes pas sans savoir que les véritables hackers adorent s'acharner sur ce qui leur résiste !

L'objet \Device\PhysicalMemory a été révélé pour la première fois à la face du monde par Mark Russinovich de Sysinternals (un type qui adore écouter les vieux développeurs autour d'un verre :-)) dans le code source de Physmem. La solution de Microsoft consiste à diviser cette mémoire en un série de pages à taille constante. Cette taille est fixée à 4KB sur les architectures x86 de moins de 4GB de mémoire physique (variable PAGE_SIZE).

La meilleure analogie que je connaisse pour la gestion de la mémoire sous Windows consiste à la comparer à un livre dans lequel chaque page contient un nombre limité de caractères. Dans ce livre, chaque processus possède sa propre table des matières (appelée registre CR3) qui lui permet de consulter les pages qui le concerne. De plus, deux processus possèdent une lecture du livre entièrement différente, chacun d'entre eux croyant être son unique lecteur. Enfin, si un processus peut lire l'adresse mémoire 0x00422211 et y lire le mot "eric", un autre processus y lira le mot "alex".

Chaque processus possède ainsi donc sa propre lecture de l'espace mémoire. Il s'agit du processus de translation de la mémoire virtuelle dans la mémoire physique et le fichier de pagination. Cette translation est possible grâce à la tenue d'une multitude de tables et de registres. Pour simplifier, on peut affirmer que toute l'habileté d'un cheval de Troie réside dans sa capacité à modifier ces tables sans provoquer un écran bleu de la mort (un BSoD pour les anglophiles) !

Premier élément d'analyse de la mémoire : les objets _EPROCESS

Chaque programme tournant sur un système MS Windows se voit assigner un "processus" qui maintient l'état de ses données en mémoire. MS Windows stocke dans la mémoire virtuelle les informations relatives à chacun de ses processus dans une structure du noyau appelée _EPROCESS.

Le gestionnaire de la mémoire des systèmes Microsoft prédéfinit un intervalle de l'espace d'adressage de la mémoire virtuelle au profit des objets du noyau (adresses supérieures à 0x80000000 pour les architectures Intel x86 de moins de 4GB de RAM et supérieures à 0xC0000000 si l'option /3GB a été utilisée lors de l'installation du système).

Nous savons que tous les blocs _EPROCESS de l'ensemble des processus tournant sur un système MS Windows sont liés entre eux dans une double-liste dans laquelle le champ ActiveProcessLinks contient l'adresse virtuelle du prochain _EPROCESS à l'offset +0x088 et le précédent _EPROCESS à l'offset +0x08C.

Malheureusement, trouver l'adresse virtuelle d'un _EPROCESS constitue l'une des difficultés de l'analyse de la mémoire physique. En s'appuyant sur de la recherche de motifs (patterns matching), les outils mem_parser et KnTList réussissent à retrouver l'adresse du _EPROCESS System, bien que celle-ci soit modifiée à chaque redémarrage de la machine. A partir de cette adresse, et grâce à la double liste, nous sommes alors en mesure de retrouver tous les processus qui tournaient sur une machine MS Windows dont on a recueilli une image de la mémoire physique. A l'exception des codes malveillants qui manipulent leurs voisins dans la double liste pour rester invisibles (technique de camouflage DKOM, pour Direct Kernel Object Manipulation).

Deuxième élément d'analyse de la mémoire :la BPD et le PEB d'un _EPROCESS

Une fois tous les processus, qui étaient en fonctionnement lorsque l'image de la mémoire physique a été prise, sont retrouvés par l'adresse de leur _EPROCESS respectif, nous pouvons nous intéresser à chacun d'entre eux en particulier.

La BPD (pour Basic Process Details) fournit un certain nombre d'information sur le processus, dont les plus intéressantes sont les suivantes, classées par Offset :
- +0x018 : DirectoryTableBase qui constitue l'adresse physique de la table des matières de ce processus (Page Directory)
- +0x084 : le PID (l'identifiant) du processus
- +0x088 et +0x08C : les adresses des processus voisins dans la double-liste
- +0x14C : le PPID (PID du processus parent). C'est là que l'on recherche en particulier les processus ayant comme parent cmd.exe
- +0x174 : le nom du fichier binaire (.EXE, .DLL, ...)

Le _PEB (pour Process Environment Block) fait partie des principaux éléments de description d'un processus. Il stocke les données d'environnement du processus en mémoire. Pour accéder au _PEB, une translation doit être réalisée en utilisant son adresse virtuelle stockée dans son objet parent : _EPROCESS. Les informations intéressantes à recueillir dans cet objet sont les suivantes, classées également par Offset :
- +0x008 : adresse virtuelle de l'image de l'exécutable. Une fois sauvegardée, cette image peut être lancée et étudiée à loisir. (il existe des offsets permettant de calculer la taille de cet exécutable)
- +0x00c : adresse virtuelle de la liste des DLL (modules) utilisées par le processus
- +0x018 : adresse virtuelle du tas (Heap) du processus. (une bonne excuse pour se replonger dans les affres de l'assembleur et du reverse engineering...)

La guerre sombre et cruelle du Kernelland

Les rootkits les plus difficiles à détecter sont ceux résidant uniquement dans la partie de la mémoire physique réservée au noyau. Il s'agit d'un terrain de jeu extrêmement dangereux où le moindre faux pas provoque le terrible BSoD.

Afin de rester invisibles aux yeux des logiciels de détection qui scrutent les accès en écriture sur le disque dur, les codes malveillants de dernière génération font en sorte de se faire passer pour un pilote de matériel ou un thread appartenant à un processus noyau qui nécessite de la mémoire virtuelle non-paginable. Pour la dernière solution, il lui faut appeler la fonction ExAllocatePool avec le paramètre NonPagedPool, mais ceci est une autre histoire..

La principale faiblesse des rootkits est qu'ils doivent restés vivants ! S'ils ont été développés pour ne rien écrire sur le disque dur, ils sont donc inévitablement présents en mémoire physique.

Les méthodes d'analyse les plus simples que j'utilise actuellement pour détecter un rootkit dans l'image de la mémoire physique d'une machine suspecte sont les suivantes :
- repérer les processus ayant comme PPID cmd.exe ou explorer.exe
- référencer les adresses inhabituelles de module dans l'Offset +0x00c du PEB. En particulier, les librairies Kernel32.dll et NTDLL.dll. (rootkit utilisant les IAT Hooks)
- faire du reverse sur l'image de l'exécutable et examiner les données du tas du processus (bon là j'avoue que j'ai du mal. Mais je me documente à fond :-)).

L'éthique kantienne contre la fascination du côté obscure

2007-01-19T22:37:00.000Z

Toujours dans le thème du social, nous allons traiter ce soir des problèmes éthiques auxquels une équipe IR peut être un jour confrontée.

Si l'aphorisme du XVIIe siècle : savoir, c'est pouvoir est aujourd'hui évident pour notre société de l'information, l'adage du XIXe siècle : le pouvoir corrompt est une constatation quotidienne des équipes IR.

Quelle équipe IR n'a jamais traité une compromission liée à un problème de moralité ?

Bien entendu, ceci ne signifie pas que le pouvoir est un synonyme de corruption, mais simplement que tout individu investi d'une autorité ou d'une responsabilité peut être tenté de l'utiliser afin d'en tirer un quelconque avantage personnel.

Une déduction immédiate peut être tirée de ces deux affirmations :

Si savoir, c'est pouvoir et si le pouvoir corrompt, alors le savoir corrompt !

Ainsi, la connaissance accroit le risque de corruption. Et c'est là le noeud du problème.

Un membre d'une équipe IR possède les connaissances et le savoir-faire pour devenir un agent extrêmement dangereux, en particulier pour l'organisation qu'il est sensé protéger ! Sa reconversion en blackhat semble très facile :

la même connaissance des vulnérabilités des systèmes d'exploitations et de la plupart des applications, la même utilisation quoditienne d'outils d'analyse et de débogage, et enfin le suivi quotidien des mêmes pages relatives aux derniers rootkits et autres malwares.

En fait, il n'en est rien. Le passage à l'acte est souvent lié chez un individu à une absence de connaissance sur les moyens à la disposition des enquêteurs. Or, peu de personnes sont plus au fait des dernières techniques de forensique numérique qu'un membre d'une équipe IR. Il est également connu que le crime parfait ne résiste jamais à l'amélioration des techniques d'investigation...

Les sommes folles offertes actuellement pour une simple vulnérabilité dans Vista étaient ce matin dans tous les esprits de mon équipe. De tels montants, comparés aux salaires de techniciens, font rêver. Je ne sais plus qui d'entre nous a lancé l'idée d'unir nos efforts afin de rechercher une telle vulnérabilité, puis de monter une société écran dans un quelconque paradis fiscal, afin d'en faire profit...

La conversation a gentiment dérapé vers toutes les actions que l'équipe pourrait entreprendre à son propre profit : détournement de centres de calcul entiers afin de réaliser des rainbow tables, collecte d'informations personnels pour la revente à des spammers ou des list-brokers, renseignement économique... Bref, l'arsenal complet du parfait criminel en col blanc.

Au delà de cette simple conversation, une équipe IR - dont la mission est essentiellement défensive - utilise les mêmes outils que ses adversaires. Ajouté à cela le côté sulfureux de la sécurité informatique, il est alors inévitable que la plupart des responsables soient méfiants vis à vis de toute initiative entreprise par son équipe IR ou son staff chargé de la sécurité informatique. Toujours est-il que notre profession souffre suffisamment de l'ignorance ambiante, pour que nous puissions nous permettre d'avoir une attitude équivoque vis à vis de notre moralité.

En fait, j'ai souvent des pics de violence lorsque j'entends l'un de ces pseudo-hackers/professionnel-INFOSEC laisser supposer qu'il pratique toujours la compromission système à distance, comme un simple passe-temps.

Pour revenir à notre sujet principal, mon autre question d'ordre éthique est la suivante :

Jusqu'où peut-on aller pour stopper ou coincer un assaillant ?

Un coordinateur IR doit constamment s'interroger sur le bien-fondé moral des contre-mesures qu'il fait mettre en place par son équipe : sniffer, pot de goudron, pot de miel (j'adore les termes français pour ces deux là), keylogger... Sur quoi un tel jugement peut-il reposer ?

L'approche la plus simpliste consiste à se convaincre que tout ce qui tient du mensonge, du chantage ou de la tromperie est immoral. Au delà des considérations religieuses (qui ne sont pas ma tasse de thé en cette période de politiquement-correct), je préfère, pour ma part, pratiquer la règle de Kant qui stipule qu'un acte est moral s'il est universel. En d'autres termes, il est légitime de tromper l'assaillant dans des situations où nous admettons que quiconque à notre place serait en droit de le tromper.

Ainsi, l'acte moral s'apprécie en fonction des intentions qui le sous-tendent. Etant donné le caractère confidentielle des affaires qu'elle traite habituellement, une équipe IR ne peut pas s'appuyer sur un quelconque débat public pour justifier du bien fondé d'une de ces actions. Mon expérience fait que je me tiens à la règle suivante : ne déployer que le strict nécessaire de moyens pour stopper ou découvrir les acteurs d'une compromission. Tout en respectant la législation des pays concernés, cela va de soi...

C'est promis, le prochain article sera technique. ;-)

La sociologie des équipes IR ou la libre société

2007-01-17T23:09:00.000Z

Bon, j'ai cinq articles sur le forensique en préparation, et toujours rien de suffisamment abouti pour être présentable en l'état (perfectionniste, me direz-vous ?). Il faut savoir que c'est très long de faire des copies d'écran d'expériences réalisées à la vas-vite...

Faisons donc un peu de social, cela peut se faire sans aucune préparation :

Les méthodologies pratiquées par les équipes IR reposent toutes sur des hypothèses visant à expliquer les informations et les données recueillies. Or, il est souvent possible d'émettre plusieurs hypothèses à partir d'un recueil donné. La première question est la suivante :

Faut-il toujours choisir le scénario le plus simple ?

Un ancien précepte philosophique, connu sous le nom de rasoir d'Ockham, du nom d'un philosophe anglais du Moyen Âge stipule que : Parmi toutes les hypothèses, choisissez la plus restreinte. S'il est possible de ne retenir qu'un élément pour expliquer tel ou tel évènement, écartez le second.

Mais, la pratique de l'IR montre que, fréquemment, le scénario le plus évident n'est pas toujours le plus proche de la réalité. Un bon binôme IR doit donc savoir abandonner ce qu'il avait présumé au préalable et être capable de prendre du recul par rapport au scénario qu'il privilégie. Toute l'expérience du responsable de l'équipe IR (appelé par la suite coordinateur IR) réside dans la décision de se détacher d'un scénario qui ne colle pas aux données recueillies.

Quelle doit donc être l'état d'esprit de l'équipe IR lorsqu'un de ses binômes présente un scénario ?

Après plusieurs tâtonnements, j'en suis venu à considérer que la meilleure attitude consistait à écouter la ou les hypothèses, puis à chercher à les démolir à l'aide de toute les objections possibles et imaginables. Le coordinateur IR et le reste de l'équipe IR se doivent donc de critiquer le scénario construit par le binôme IR. Ceci va à l'encontre de toute règle sociale et peut mettre en danger la cohésion d'une équipe IR non entrainée à cette pratique !

Le processus de réfutation doit pour cela être facilité par le binôme IR qui doit faire en sorte de présenter son scénario de manière à permettre justement son démenti. Ceci demande beaucoup d'entrainement et ressemble, pour une oreille non avertie, à de la langue de bois !

Mais cela ne suffit pas. Mon opinion est la suivante :

La formulation d'une critique n'est possible que dans une équipe IR ouverte, dans laquelle l'information circule librement.

L'un des meilleurs moyens que je connaisse consiste à faire tourner le rôle de coordinateur IR, facilitant à la longue une libre expression, là où une hiérarchie trop stricte ne ferait que la museler.

On est là à des années lumières de l'image convenue de la cellule de crise : le sombre capitaine, seul maitre à bord au milieu de la tempête, qui dicte ses ordres à une équipe disciplinée, au fil de son intuition... Les plus gros désastres, que j'ai d'ailleurs pu observer au cours de ma carrière, provenaient souvent de ce genre de configuration, si prisée dans les films d'actions. Mais, je m'égare encore...

Personne n'aime faire l'objet de critique, surtout après une vingtaine d'heures de travail acharné. Enfin, notre éducation fait que l'on hésite toujours à critiquer la travail d'un proche. Le rôle du coordinateur IR est donc d'encourager ce genre d'aptitude. Le plus dur à vaincre reste la peur du ridicule devant ses pairs, si une réfutation parait complètement farfelue.

Finalement, les meilleures équipes IR que j'ai pu rencontrer ressemblaient d'avantage à un cercle de joueurs de poker, plutôt qu'à une section d'infanterie de la Grande Armée ! Quant à l'image que peut avoir une telle équipe au sein d'une organisation, ceci est une autre histoire. :-)

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

2006-12-19T00:53:00.000Z

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

2006-12-08T00:59:00.000Z

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...

2006-12-02T22:34:00.000Z

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...

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

2006-11-30T00:41:00.000Z

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 !

2006-11-27T00:32:00.000Z

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

2006-11-26T17:00:00.000Z

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 ?

2006-11-26T08:44:00.000Z

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 ?

2006-11-25T00:45:00.000Z

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

2006-11-24T02:08:00.000Z

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 ?

2006-11-16T00:48:00.000Z

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

2006-11-13T11:45:00.000Z

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

2006-11-12T15:48:00.000Z

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

2006-11-10T20:18:00.000Z

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

2006-11-08T13:24:00.000Z

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/cgibin/index.pl /opt/otrs/bin/cgibin/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

2006-11-07T13:18:00.000Z

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.

Charlatanisme digital et gri-gris en fer blanc

2006-10-26T13:43:00.000Z

Un Blog au stade larvaire, dont l'auteur ne m'est pas complètement inconnu : Charlatanisme digital et gri-gris en fer blanc
. Il lui reste à lacher son fer à souder...

De la gestion du risque à la gestion de crise

2006-10-17T19:57:00.000Z

Les financiers et les assureurs ont inventé la gestion du risque pour justifier des tarifs toujours plus exorbitants. Le malheur est que certains professionnels de la sécurité - et notamment ceux de la sécurité informatique - ont cru bon d'en faire un de leurs credos. L'apothéose de cette pseudo-science est aujourd'hui atteinte avec la ROI appliquée à la SSI !

Ma première question est la suivante :

Lorsqu'il faut justifier ce centre de coût que constitue la SSI à un décideur, vaut-il mieux lui raconter les pires catastrophes qu'il a judicieusement su éviter l'année précédente ou bien lui promettre que cette investissement sera amorti en deux ans grâce au temps gagné sur l'indisponibilité des serveurs hyper-critiques sur lesquels sont passés tous les ordres ?

Si l'adaptation au milieu constitue l'une des bases de la survie (surtout en milieu bancaire), encore faut-il pouvoir regarder ce décideur au fond des yeux lorsqu'on lui lache de telles vérités. Chacun son métier, vous l'avez deviné, je ne suis pas RSSI !

Mais, le plus terrible demeure la contemplation d'un RSSI-risqueur essayant d'appliquer sa pseudo-science à la résolution d'une simple crise... Un tel personnage - bercé toute la journée par les menaces et les risques - s'efforce alors de trouver la liste exhaustives de toutes les vulnérabilités potentielles pouvant correspondre à cet incident...

Ce délire se poursuit d'ailleurs souvent par des dizaines de minutes passées (avec l'aide d'un technicien IT compatissant ou n'ayant que ça à faire) devant un schéma réseau sur tableau blanc, recouvert bientôt de sigles et de noms de protocoles toujours plus savants. Le plus navrant dans une telle situation reste ce credo pseudo-scientifique qui s'acharne à être juste et exhaustive, plutôt que simplement efficace.

La qualité première du domaine de la réponse aux incidents sont, dans l'ordre :

le pragmatisme ;
l'art subtil de la prise de décision sur la base d'informations parcellaires.

Dans la gestion de crise, savoir prendre des décisions ou, plus difficile, faire prendre des décisions à une personne étrangère au domaine, reste un art plutôt qu'une science. Le problème réside en fait lorsque l'on recherche à prendre absolument les BONNES décisions ! Il est tentant d'enrober cette prise de décision dans une démarche pseudo-scientifique. Si une telle démarche peut rassurer, elle ne remplacera jamais l'expérience et le recul. Tout au plus faut-il s'appuyer sur une procédure toute simple relevant d'avantage de la check-list que des théorèmes de Sylow...

Lors d'une crise, les informations sont la plupart du temps fournies par des utilisateurs et des techniciens paniqués ou complètement blasés, selon leur ancienneté. Recruter des spécialistes relationnels des help-desk m'a souvent traversé l'esprit en contemplant une équipe essayant de répondre à un incident sécurité informatique. Ma deuxième question, à laquelle je vous invite à répondre, est donc :

Est-il plus difficile de fournir le jargon technique de la SSI à des spécialistes de la relation-client ou d'essayer d'inculquer un savoir-être de base à un spécialiste SSI persuadé d'être un ÜberHacker ?

Une des réponses les plus évidentes peut être : il faut ces deux populations pour une équipe de réponse aux incidents ou un hybride des deux. Si vous n'avez jamais eû à vous poser la question, soit vous êtes de ceux qui ont su persuader leur décideur du retour sur investissement en six mois d'une équipe de trente personnes, soit vous êtes de ces apprentis sorciers qui ont réussi à obtenir ou embaucher des hybrides par je ne sais quelle méthode génétique !

int main() {

2006-10-15T02:30:00.000Z

Un Blog concernant l'inforensique, la réponse aux incidents sécurité informatique et peut être... d'autres thèmes, suivant l'inspiration du moment.

Après réflexion - et connaissant mes tendances à l'écriture automatique - je me suis fixé comme règle d'attendre 24 heures avant de publier tout message, aussi génial puisse-t-il être à trois heures du matin...

Voila pour les bonnes résolutions.