Une liste de ces différentes attaques a déjà été proposée par d'autres. Aussi je pense m'intéresser ici aux conditions de réalisation de ces attaques et ce qu'elles permettent de faire.

Cela va sembler une évidence pour la plupart de mes lecteurs, mais il apparaît qu'il faille parfois insister sur deux points. D'abord, ces attaques sont des attaques qui demandent un accès physique à la machine ciblée. En tout cas, jusqu'à ce qu'on soit capable d'éteindre et rallumer physiquement une machine par la force de l'esprit, ou que le Firewire over 802.11 soit standardisé. Encore que le Firewire sans-fil ne soit pas très loin en fait... Ensuite, il s'agit d'attaquer un système qui tourne. Là encore, je suis tout à fait conscient d'enfoncer une porte ouverte, mais au risque de paraître ridicule, force est de constater que récupérer la mémoire d'un système éteint présente, pour un attaquant un tant soit peu sensé, un intérêt relativement faible.

Ces précisions étant faites, passons aux attaques proprement dites...


Coldboot

Cette attaque repose donc sur la rémanence des données en mémoire lorsqu'on coupe l'alimentation. De part la construction même des mémoires modernes, la charge électrique demeure physiquement l'espace d'une dizaine de secondes, et les données contenues en RAM avec. L'idée consiste donc à exploiter cette fenêtre temporelle pour lire, voire dumper, le contenu et y récupérer un maximum d'informations utiles. Et ce qui rend l'attaque efficace, c'est que si les données ne sont pas effacées quand on éteint la machine brutalement, elles ne le sont pas non plus quand on la redémarre.

L'idée consiste donc à procéder à un redémarrage brutal du système sur un système d'exploitation qui touchera le moins possible à l'état de la mémoire et qui nous permettra de travailler dessus en paix. C'est typiquement ce que fait l'outil DaisyDuke qui a été présenté à Cansecwest. Il utilise une base FreeDOS qui ne travaillera que sur la mémoire basse et ne touchera pas au reste. Cependant, l'attaquant peut se retrouver dans une situation dans laquelle il n'est pas forcément capable de booter la machine cible sur un support externe. Il est vrai que dans la vraie vie, de plus en plus de laptops sont verrouillés pour ne booter que sur le disque dur local, vous obligeant à remplacer ce disque pour rebooter, ce qui pourrait être également impossible du fait de BIOS récalcitrants, voire de TPM configurés. C'est dans ce type de cas qu'il s'avère nécessaire de recourir au tournevis et à la bombe réfrigérante, pour démonter les barrettes après les avoir refroidies pour dopper l'effet de rémanence pendant le transfert. C'est ce qu'on voit sur la vidéo de Princeton. On les place alors dans une machine qu'on boote sur l'OS qui va bien. J'ai quelques doutes sur l'universalité de cette dernière méthode, en particulier sur sa dépendance à l'electronique utilisée.

Mais bref, l'idée, c'est qu'on arrive à un point où on peut lire la mémoire et en analyser la structure pour trouver les informations qui vont bien, voire en dumper carrément le contenu. Le genre de choses utiles qu'on trouve en mémoire, ce sont principalement des mots de passe et des clés de chiffrement.

Donc pour mener à bien cette attaque, il vous faudra la possibilité soit de booter sur un device externe, inscriptible de préférence pour y stocker vos trouvailles, soit d'avoir un peu plus de temps pour démonter la RAM. Vous ne pouvez que lire les informations. Enfin, votre passage sera visible puisque vous éteignez la machine. Ce qui devrait vous mettre la puce à l'oreille au passage, ne serait-ce que si vous avez déjà envisagé la possibilité que quelqu'un veuille dumper votre disque dur pendant votre absence...


Sandman

Sandman, dont je parlais précédemment, travaille sur le fichier d'hibernation pour y récupérer des informations, mais également pour injecter des données. La machine visée étant destinée à redémarrer en utilisant ce fichier comme base, on peut, en plus de l'extraction de données sensibles, penser à pleins d'applications plus intéressantes les unes que les autres : élévation de privilèges, comme démontré dans la vidéo projetée à Cansecwest, ou injection de processes plus rigolos les uns que les autres.

