Changement de disciplines en vue...

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

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

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" ?

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