Peter Tippett

Cet article restranscrit les grandes idées d'une présentation donnée par Peter Tippett au Computer Forensics Show 2008 à Washington et intitulée "What's wrong with our security thinking ?". Titre alléchant qui laisse entrevoir pleins de sujets croustillants, et autant de pratiques à discuter dans ce grand monde de la sécurité. Or, je dois avouer que l'article me laisse perplexe sur le contenu...

Dès le début, on nous parle de la gestion des correctifs. Le fameux "patch management" qui monopolise à lui seul une sacrée part de l'énergie dépensée. Pour justifier l'argument comme quoi les équipes sécurité y consacrent trop de temps, constatation loin d'être erronée, il nous explique que seulement 3% des failles découvertes sont exploitées dans la nature. Et de poursuivre par une analogie de derrière les fagots, comme souvent dans de tels cas, qui me laisse dubitatif. D'abord sur le taux d'exploitation. Ce chiffre n'est probablement pas loin de la vérité, mais d'où le tient-il ? Quelles sont les données qui lui permettent d'affirmer cela ? Parce que comme l'expliquait très justement Stefano Zanero à Deepsec, les chiffres qu'on nous balance ne tienne souvent sur... rien. De toute manière, on sait bien que "80% des statistiques sont fausses". Ce que je veux dire par là, c'est qu'il ne suffit pas de regarder quelles failles ont donné un ver pour en conclure que paf, 3%.

Et quand bien même cette statistique serait exacte, il est toujours facile de donner des leçons a posteriori. Car avec le recul, on peut se dire qu'effectivement, peu d'entre elles génèrent l'essentiel du bruit[1]. Mais avec le recul. Car avant, on n'en sait rien. Ou presque. Parce qu'armé d'une description détaillée, on pourrait étudier la faille, lui donner une criticité et prioritiser son déploiement. On a déjà l'idée avant moi ?! Merde. Et puis à peser le pour le contre, est-il plus rentable de déployer systématiquement ou de qualifier ? Ou de faire confiance à un tiers ? Bref, je trouve ça un peu gros de laisser entendre que le patch management ne sert à rien, surtout venant de la part de quelqu'un dont l'œuvre majeure nécessite un cycle de mise à jour de l'ordre du quart d'heure pour être d'une utilité quelconque[2].

Quant au parallèle avec son histoire de flèche qui tue le conducteur par son toit ouvrant, on s'aperçoit bien qu'il n'a rien à voir avec la réalité d'Internet, ne serait-ce qu'au niveau des conditions nécessaires de réalisation. Car dans notre beau monde numérique, quand bien même une faille serait difficile à exploiter, la mise à disposition d'un exploit, même moyennement efficace, explose en terme de potentialité tout ce que nous connaissons dans le monde réel. Il faudrait donc comparer cela non pas à un archer, mais à un arc automatique, d'une précision extrême sans limite de portée ou de champ de vision[3], et sans limite de munitions. Et cet arc serait en vente libre...

La suite est plus sensée à mon sens. Nettement plus. En particulier cette critique de l'approche microcopique de la sécurité, dans un environnement résolument macroscopique. Critique qui aurait mérité d'être un peu plus approfondie, mais sur laquelle l'article passe très rapidement. Bien vu également la recherche du 100% qui est un autre problème je pense de la sécurité aujourd'hui. À savoir qu'on n'a pas encore su trouver le bon point d'inflexion entre la technique et le juridique pour qualifier le risque acceptable, et donc du niveau de protection au-delà duquel il ne sert à rien d'aller, sinon à cramer inutilement son budget.


Les imprimantes multifonctions

eWeek traite donc des problèmes de sécurité liés aux imprimantes, à la lumière des propose de Brendan O'Connor, auteur d'une présentation sur le sujet à la BlackHat US 2006. L'article est intéressant, même s'il s'agit quelque peu d'une prise de conscience tardive de l'ampleur du problème. Car même sans aller jusqu'à l'exploitation de ces périphériques bons à tout faire, on ne compte plus les files d'impressions accessibles anonymement ou les bugs dans leurs systèmes de contrôle d'accès.

