Pourquoi il est important de soutenir les responsables de la sécurité qui font preuve de curiosité plutôt que de les sanctionner

Le récent rapport de Bill Demirkapi, chercheur en sécurité informatique chez Youth, sur les principales vulnérabilités exposées dans les logiciels utilisés dans son établissement scolaire m'a rappelé des souvenirs. Je me souviens, lorsque j'étais enfant et curieux, avoir soulevé le capot du logiciel pour observer son fonctionnement. Et surtout, je me demandais si j'étais capable de le pirater. Depuis des décennies, les ingénieurs en informatique cherchent à améliorer et à renforcer constamment leurs produits, et la communauté de la sécurité joue un rôle essentiel dans la détection des failles et des catastrophes potentielles (même si son approche est parfois un peu arrogante). Et ce, avant que des personnes malveillantes ne le fassent.

Cependant, le problème ici est qu'en réaction à sa découverte, il a reçu une légère sanction disciplinaire. Et cela ne s'est produit qu'après qu'il ait épuisé tous les moyens possibles pour contacter l'entreprise (Follett Corporation). À titre personnel, il a finalement choisi de procéder à une divulgation publique afin de se faire connaître et de faire connaître ses compétences en matière de piratage informatique. Ses tentatives répétées pour alerter Follett Corporation de manière éthique sont restées sans réponse. Le logiciel est resté vulnérable et les données des étudiants, qui s'accumulaient en quantités considérables, n'étaient pas cryptées et pouvaient donc être facilement exposées.

Il a également détecté des bogues dans le logiciel Blackboard d'une autre société. Les données de Blackboard étaient au moins cryptées, mais un attaquant potentiel pouvait accéder à des millions d'enregistrements et en voler davantage. Son école utilisait à la fois ce logiciel et les produits Follett.

Le terme « hacker malveillant » pose problème.

Demircapı a présenté les résultats de ses recherches lors d'une conférence cette année. Les détails plus ludiques de son icône Def, ses facéties, ont été applaudis par le public. C'est exact. En réalité, Follett Corporation a initialement rencontré de nombreux obstacles pour faire reconnaître ses découvertes, qu'il avait faites en se plongeant dans des livres peu recommandables, mais en reconnaissant ses efforts et en suivant ses conseils, l'entreprise a finalement renforcé la sécurité de ses logiciels et évité une nouvelle crise qui aurait pu se traduire par une nouvelle fuite de données. Il est également prévu qu'il intègre l'université technologique de Rochester après avoir obtenu son diplôme d'études secondaires, ce qui montre clairement qu'il est sur la bonne voie pour devenir un expert en sécurité très recherché.

En tant que responsable de la sécurité, il est difficile de ne pas contester la manière dont cette situation a été gérée. Dans ce cas précis, tout s'est bien terminé, mais au début, il a été traité comme un enfant turbulent qui se mêlait de ce qui ne le regardait pas.En recherchant cet incident sur Google, on trouve des articles qui le qualifient de « hacker » (les profanes en matière de sécurité le considèrent à bien des égards comme un méchant). En réalité, son approche (et celle de nombreuses autres personnes) contribue à la sécurité des données.

Nous avons besoin de personnes curieuses, intelligentes et soucieuses de la sécurité. De plus, ce type d'incident devrait se produire plus fréquemment. En juillet, plus de 4 milliards d'enregistrements ont été exposés à des violations de données malveillantes cette année seulement. En août, une violation de la sécurité de la marque de mode et de lifestyle Poshmark a ajouté 50 millions de dollars à ce chiffre.

Nous commettons également les mêmes erreurs. Plus inquiétant encore, ces vulnérabilités, qui sont souvent des vulnérabilités simples qui nous font trébucher, continuent de nous faire chuter.

Le cross-site scripting et l'injection SQL n'ont pas disparu.

Comme indiqué précédemment, Wired et Demirkapi ont confirmé que le logiciel communautaire Blackboard et le système d'information étudiant Follets contenaient des bogues de sécurité courants, tels que le cross-site scripting (XSS) et l'injection SQL. Ces deux bogues ont été identifiés par les experts en sécurité dès les années 1990. Nous avons continué à les surveiller de près en raison de leur importance. Il y a très longtemps, tout comme les t-shirts Hypercolor et les disquettes, ils ne sont plus aujourd'hui qu'un lointain souvenir.

Cependant, ce n'est pas le cas. Il est également évident qu'il n'y a pas suffisamment de développeurs ayant une conscience suffisante de la sécurité pour empêcher l'introduction de ces fonctionnalités dans le code. Les tâches pouvant être effectuées à l'aide d'outils d'analyse et de révision manuelle du code sont limitées, et les problèmes de sécurité sont également beaucoup plus complexes que les injections XSS et SQL. En effet, il est possible de mieux exploiter ces méthodes coûteuses et chronophages.

Des personnes telles que Bill Demirkapi devraient inspirer les développeurs à créer un code de meilleure qualité. À seulement 17 ans, il a compromis deux systèmes à fort trafic en exploitant un vecteur de menace qu'il aurait dû détecter et corriger avant de valider le code.

Gamification : Quel est le principe fondamental de la participation ?

Pour expliquer brièvement pourquoi les développeurs ne s'impliquent toujours pas beaucoup dans la sécurité, c'est parce que l'on ne déploie pas suffisamment d'efforts organisationnels ou éducatifs pour former des développeurs compétents en matière de sécurité. Si les entreprises prenaient le temps de parler le langage des développeurs et mettaient en place des formations pour les motiver à continuer à essayer, si elles récompensaient leur participation et reconnaissaient leur contribution en instaurant une culture de la sécurité, les vulnérabilités gênantes commenceraient à disparaître des logiciels que nous utilisons.

Demirkapi accorde manifestement une attention particulière à la sécurité et a consacré du temps à apprendre à rétroconcevoir des logiciels malveillants, à détecter des vulnérabilités et à détruire des éléments qui, vus de l'extérieur, ne semblent pas défectueux. Cependant, au cours de notre conversation (et à travers les diapositives DEF CON), il a fait une déclaration intéressante au sujet de son autoformation... Il l'a transformée en jeu.

« Mon objectif étant de trouver quelque chose dans le logiciel de l'école, j'ai pu apprendre par moi-même une quantité considérable de tests d'intrusion grâce à une méthode ludique et amusante. J'ai commencé mes recherches dans le but d'en savoir plus, mais j'ai finalement découvert que la situation était bien pire que prévu », a-t-il déclaré.

Tous les développeurs ne souhaitent pas nécessairement se spécialiser dans la sécurité, mais chacun devrait avoir l'opportunité de comprendre les principes fondamentaux de la sécurité. En particulier, les développeurs qui gèrent de grandes quantités de données sensibles doivent posséder des connaissances de base qui leur permettent d'agir en tant que « gardiens du code » au sein de leur organisation. Si tous les développeurs pouvaient corriger les failles de sécurité les plus simples avant même qu'elles ne soient exploitées, nous serions dans une position bien plus sûre face aux développeurs malveillants.

Vous souhaitez en savoir plus sur l'apprentissage ludique ? Découvrez la série Coders Conquer Security sur le lien suivant XSS et Injection SQL.