La Computer Security Awareness Week est un événement annuel organisé par la Polytechnique de New York depuis maintenant dix ans. En plus de la compétition de 36 heures à laquelle la DCI a participé (et où elle s’est très bien classée), des conférenciers sont invités à partager leurs travaux et leurs connaissances. La plupart des conférenciers ont bénéficié du programme Cyber Fast Track, organisé par la Defense Advanced Research Projects Agency (ou DARPA pour les intimes), pour financer leurs recherches.

J’ai personnellement assisté à huit conférences. Celles-ci étaient de qualité variable. Voici un compte-rendu des trois qui m’ont le plus intéressé.

MoRE : Measurements of Running Executables

Cette conférence a été présentée par Jacob Torrey. Celui-ci s’intéresse à la vérification de l’intégrité des processus de démarrage d’un ordinateur. Présentement, la plupart des ordinateurs sont équipés d’un TPM (pour Trusted Platform Module), un module qui permet de vérifier la signature numérique de ces processus. Cependant, ces programmes contiennent aussi des données qui doivent inévitablement être modifiées, et il n’est parfois pas possible de démêler le code exécutable de ces données. Par conséquent, une fois en marche, l’intégrité ne peut plus être vérifiée.

Torrey présente donc une approche fascinante pour résoudre ce problème, inspirée du rootkit Shadow Walker. Soyez prêt à plonger deep down in the rabbit hole pour suivre son idée...

Les ordinateurs modernes utilisent le concept de « mémoire protégée » : chaque programme dispose à lui seul d’un espace d’adressage mémoire unique et isolé, qui ne contient que ses données, et qui ne peut généralement pas être touché à partir d’un autre programme. Inévitablement, il arrive que deux processus accèdent à une adresse mémoire identique dans leur espace d’adressage, mais qui correspond évidemment à une adresse physique différente.

Pour permettre cette protection, les processeurs modernes utilisent un translation lookaside buffer (ou TLB), qui permet de faire la traduction entre une adresse mémoire qu’un processus croit utiliser et l’adresse mémoire physique qui doit être utilisée.

Les architectes des processeurs x86, non contents d’un seul TLB, ont trouvé qu’il y avait à gagner à en avoir deux : un TLB pour les données (le D-TLB), utilisé par les instructions de lecture et d’écriture à la mémoire, et un TLB pour l’exécution (le I-TLB), utilisé pour lire les instructions qui doivent être exécutées. Tous les systèmes d’exploitation modernes les synchronisent, de sorte qu’elles contiennent toujours les mêmes entrées.

Qu’arrive-t-il si ces deux TLB sont désynchronisées? Pour beaucoup de programmes, pas grand-chose : tant que la I-TLB permet au processeur de récupérer des instructions valides, les programmes continuent de fonctionner. Cependant, les logiciels antivirus se font jouer un sale tour : pour faire l’analyse d’un programme, ils doivent lire son code plutôt que l’exécuter, ce qui fait que la D-TLB est utilisée pour accéder à la mémoire. Si la I-TLB n’est pas identique à la D-TLB, l’analyse est inutile, parce que les instructions exécutées ne correspondent pas aux instructions analysées! C’est l’essence de Shadow Walker: il arrive à se cacher en mémoire d’une façon qui le laisse faire ce qu’il veut, sans être détecté.

L’idée de Torrey est d’utiliser cette même technique, mais à des fins bénéfiques. Shadow Walker, finalement, crée un espace d’adressage distinct pour le code exécutable et pour les données. C’est une séparation essentielle pour la validation des processus de basses couches du système d’exploitation. Avec cette séparation, il est possible de faire vivre les données dans un espace distinct du code exécutable, et ainsi de continuer à valider l’intégrité du programme exécuté sans avoir à se soucier du fait que des parties puissent avoir changé.

Torrey travaille donc à une solution qui emploie cette technique. Il y a eu un certain nombre d’embûches, mais sa solution semble fonctionner, et a un impact de performance minimal. Lors de la séance de question, il a affirmé qu’un programme semblable pourrait être développé pour l’architecture ARM (plus souvent utilisée dans les téléphones intelligents) parce que la plateforme « suit le même plan de feature creep. »

PATHWELL : Topology Wear-Leveling Effectiveness