Exemple tout bête qui date de mon tout premier emploi. Un copieur multifonction d'une marque dont je tairai le nom par charité, permettait à tout un chacun de conditionner la sortie de ses impressions à la fourniture d'un code personnel. Si la fonctionnalité semblait fonctionner remarquablement, elle ne s'appliquait pas à toutes les fonctions de l'appareil. Obscure formulation me direz-vous. Certes, jusqu'à ce qu'on regarde ce que ces bestiaux savent faire. Celui-ci, en particulier, savait assembler des documents, extraits du disque local contenant les documents imprimés récemment. Mais là, par contre, sans mot de passe. Donc vous balancer une feuille blanche à l'impression, demandez un assemblage et avez alors accès à tous les documents, y compris ceux qui étaient protégés. Youpi.

C'est également intéressant parce que ces bestiaux sont en quelque sorte indispensables dans toute organisation de taille importante, ne serait-ce qu'en terme de coût d'utilisation. Et comme ils présentent ce qu'on pourrait qualifier de niveau zéro en terme ne serait-ce que de sécurité réseau, ils constituent une cible de choix. Admettons que vous deployiez du 802.1x. Qui est-ce qui va tout vous ruiner parce qu'il ne le supporte pas ? Votre copieur. Vous voulez imposer des flux chiffrés ? L'exception sera votre copieur. Vous voulez des authentification fortes, voire du SSO ? Demandez donc à votre copieur... Évidemment, la situation évolue et certains modèles sont relativement bien fournis... À condition de pouvoir en acheter des récents ou de disposer de mises à jour compatibles. Car c'est le genre de mastodonte qu'on ne renouvelle pas tous les deux ans.


L'aléa chez OpenBSD

Amit Klein a publié un papier sur la qualité du générateur d'aléa des BSD, avec comme application la corruption de cache DNS sous OpenBSD et la prédiction des numéros d'identification IP sur une large palette de BSD ou dérivés. c'est technique et très intéressant. Je vous le recommande en particulier si les termes corruption de cache DNS ou Idle Scan ne vous évoquent que de lointains souvenirs.

J'ai bien apprécié également la référence à ces réflexions de Michal Zalewski sur l'injection de données dans un flux TCP en ne jouant que sur les IP ID justement, et non sur les ISNs. Technique qu'il développe nettement plus dans son bouquin, Silence on the Wire. Si les conditions initiales de l'attaque sont peu courantes[4], force est de constater qu'elle présente quelque élégance qui lui procure un intérêt culturelle pour l'amateur de sécurité réseau.


GNUCitizen et le Wi-Fi

Ça va faire un peu "je l'avais fait avant toi", mais là n'est pas mon propos. Pdp ouvre ses lignes à Sam Aldis pour nous présenter un script Python d'injection DNS sur un réseau Wi-Fi ouvert. Certes, Wifitap contient un script wifidns.py qui fait exactement la même chose, support WEP en plus, depuis deux ans et demi. Certes, j'en ai parlé à une tonne de conférences et en particulier à Bellua en 2006.

Non, ce que je veux dire, c'est que même des années plus tard, des trucs vieux comme le monde restent d'actualité, quand bien même on les aurait rabâché à les user. C'est un peu l'histoire de la sécurité tout ça... People never learn...


Et puis...

Et puisqu'on parle de conférences, je donne rendez-vous aux plus rapides[5] de mes lecteurs au SSTIC 2008 pour lequel ma soumission a été sélectionnée[6]. Youpi ! J'en profite pour remercier les trois relecteurs[7] de m'avoir fait confiance. Maintenant, au boulot.

Notes

[1] On sent la loi de Pareto pointer le bout de son nez...

[2] Je sais, c'est bas comme argument.

[3] Comprendre qu'il est capable d'atteindre n'importe quel véhicule circulant à ciel ouvert.

[4] Nécessité de s'appuyer sur un paquet fragmenté.

[5] Ou chanceux.

[6] "Patrimoine informationel" compris.

[7] Ou relectrices, même si la composition du comité de relecture et la grammaire française me dispensent de faire le distingo.