Donc nous y voilà. Root Me, kézako ? C'est exactement ce qui vous conviendra si, jeune ou vieux soldat, il vous faut un peu sentir l'odeur de la poudre sur le champ de bataille pour vous mettre en marche. Root Me est un site Web (https://www.root-me.org) entièrement gratuit, où vous êtes invité à vous confronter à des challenges, gagner des points si vous les surmontez, et de là pouvoir plastronner un peu. Car pour ce que j'ai pu en juger, si vous jouez franc jeu, soyez certain que vous ne les aurez pas volés, vos points.

Pour ma part, j'ai donc décidé de me concentrer sur les challenges de forensics. Serait-il possible de les faire tous ? Cela m'a semblé être une belle occasion d'en apprendre long sur le domaine. Après avoir surmonté 23 des 25 challenges au fil des dernières semaines – il faut bien travailler et vivre par ailleurs, même si Root Me devient vite envahissant... – et engrangé 870 points - ce qui ne fait de moi qu'un newbie dans la hiérarchie indigène -, l'heure m'a semblé favorable pour dresser un premier bilan.

Un premier intérêt de ces challenges de forensics, c'est d'apprendre à renouer avec l'ambiance devoir sur table. En effet, la première chose à faire, et à ne pas hésiter à refaire en cours de route pour ne pas s'égarer, consiste à bien lire l'énoncé et étudier les moyens mis à disposition.

En matière de challenges de forensics, l'énoncé est toujours d'un laconisme de prime abord déconcertant. Par exemple, le challenge Vilain petit canard :

Cet énoncé s'accompagne invariablement d'un ou de plusieurs fichiers à télécharger, qui constituent le matériau sur lequel il va falloir travailler, et éventuellement de références de documents renseignant d'assez loin sur des aspects techniques du challenge – par exemple, un simple manuel de l'outil votatility.

Il ne faut pas se laisser décourager pas le caractère aride du challenge, qui peut donner l'impression d'être débarqué en slip sur une île déserte, comme Link dans Breath of the Wild. En fait, la première chose dont il faut se rappeler, c'est qu'il faut lire l'énoncé. Certes, je viens de le dire, mais je ne suis pas certain d'avoir été bien lu. Quand je dis lire l'énoncé, c'est lire l'énoncé, en notant qu'il comporte trois parties : le titre, le sous-titre et l'exposé. C'est aussi lire les documents qui sont éventuellement référencés. En gros, c'est assez comme se lancer dans un LEGO : il faut trier les pièces et lire la notice pour éviter de s'engouffrer sur une voie de garage.

Dans ses mémoires qu'il vient de publier, Edward Snowden souligne amèrement comment il s'est prêté à une entreprise dont il a pu ultérieurement constater qu'elle était radicalement contradictoire avec ses convictions, tout simplement parce que focalisé sur son sujet, il avait perdu de vue the big picture.

De fait, prendre du recul n'est pas une pratique des plus répandues en informatique, ne serait-ce que parce que les projets sur lesquels l'on est mobilisé peuvent être très conséquents, et que l'on ne peut pas être au four et au moulin, ni tout comprendre, car chacun a ses spécialités comme ses appétences. Il en résulte que du tout, l'on ne voit souvent qu'une partie – ce tout pouvant être plus que la somme des parties, qui plus est. Aussi, sans que cela doive entraîner une crise de conscience comme chez Ed, mais simplement permettre de constater que l'on peut faire mieux en ayant conscience de ce que l'on fait, pratiquer ce type de challenges est utile.

Un deuxième intérêt des challenges de forensics, c'est qu'ils permettent d'en apprendre long sur des technologies, des techniques et des outils, pour autant que l'on sache saisir l'occasion.

Par exemple, je n'avais jusque-là guère trouvé la motivation pour installer une VM sous Hyper-V et y faire tourner Kali Linux, et au passage faire quelques lectures sur le fonctionnement d'un hyperviseur, jusqu'à un chapitre d'un manuel d'Intel pour bien comprendre comment cela se déroule au niveau du CPU.

J'aurais pu ne pas m'embarrasser et suivre un didacticiel sans me poser de questions, mais l'occasion était trop belle d'acquérir des connaissances sur les bases de la virtualisation, qui pourront très certainement me resservir en d'autres circonstances. Il en a été de même au fil des challenges pour toute sorte de sujets, du chiffrement à l'écriture d'un batch. Sans jamais aller jusqu'au fond des sujets car ce serait impossible et ce n'est pas l'objet, chercher tout de même d'en faire un peu plus que simplement les effleurer.

A côté de ces explorations parfois périphériques, il a bien fallu que j'acquière une certaine expérience sur des technologies, techniques et outils visiblement incontournables en forensics. Je pense à volatility, les outils de la suite TSK (The Sleuth Toolkit), ceux de la suite Sysinternals, WireShark et sa version en ligne de commandes tshark, et quelques autres.

Ces outils, j'ai dû non seulement apprendre à m'en servir, mais aussi apprendre comment il était possible de s'en servir de manière opportune et relativement efficace – la technique –, et parfois même comment aller jusqu'à les adapter en fonction de mes besoins – la technologie. Par exemple, volatility étant écrit en Python, j'ai pu, car j'ai dû, rentrer dans le code de la commande vaddump pour la modifier afin qu'elle ne crache que les traces des heaps d'un processus.

J'ai aussi dû parfois créer mes propres outils. Sans doute, ce n'était que de petits outils puisqu'il ne s'agissait jamais que d'une fonction pour déchiffrer un bloc de données, mais cela ne m'en a pas moins donné une nouvelle occasion de me remettre à Python après quelques mois passés sur du JavaScript bien moderne et de l'assembleur bien vétuste, donc de réapprendre des choses que j'avais oubliées, et d'en apprendre de nouvelles.

Pour en rester aux enseignements strictement techniques, il est clair que j'ai dû aussi rentrer dans des sujets qui étaient pour le coup bien spécifiques aux challenges. Par exemple, quelle est la structure d'une app sous Android ? Autrement dit, que faut-il s'attendre à trouver dans un APK, et par quel bout faut-il s'en saisir pour comprendre ce que fait l'app ? Ou alors, comment est-il possible de mettre en place un keylogger sous Linux, et décrypter ensuite les structures des événements qu'il a permis d'enregistrer dans un fichier ? Ou encore, bien évidemment, que peut-on espérer trouver dans un dump de la mémoire d'une machine sous Windows, qui permette de comprendre ce qui était en train de se jouer à cet instant-là ?

On le voit, s'attaquer à un challenge de forensics, c'est aussi l'opportunité d'être bien contraint d'apprendre quelque chose sur des sujets informatiques auxquels l'on ne s'est jamais frotté, parce le dump que l'on vous balance est d'une version d'OS X sur Mac et que vous n'utilisez pas de Mac, ou parce que le programme que l'on vous jette est en Java et que vous ne codez pas avec, voire que dans un cas ou l'autre, voire les deux, au fond, vous détestez cela - ce qui peut se comprendre...

Un troisième intérêt de ces challenges de forensics, c'est... le forensics, ou du moins une certaine idée de ce qu'est le forensics, telle que l'on peut l'appréhender dans ces challenges – j'y reviendrai plus loin, en traitant de que je n'ai pas appris.

Ce qui ressort de ce forensics-là, c'est avant tout qu'il est passionnant. N'est-ce pas devoir partir à l'aventure en terrain complètement inconnu, que l'on peut par ailleurs craindre miné tant l'auteur du challenge pourrait avoir trouvé un malin plaisir à nous égarer sur de fausses pistes ? Partant, l'on progresse avec anxiété dans la jungle des données, surtout si l'on se met un peu la pression pour surmonter le challenge au plus vite, mais point trop pour ne pas rater les occasions d'apprendre que j'ai évoquées.

Après avoir effectué quelques repérages que l'on apprend à systématiser au fil des expériences, l'on trouve les premiers indices. Tiens ! l'arborescence des processus retournée par la commande pstree de volatility permet de constater que ce processus a donné naissance à un autre, alors que le lien entre les deux n'apparaît pas des plus évidents ? Ou alors, la dissection d'un PCAP par WireShark permet de constater que les réponses à des requêtes appelant des réponses lisibles se présentent sous une forme des plus ésotériques ? Hmm... il faut décidemment aller voir cela de plus près.

Le caractère ludique des challenges est fortement accentué par l'esprit de compétition. Je l'ai évoqué rapidement au début de cet article, et il est temps d'y revenir car c'est un aspect d'importance cardinale de Root Me : qui surmonte un challenge gagne des points.

Plus le challenge est difficile, plus il en rapporte, c'est évident. Pour ce qui concerne les challenges de forensics, le nombre de points à glaner va de 5 pour le premier, à 70 pour dernier. Si j'ai bien compté, il y a pour l'heure 25 challenges, ce qui laisse largement le temps de s'arracher les cheveux, la difficulté m'étant apparue réellement croissante.

Au-delà des points, dans le profil de son compte, le rootmiste peut consulter des statistiques qui lui permettent de se faire une idée toujours réconfortante du chemin qu'il a pu parcourir, s'il se souvient que quelques semaines plus tôt, il n'y entendait que pouic au forensics, à la cryptographie, ou que sais-je encore :

Il peut aussi consulter la liste réjouissante des challenges où les vilains points rouges disparaissent, remplacés par de gentils points verts :

Ainsi, en pratiquant les challenges, l'on s'entraîne naturellement à en relever, ce qui peut donner envie de participer un jour à un CTF, l'acronyme de Capture The Flag, qui désigne une épreuve lors de laquelle il faut parvenir à trouver l'information enfouie dans les données avant les autres compétiteurs, en temps réel.

Ce qui ressort aussi du forensics selon les challenges, c'est qu'il faut faire preuve d'une certaine méthodologie pour en tirer tout le bénéfice, et avant tout prendre des notes.

Prendre des notes est indispensable, car les investigations pouvant durer et les pistes sur lesquelles s'engager se multiplier, l'on est bien content de pouvoir se rappeler où l'on en était quand il faut revenir en arrière, ou simplement s'y remettre après une coupure.

Personnellement, je trouve un intérêt à noter ce que j'ai fait et qui a bien marché, mais aussi ce que j'ai fait et qui n'a pas marché, histoire de ne pas refaire deux fois la même erreur, si ce n'est lors du même challenge, du moins lors d'un autre. Aussi, quand un challenge me donne du fil à retordre, il me semble intéressant de prendre le temps de rédiger un petit résumé de mes notes, pour le coup concentré sur ce qui a bien marché, histoire de prendre du recul.

De plus, prendre des notes permet de disposer du matériau pour rédiger une solution et la proposer. Car les solutions sont accessibles sur Root Me, et il est toujours possible d'en proposer, pourvu qu'elle ne soit pas redondante avec une solution déjà publiée.

Bien évidemment, je ne me suis jamais risqué à cliquer sur le bouton permettant de les consulter avant d'avoir surmonté le challenge : en cas de blocage, il est recommandé de demander de l'aide sur les forums, ou simplement de consulter les réponses apportées à ceux qui en ont demandée.

Toutefois, une fois un challenge surmonté, je recommande de lire la ou les solutions proposées. En effet, si l'on veut bien se rappeler qu'il y a toujours plus d'un moyen de résoudre un problème, et que l'on n'a peut-être pas trouvé le plus futé, lire les solutions donne l'occasion d'en rajouter aux découvertes en matière de technologies, de techniques et d'outils.

La première limite, c'est que l'on peut regretter qu'il n'y ait pas plus de directives pour inciter, sinon contraindre, à adopter de bonnes pratiques professionnelles.

Je ne suis pas encore renseigné sur les attentes dans les métiers qui emploient des professionnels du forensics, mais je me doute bien que savoir trouver l'épingle dans la botte de foin ne doit être que l'une des compétences requises. Tout comme du médecin légiste, il me semble que l'on attendra de l'informaticien qu'il ne mette jamais son ADN partout avec ses gros doigts, et qu'il soit toujours en capacité de le démontrer. Car si la finalité est de produire une preuve, l'intégrité de cette dernière ne doit-elle pas, par définition, être incontestable ? Partant, une preuve ne se réduit pas à un fait ; elle tient sa nature du processus qui a permis de la révéler.

Aussi me semble-t-il qu'en plus de savoir produire une preuve, un professionnel du forensics doit être en mesure de prouver que cette preuve en est une, ce qui mobilise d'autres compétences, comme celle de savoir documenter ses investigations. Si l'on se contente donc de résoudre des challenges pour résoudre des challenges, il me semble que l'on risque trop de s'enfermer dans la logique de compétiteur de CTF, et de développer alors non seulement une conception, mais aussi des pratiques éloignées de ce que peut être en réalité le forensics – en témoigne un script comme celui produit par TeamCTF-PRIME, que l'on pourrait d'emblée lancer sans se poser d'intéressantes questions.

Reste qu'il faut sérieusement tempérer cette critique, car il serait parfaitement injuste d'exiger de Root Me que le site joue un rôle qui n'est pas le sien. Rien que dans son nom, Root Me se présente clairement comme un site de challenges. Il n'a donc pas vocation à se substituer à des cursus de formation, mais à donner envie d'en poursuivre, voire à les compléter – sur ce point, j'espère que tous les enseignants et autres formateurs en sécurité informatique pressent leurs étudiants de s'y inscrire.

Par ailleurs, j'ai déjà dit qu'il est possible de proposer une solution à un challenge pour qu'elle soit publiée. Or en rédiger une implique de se livrer à un exercice qui constitue la base de l'écriture d'un rapport – les enseignants et formateurs précédemment cités sont invités à noter les rapports remis par leurs étudiants tant sur la forme que sur le fond. On ne peut donc pas dire que Root Me ne fait que valoriser une pratique secrète du hacking, et c'est tant mieux.

Une deuxième limite est plus spécifique aux challenges de forensics. C'est bien beau de prétendre qu'il est interdit de résoudre un challenge en procédant par pifométrie – deviner un mot de passe –, encore faudrait-il que ce ne soit pas le seul moyen possible de parvenir à ce beau résultat. Or, force est de constater que ce n'est pas toujours le cas, que la solution, ou du moins une partie de cette dernière, ne s'obtient pas toujours en mobilisant la seule technique, mais le flair, le nez planté dans un faisceau d'indices.

Ici encore, c'est une critique qu'il faut tempérer. Dans la réalité, qui est un labyrinthe, il est bien nécessaire de faire des choix qui sont arbitraires, et qui sont d'ailleurs inconsciemment guidés par l'expérience, c'est-à-dire de la compétence si parfaitement intégrée que l'on n'est même plus conscient qu'on la mobilise. Par ailleurs, il faut savoir se montrer efficace, et le puriste peut perdre beaucoup de temps pour parvenir à un résultat sans pour autant en rajouter à la rigueur ; il aurait mieux fait de s'en remettre à son intuition.

D'ailleurs, cela se lit dans certaines solutions, où les auteurs présentent des programmes qui avalent le dump et recrachent le flag. S'il est bien entendu que c'est une manière de documenter le travail – the code is the doc, n'est-ce pas ? –, et qu'il est parfois nécessaire de coder, il me semble que c'est un peu perdre du temps pour rien, le premier impératif m'apparaissant de faire vite et bien. Après, il est parfaitement possible que les auteurs de tels programmes les aient conçus très rapidement, tant ils sont productifs... A voir.

Dans le même registre critique, l'on peut regretter qu'un challenge forensics repose intégralement ou en partie sur le principe que je qualifierai de "la lettre volée". Je fais référence à la célèbre nouvelle d'Edgar Allan Poe, dont je ne citerai que ce passage pour ne pas en ruiner la lecture – d'ailleurs incontournable pour qui s'intéresse au forensics, il me semble :

Ce type de challenge est particulièrement exaspérant, mais il est vrai que la critique doit être encore une fois tempérée, car ce vice est aussi sa vertu. En effet, un tel challenge est certainement des plus formateurs, quand l'on constate rétrospectivement – importance de relire les notes que j'ai évoquées – la quantité de techniques que l'on a mobilisées, et l'effort que l'on y a investi... pour pas grand-chose. Si l'apprentissage par renforcement négatif à la Skinner n'est pas une blague, il est à parier que certains se souviendront longtemps de ce qu'ils ont appris lors d'un tel challenge, en premier lieu de faire le tour des évidences – ce qui, de manière assez intéressante, est le terme anglais pour désigner une preuve – avant de chercher ailleurs.

Une troisième et dernière limite est qu'aucun challenge de forensics n'exige de démontrer que quelque chose n'existe pas.

On connaît la formule, reprise par Donald Rumsfeld, alors Secretary of Defense, selon laquelle l'absence de preuve n'est pas la preuve de l'absence, et le dessein parfaitement douteux dans lequel elle a été employée. C'est justement pour éviter de forger des esprits aussi tordus qu'il serait intéressant que des challenges de forensics consistent à démontrer que l'on ne peut trouver quelque chose.

Quitte à m'en faire une fois encore une idée puisque je n'en suis pas, il me semble que dans le monde professionnel, être en capacité de démontrer qu'il est impossible de produire une preuve doit être tout aussi important que d'être capacité d'en produire.

L'enjeu peut être explicite : il s'agira de démontrer qu'un système n'était pas infecté, comme le médecin légiste démontrera que la victime n'a pas été empoisonnée. Il peut être aussi implicite, car permettre à celui qui nous a missionné de savoir qu'un fait ne s'est pas produit peut grandement influencer les enseignements qu'il en tirera. On imagine un juge, qui n'inculpera pas pareillement son témoin assisté s'il sait que ce dernier non seulement a infecté une machine, mais qu'il a de plus exfiltré des données.

Certes, une fois encore, c'est sans doute attendre de Root Me ce qu'il n'a pas vocation à apporter. Toutefois, ce n'est vrai qu'en partie, et je pense qu'il faudrait que les auteurs de challenges de forensics en élaborent dont la finalité serait de prouver une absence. A quoi pourrait ressembler le flag dans ses conditions ? Je ne le sais pas. A ces génies de trouver. Ils ont largement démontré qu'ils savaient enterrer un flag ; il n'appartient qu'à eux de passer le cap suivant, qui consiste à le faire disparaître. Nom du challenge : 64rc1m0r3 🙂

Root Me est passionnant, j'espère l'avoir bien dit. Pédagogiquement, on est dans un registre qui n'a pas été sans me renvoyer à un cursus de MBA, où le principe très anglo-saxon était que tout l'enseignement se fondait sur des études de cas. Cela a ses limites, car il est parfaitement possible de ne s'en tenir qu'au cas. Toutefois, il n'appartient qu'à l'étudiant de repousser ces dernières en profitant de l'opportunité unique qui lui est offerte de s'intéresser à un sujet, contre points trébuchants, pour l'approfondir au-delà de ses seuls besoins de l'instant.

Sur Root Me, du moins pour ce qui concerne les challenges forensics que je rappelle être les seuls que j'ai relevés – pour l'instant, évidemment ! –, la difficulté m'est apparue très bien dosée. J'en reste même étonné, tant il me semble rétrospectivement avoir été pris par la main pour rentrer dans le forensics, tout particulièrement pour apprendre à utiliser l'incontournable volatility. Sans doute, je ne débarque pas en informatique, mais en matière de forensics, je n'y connaissais vraiment rien – même pas cracker en mon temps sur Amiga, lire le code des autres m'ayant jusque-là fort peu inspiré...

Un grand merci donc à ceux qui ont créé et animent Root Me, ainsi qu’à ceux qui ont produits les challenges de forensics. Ceux-là, je les ai souvent voués aux gémonies ces derniers temps pour m’avoir jeté dans une telle Géhenne, mais c’est bien tout le jeu : Thanat0s, sambecks, eilco, N1lux, makhno, sourcePerrier, Bernstein, fraf, Futex, cryptax, koma, Siras, franb, dans le désordre et en espérant n’avoir oublié personne.

Je ne saurais donc trop chaudement recommander à vous tous, petits et grands, d'aller vous amuser sur Root Me. Et comme il existe certainement de nombreux sites du même acabit, j'invite ceux qui les ont testés de s'inscrire à un Meetup du fort sympathique chapitre France d'OWASP pour en faire l'objet d'un flashpoint, voire d'un atelier.

NB : La version de cet article publié dans Programmez! contient deux témoignages de rootmistes intéressants à lire.