Cette conférence a été donnée par Hank Leininger, un administrateur système ayant près de 20 ans d’expérience. Dans cette conférence, il raconte qu’après avoir analysé les banques de mots de passe de plusieurs entreprises, il a fait un sombre constat : malgré toutes les politiques quant à la complexité des mots de passe, 85 % des mots de passe sont associés aux cinq « topologies » de mots de passe les plus populaires. Il s’avère que 33 % des mots de passe trouvés sont de topologie « ULLLLLDD », où U veut dire majuscule (uppercase), L veut dire minuscule (lowercase), D veut dire chiffre (digit); 33 % sont de topologie ULLLLLLDD (une lettre minuscule de plus); 27 % sont de topologie ULLLLDDD; 19 % de topologie ULLLLLLLDD; 13 % de topologie ULLLLDDDD. Et quand un caractère spécial est utilisé, c’est un point d’exclamation dans la vaste majorité des cas.

Ce sont des connaissances que les gens qui essaient de voler des mots de passe ont probablement, et qui sont d’une importance cruciale. Il est ridiculement plus facile de trouver un mot de passe dont on connaît la topologie qu’un mot de passe dont elle nous échappe : si on suppose que la topologie d’un mot de passe est ULLLLLDD, on peut le trouver en moyenne deux cent mille fois plus rapidement que si on ignore tout de sa composition. Si on vise les deux topologies les plus fréquentes, on peut retrouver 66 % des mots de passe en moyenne 140 000 fois plus rapidement que si on essayait bêtement toutes les combinaisons de tous les caractères possibles.

Bref, si vos mots de passe correspondent à l’une de ces topologies, considérez les changer!

Hank, de son côté, a créé un module PAM (le système responsable de l’authentification sur Linux) pour compter les topologies de mots de passe et vérifier que les topologies les plus fréquentes sont évitées, et bloquer les topologies qui commencent à être trop prisées par les utilisateurs. De cette façon, même si un attaquant récupère la base de données de mots de passe cryptés d’une compagnie, il ne pourra pas espérer retrouver beaucoup de mots de passe en utilisant les topologies les plus fréquentes, ce qui freinera énormément la vitesse à laquelle il pourra en décoder.

Pyrometer

Cette conférence a été donnée par Jonathan Grier, chercheur et consultant depuis 15 ans un peu partout aux États-Unis. L’objectif de sa conférence était de présenter ses travaux sur son application nommée Pyrometer, un programme qui permettrait aux administrateurs réseau de détecter en temps réel le vol de données.

Présentement, le vol de données est rarement détecté en entreprise. D’après Grier, des études empiriques montrent que le vol est découvert plus de trois mois après qu’il ait eu lieu, et la méthode de « détection » habituelle est que quelqu’un d’autre te montre que tes données ont été volées.

Pour atteindre son objectif, Pyrometer analyse les tendances d’accès aux fichiers pour déterminer quelle utilisation en est faite. Le programme est basé sur la façon par laquelle les programmes accèdent aux fichiers dépendant de leur objectif : par exemple, la copie de tout un dossier réseau provoque rapidement l’ouverture, la lecture et la fermeture de dizaines de fichiers, tandis qu’une utilisation normale provoque l’ouverture de très peu de fichiers à la fois (ceux que l’utilisateur désire lire). Pyrometer classe donc les tendances d’accès en quatre catégories : usage immédiat, recherche (par un utilitaire de recherche), activité système, et exfiltration; la dernière catégorie étant la seule dangereuse.

Il reste encore beaucoup de travail à faire. Pyrometer fonctionne dans un laboratoire, mais ne fonctionne pas vraiment dans un environnement de production, où, par exemple, il y a beaucoup de bruit dans les tendances d’accès. De plus, il va de soi, Pyrometer ne fait que rapporter ce qui se passe; le programme ne peut pas savoir si c’est une utilisation autorisée ou non. De plus, dans cette phase d’élaboration, l’impact de performance de l’application est visible.

L’audience a posé plusieurs questions au terme de la conférence; la plupart tournaient autour des méthodes par lesquelles le mécanisme de Pyrometer pourrait être dupé. La principale méthode était une très lente copie; mais comme Grier le note, une très lente copie peut ne pas être pratique pour un attaquant. Il fait remarquer malgré tout qu’il serait toujours possible de passer sous le radar, mais qu’un vol moins bien préparé pourrait facilement être attrapé.

Une expérience remarquable

Globalement, j’ai trouvé mes quelques jours au CSAW absolument remarquables. Comme l’événement sera certainement repris pour plusieurs années encore, vous pouvez être certain que j’essaierai à nouveau de me qualifier l’an prochain. Je rappelle d’ailleurs que la Délégation des compétitions informatiques de l’ÉTS est continuellement à la recherche de membres. Que vous vous sentiez amateur ou expert, nous serons heureux de vous avoir parmi nous!