Commençons par HES. Cette convention de très haut niveau a rassemblée environ 200 personnes venues écouter des chercheurs en sécurité triés sur le volet. Ils présentaient leurs recherches et les exploits développés suite aux failles découvertes. Je n'aurai finalement assisté qu'a deux de ces conférences, mais elles étaient passionnantes. Voila donc un petit résumé de ce que j'ai entendu sur place.

Open Source Monitoring Security Issues

Il semblait logique de se pencher sur la sécurité des outils de supervision :

• Le serveur à souvent accès à toutes les machines, sur tous les réseaux (DMZs etc)
• Il est positionné "profondément" dans l'architecture, dans un réseau de confiance
• Il contient énormément de données (logs, traps snmp etc)
• Des agents de supervision sont souvent installés sur tous les équipements

Volontairement, ces deux chercheurs ont laissés de coté les solutions commerciales, ainsi que les fonctions forcément non sécurisées (exécution à distance etc), et les plugins qui ne sont pas intégrés par défaut avec le logiciel. Ils ont décortiqués quatre solutions : Cacti, Nagios, check_mk et Icinga. Ces études n'ont étés faites qu'avec les paramètres par défaut, sur des configurations réalistes.

Vous vous en doutez, ils ont trouvés des problèmes critiques dans tous ces logiciels (XSS etc, la liste est longue). Résultats : De magnifiques démonstrations, des shells en pagaille si l'admin vient à cliquer sur une url piégée. Plus rigolo, en rootant une des machines supervisée, il est possible de utiliser comme proxy pour remonter jusqu'au serveur.

Mais Le clou du spectacle était de parvenir à faire la même chose sans devoir "hacker" la machine supervisée. Une simple tentative de connexion ssh peut en effet suffire à corrompre la solution. Pour cela, on suppose que logwatch est installé. En lançant une connexion ssh avec des chaine de caractère spécifique (nom de l'utilisateur etc), on arrive a hacker le serveur de supervision, qui se chope l'exploit lors de la remonté des logs via logwatch. La grande classe non ?

Bien sur, toutes ces failles ont étés expliquées aux développeurs de chacune des solutions. Le temps moyen de correction est très bon puisqu'il n'a fallu en moyenne que six jours pour que les problèmes soit référencés (CVE...) et corrigés. Malheureusement il y a de grosses différences entre les équipes. Les développeurs de cacti auraient été très mauvais (limite pas de réponses). Au contraire les chercheurs félicitent les développeurs d'Icinga pour l'ensemble de leurs actions (Déjà penser à remercier...) Bref, en résumé, il faut vraiment éviter Cacti et Check_mk.

Lors des questions/réponses, j'ai demandé si ils avaient eu le temps de regarder Zabbix. La réponse est non. J'espère que lui aussi fera l'objet d'un audit poussé prochainement, en espérant que eux aussi traitent ce genre de choses serieusement

Extracting public keys from embeddeb devices

Durant le premier quart d'heure, j'ai été vite largué, avec la peur de ne rien capter de toute la présentation. Il s'agissait en effet d'un "rappel" sur les bases mathématiques du chiffrement asymétrique (clef publique/privée). La conclusion de cette introduction était qu'il est mathématiquement possible de calculer la clef publique utilisée pour une communication à partir de deux messages signés (signature effectué bien sur à partir de la clef privée). Je suis déjà assez content d'avoir compris la conclusion, ne me demandez pas de vous expliquer comment.

Mais vous vous posez surement la question... Quel est l’intérêt de trouver une clef qui est "publique" par définition ? L'idée c'est que, dans la pratique, la clef publique ne l'est pas toujours : Équipement de type "boite noire", système embarqué ou il n'est pas possible d'extraire les clefs etc). L’intérêt est d'auditer des systèmes qui utiliseraient des clefs trop faibles. (D'autres exemples ont étés donnés mais, la encore, je n'ai pas tout compris).

Nous avons alors droit à une petite démonstration sympathique avec deux fichiers textes en entré. Deux mails signés, récupérés sur une mailing de kernel.org. En quelques minutes, un script python associé à une librairie mathématique calcule la clef publique associée.

La suite sera beaucoup plus intéressante. On apprend en effet que les systèmes d'ouvertures des immeubles en France, le système Vigik, utiliserai justement des clefs trop faibles. Vous voyez de quoi on parle ? La porte de votre immeuble qui s'ouvre quand vous placez votre "token" devant le machin noir à coté de la sonnette... Le contenu des cartes (token) est maintenant totalement connu. Le firmware des lecteurs à été dumpé etc. Or, la clef RSA utilisée ne peut pas avoir une taille supérieur à 1024 bits, ce qui aujourd'hui est un peu faible. A moins de rapidement remplacer l'ensemble des lecteurs (environ un million en France, à 100 euros pièces...), il est probable que le système sera complétement cassé dans quelques années. Ce qui donnerait lieu à des petites choses rigolotes comme des applications pour smartphone permettant de se faire passer pour le postier (ou mieux, un employé EDF) et donc de rentrer dans n'importe quel immeuble juste avec son téléphone...

Notez que les gens qui spamment vos boites aux lettres sont identifiés comme "autre service postaux". Ils ont accès à l'immeuble même le dimanche, ce qui n'est pas le cas du facteur ordinaire ! Notez aussi qu'un pass "perdu" n'est utilisable que 24 heures, après quoi il faut charger une nouvelle clef à l’intérieur.

Hacker space fest

En parallèle d'HES, le HSF était un espace en accès libre, organisé en atelier. Des "hackers fous" y pressentaient leurs travaux dans des domaines aussi variés que la fermentation, le textile, la musique ou l'analyse des ondes cérébrales. D'autres se rassemblaient autour d'une "chiffro-fête" afin de s'échanger leurs clefs publiques, ou d'expliquer aux visiteurs curieux la signification de tout ça :)

Une visiteuse test le dispositif de NeuroHack :

Des présentations plus classiques ont aussi eu lieu, concernant chacun de ces sujets. Je n'ai malheureusement pas pu rester assez longtemps pour pouvoir entrer dans le détail mais, concernant l’association "informatique/électronique" avec le textile, franchement il y avait du lourd. Je ne pensai pas qu'on pouvait faire tout ça avec du tissu. Des poches qui faisaient office de condensateur, des tricots dont l’étirement était mesurable en faisait passer un courant électrique à l’intérieur, des fibres optiques tissées etc. Tout cela était réalisé de façon très artisanale mais ça fonctionnait parfaitement. Il ne reste plus qu'a trouver une utilité industrielle concrète à toutes ces bonnes idées.

Pour l’anecdote, ce HSF m'aura permis de (re)croiser Genma, lui aussi bi-classé geek/otaku et venu pour la chiffro-fête (crypto-party). J'ai aussi eu le plaisir de rencontrer Aeris, qui m'a appris pas mal de choses sur TAO et leurs joujoux. Des informations sont à récupérer ici. Vous je ne sais pas mais moi je ne regarderai plus jamais mes connecteurs USB de la même façon...

Merci Aeris ! (Pour ça et pour ne pas t'être trop foutu de ma gueule pendant ma prez sur le chiffrement ;) A une prochaine j'espère.