Le problème, c'est d'avoir accès à ce fichier. Il faut en effet soit disposer d'une machine en hibernation, soit d'avoir la possibilité de la mettre dans cet état, ce qui revient à avoir accès à la console. En outre, il faut que le support de données qui contient le fichier d'hibernation ne soit pas chiffré. Sinon, paf. On pourrait utiliser l'attaque précédente pour récupérer la clé avanceront certains, mais vous allez éteindre la machine pour la réaliser, et donc perdre l'état du système... Certains avanceront aussi que si on a accès aux données du disque dur, il sera probablement suffisant de modifier quelques binaires ou bibliothèques de base pour obtenir un effet quasi-identique. C'est tout à fait vrai. Mais on a ici l'avantage de ne pas toucher au disque[1]. Et moins on y touche, mieux on se porte C'est ce qui a motivé l'engouement pour les attaques se déroulant complètement en mémoire qu'on a pu constater ces dernières années. Et avec lui le besoin de lire la mémoire en live...

Un intérêt non négligeable par rapport à la technique précédente est que vous rendez le système dans un état très proche de celui dans lequel il était avant que vous le passiez en hibernation. En outre, si l'élévation de privilèges semblent une application un peu naïve, je peux vous assurer qu'elle éveille l'intérêt de nombre d'utilisateurs désireux d'obtenir les droits d'admin sur leur poste de travail considérant la facilité de mise en œuvre. Enfin, un point intéressant démontré dans la vidéo, mais pas assez mis en avant à mon avis, est qu'un poste dont la fonction d'hibernation est désactivée, essayera tout de même de booter sur le fichier d'hibernation si ce dernier est présent. Je tire un peu sur la corde dans la mesure où c'est très loin d'être simple, mais l'idée de pouvoir amener une machine dans un état arbitraire juste en posant un fichier sur son disque n'est pas complètement dénué d'intérêt.


Firewire

J'avoue que l'attaque passant par le système Firewire gagne ma préférence. Surtout parce qu'elle permet de combiner les avantages des deux précédentes sans en cumuler les défauts. Elle permet un accès quasi-complet à la mémoire, en lecture comme en écriture, sans pour autant avoir besoin d'arrêter ou hiberner la machine. Et quand on part, pour peu qu'on fasse bien les choses, l'utilisateur légitime du poste ne verra pas qu'il s'est passé quelque chose. De plus, si la machine ne dispose pas d'un port Firewire, vous pouvez tout à fait lui en ajouter un par le truchement d'une carte PCMCIA adaptée, ça marchera tout aussi bien. Enfin, quel que soit l'état de la machine, ça marche. Par exemple, si elle est lockée, vous ne pourrez pas utiliser Sandman puisque dans l'impossibilité de passer en hibernation. Là, pas de problème.

Le principe est donc de disposer d'une unité de calcul embarquée se présentant comme un périphérique Firewire et qui va lire et/ou écrire dans la mémoire du système, en live. Vous pouvez donc en lire le contenu, comme pour le Coldboot ou Sandman, et le modifier, exactement comme avec Sandman. C'est donc globalement la fête : récupération de données sensibles, élévation de privilèges, injection ou destruction de processes[2], etc.

Mais il n'y a rien de nouveau là-dedans, la puissance de cette attaque est connue depuis des lustres.


Conclusion

La conclusion, c'est que contrairement à ce que disent les auteurs de DaisyDuke, le Coldboot n'a pas révolutionné le paysage de la sécurité physique. L'adage qui veut que si quelqu'un accède physiquement à votre machine, cette dernière peut être considérée comme compromise, a toujours été vrai, et continue à l'être. Ces attaques sont juste de nouveaux vecteurs qui le démontrent. Ne vous méprenez pas cependant. Ces attaques sont très intéressantes, autant par leur principe, leur réalisation que par leurs applications. Pour autant, elles ne font que confirmer ce qu'on savait déjà.

Notes

[1] Même si en terme de persistence, ce sera aussi un inconvénient...

[2] Genre l'écran de veille...