La vérité, mon cœur saigne !

Pris dans la tourmente médiatique, entre Bygmalion/UMP, la coupe du monde de foot et le FN arrivant en tête aux élections européennes, vous n’avez néanmoins pas pu passer à côté de l’événement de l’année.

Bref, la une a été longuement occupée par la très médiatique faille heartbleed avec son joli logo jusque la dernière, CCS, à l’heure de la rédaction de ces lignes. Elle est certes amusante et permet de récupérer des données sensibles en mémoire, tout en étant techniquement hallucinante de bêtise.

Ce qui est d’autant plus hallucinant, c’est de constater que les gens qui font OpenSSL sont si peu soutenus. D’une part, l’équipe de développement n’est pas énorme comparé à l’ampleur du projet, tant en lignes de code qu’en utilisation globalement partout. D’autre part, la complexité du code est équivalente à celle de nos instances dirigeantes européennes, avec des supports de systèmes improbables.

Il existe des tonnes de logiciels coûtant certes une fortune pour faire de « l’analyse de code ». Ils ne permettent pas de tout détecter, y compris heartbleed. Mais on se demande pourquoi aucun détenteur de ces logiciels ne se lance régulièrement, en partenariat avec les développeurs, dans le test d’OpenSSL.

Depuis heartbleed, d’autres failles ont été découvertes dans les bibliothèques crypto, assez ennuyeuses évidemment, comme si soudainement, on avait pris conscience qu’il fallait auditer également ce type de bibliothèque, non seulement pour la qualité de la crypto, mais aussi pour celle du code.

L’autre actu crypto est le ragequit des développeurs de TrueCrypt. Après un audit médiatisé et crowdfundé, les développeurs ont soudainement annoncé qu’il valait mieux utiliser Bitlocker. Tout cela interpelle. D’abord, il y a toujours eu un mystère autour de l’identité des développeurs de TrueCrypt, semant les germes d’un doute : sont-ils financés par on ne sait qui, ou bien est-ce une personne qui fait ça dans son garage après une journée de dur labeur ? Personne n’en sait rien.

Toutefois, il y a eu des CSPNs ordonnées par l’ANSSI sur ce produit. Ayant été mêlé à une de ces CSPN, je peux témoigner que les développeurs ne sont pas super fair-play quand on leur rapporte des problèmes. Et l’issue de l’audit crowdfundé a révélé quelques problèmes, loin d’être critiques. Mais si le(s) développeur(s) anonyme(s) en ont marre de se faire descendre pour un soft qu’ils développent sur leur temps libre, on peut comprendre leur réaction, tout en regrettant la forme qui renforce le doute.

Moralité épisode 1, développer de la crypto, c’est compliqué. Ça demande à la fois un cryptologue et un développeur, le premier ne sachant pas coder, le second ne sachant pas quels paramètres utiliser pour une crypto robuste
(voir [1]). Or les équipes où les 2 travaillent en bonne intelligence sont rares... et elles sont alors plus portées sur la conception de produits (ex. OpenSSH) que l’audit de solution existantes. Néanmoins, cette collaboration est également fructueuse par exemple quand on analyse des DRM modernes, où on « exploite » aussi bien des failles informatiques que mathématiques pour parvenir à nos fins (quand on nous laisse le temps de fouiner).

Moralité épisode 2 : les révélations de la NSA ont levé le voile sur les capacités d’espionnage des américains, même si des doutes subsistent. Néanmoins, la réaction unanime a été de dire : développons la crypto. Et là, subitement, plusieurs nouvelles viennent mettre en doute la crypto, soit par des failles dans des produits grand public, soit en provoquant un ragequit. Si j’étais paranoïaque, je me demanderais à qui profite le doute qui pèse maintenant sur la crypto pour tous...

Bonne lecture !

Fred Raynal | @fredraynal | @MISCRedac

[1] http://aumasson.jp/data/talks/cryptocoding_sstic14.pdf

Au sommaire de ce numéro :

Exploit corner

p.04 CVE-2013-3881

Pentest corner

p.10 Tester la sécurité d'une base de données Oracle (ODAT)

Malware corner

p.20 Opération Windigo : infection de serveurs Linux à grande échelle

Dossier : Scada, c’est plus fort que toi

p.26 Préambule
p.27 Introduction à la cybersécurité des Systèmes d'Information (SI) Industriels
p.34 Intégration de la cybersécurité avec la sûreté de fonctionnement
p.43 Bonnes pratiques d'architecture pour la sécurité
p.52 Tests d’intrusion sur automates : méthodes, outils et retours d’expérience

Système

p.60 Cryptographie : vol de clefs via stunnel

Application

p.66 Automatisation des audits de sécurité avec SCAP

Réseau

p.78 Naviguez mieux protégé (ou pas)