Pourquoi nous devons soutenir, et non sanctionner, les esprits curieux en matière de sécurité

Les récents rapports du jeune chercheur en sécurité Bill Demirkapi, qui exposent les principales vulnérabilités du logiciel utilisé par son école, vous ont certainement rappelé des souvenirs. Je me souviens que lorsque j'étais un enfant curieux, je levais le capot du logiciel pour jeter un œil et voir comment tout fonctionnait et, plus important encore, si je pouvais le déchiffrer. Depuis des décennies, les ingénieurs en informatique cherchent à améliorer et à renforcer continuellement leurs produits, et la communauté de la sécurité (même si son approche est parfois un peu effrontée) joue un rôle important dans la découverte des failles et des catastrophes potentielles, espérons-le avant qu'un individu malveillant ne le fasse.

Cependant, le problème ici est qu'en réponse à ses découvertes, il a été temporairement suspendu de l'école. Cela ne s'est produit qu'après avoir épuisé tous les moyens de contacter l'entreprise (Corporación Follett) en privé, et avoir finalement opté pour une divulgation publique afin de se faire connaître et de démontrer sa capacité à compromettre leur système. Ses tentatives répétées pour avertir de manière éthique la société Follett Corporation sont restées sans réponse, tandis que le logiciel restait vulnérable et que de nombreuses données d'étudiants étaient facilement accessibles, car la plupart d'entre elles n'étaient pas cryptées.

Il a également recherché des erreurs dans le logiciel d'une autre entreprise : Blackboard. Même si les données de Blackboard étaient au moins cryptées, des attaquants potentiels auraient pu accéder à des millions d'enregistrements supplémentaires et s'en emparer. Son école utilisait à la fois ce logiciel et le produit de Follett.

Le récit du « hacker malveillant » est problématique.

Demirkapi a présenté ses découvertes lors de l'ICONO DE DEFINICIÓN, et les détails les plus audacieux de ses initiatives ont été applaudis par le public. En réalité, bien qu'il ait initialement été mal vu et ait rencontré de nombreux obstacles pour faire reconnaître ses découvertes, la société Follett Corporation a apprécié ses efforts et a suivi ses conseils afin, en fin de compte, de rendre son logiciel plus sûr et d'éviter que la crise ne devienne une nouvelle statistique de violation de données. Il fréquentera également l'Institut de technologie de Rochester après avoir terminé ses études secondaires, ce qui montre clairement qu'il est en bonne voie pour devenir un spécialiste de la sécurité très recherché.

En tant qu'agent de sécurité, il est difficile de ne pas être en désaccord avec la manière dont cette situation a été gérée. Bien que tout se soit bien terminé dans ce cas précis, au début, ils l'ont traité comme s'il s'agissait d'un scénariste importun qui se mêlait de ce qui ne le regardait pas. Une recherche Google sur l'incident donne des articles le qualifiant de « hacker » (dans l'esprit de l'expert en sécurité, cela le positionne comme le méchant à bien des égards), alors qu'en réalité, son approche (et celle de beaucoup d'autres) contribue à la sécurité de nos données.

Nous avons besoin de personnes curieuses, intelligentes et soucieuses de la sécurité qui surveillent de manière clandestine, et nous avons besoin que cela se produise beaucoup plus souvent. Depuis juillet, plus de quatre milliards d'enregistrements ont été exposés à des violations de données malveillantes rien que cette année. Cinquante millions d'autres pourraient s'ajouter à ce chiffre, en raison de l'intrusion en août dans une marque de mode et de style de vie, Poshmark.

Nous commettons les mêmes erreurs et, ce qui est encore plus préoccupant, il s'agit souvent de vulnérabilités simples qui nous font trébucher.

Les scripts intersites et l'injection SQL n'ont pas disparu.

Selon les informations fournies par CABLEADO, Demirkapi a découvert que les logiciels Blackboards Community Engagement et Folletts Student Information System comportaient des failles de sécurité courantes, telles que les scripts intersites (XSS) et les injections SQL, qui sont connues des spécialistes de la sécurité depuis les années 1990. Nous avons supporté leur existence pendant un certain temps, et tout comme les t-shirts et les disquettes Hypercolor, elles devraient désormais appartenir au passé.

Cependant, ce n'est pas le cas, et il est clair qu'il n'y a pas suffisamment de développeurs qui font preuve d'une conscience suffisante en matière de sécurité pour empêcher leur introduction dans leur code. Les outils d'analyse et les révisions manuelles du code ne sont pas très efficaces, et il existe des problèmes de sécurité bien plus complexes que ceux liés à l'injection XSS et SQL. Par conséquent, ces mesures coûteuses et lentes pourraient être mieux exploitées.

Des personnes telles que Bill Demirkapi devraient inciter les développeurs à établir des normes de codage plus élevées. À seulement 17 ans, il a compromis deux systèmes à fort trafic en utilisant des vecteurs de menaces qui auraient dû être détectés et corrigés avant même que le code ne soit écrit.

Gamification : la clé de l'engagement ?

J'ai beaucoup écrit sur les raisons pour lesquelles les développeurs restent largement indifférents à la sécurité, et la réponse courte est que peu d'efforts sont déployés au niveau organisationnel et éducatif pour encourager les développeurs à se préoccuper de la sécurité. Lorsque les entreprises consacrent du temps à créer une culture de la sécurité qui récompense et reconnaît l'engagement, notamment en mettant en place une formation qui parle le langage des développeurs et les motive à persévérer, ces vulnérabilités gênantes commencent à disparaître des logiciels que nous utilisons.

Il est évident que Demirkapi s'intéresse à la sécurité en dehors de son travail et qu'il a pris le temps d'apprendre à appliquer l'ingénierie inverse aux logiciels malveillants, à détecter les défauts et, enfin, à déjouer des éléments qui ne semblent pas compromis à première vue. Cependant, lors de sa conversation avec VICIO (et à travers ses diapositives DEF CON), il a fait une déclaration intéressante sur son autoformation... il l'a transformée en jeu :

« Dans le but de découvrir quelque chose dans le logiciel de mon école, cela s'est avéré être une manière ludique et amusante d'apprendre un nombre significatif de tests de pénétration. Bien que j'aie commencé mes recherches dans le but d'obtenir plus d'informations, j'ai finalement découvert que la situation était bien pire que ce à quoi je m'attendais », explique-t-il.

Bien que tous les développeurs ne souhaitent pas nécessairement se spécialiser dans la sécurité, chacun devrait avoir l'opportunité de se sensibiliser à cette question, car les connaissances de base constituent en quelque sorte un « permis de programmer » au sein d'une organisation, en particulier celles qui gèrent une grande quantité de nos données confidentielles. Si tous les développeurs sont en mesure de corriger les failles de sécurité les plus simples avant même qu'elles ne soient écrites, nous serons dans une position beaucoup plus sûre face à ceux qui cherchent à causer des dommages.

Êtes-vous intéressé par la formation ludique ? Veuillez consulter notre série Coders Conquer Security sur XSS et Injection SQL.