Pourquoi nous devons soutenir les agents de sécurité curieux et non les sanctionner

Les rapports récents du jeune chercheur en sécurité Bill Demirkapi, qui a découvert de graves failles de sécurité dans le logiciel utilisé dans son école, ont certainement ravivé certains souvenirs. Je me souviens avoir été un enfant curieux qui démontait les logiciels pour voir comment ils fonctionnaient et, surtout, pour voir si je pouvais les endommager. Pendant des décennies, les ingénieurs logiciels se sont efforcés d'améliorer et de renforcer continuellement leurs produits, et la communauté de la sécurité (même si elle est parfois un peu effrontée dans son approche) joue un rôle important dans la découverte des bogues et des catastrophes potentielles, espérons-le avant qu'un individu malveillant ne le fasse.

Le problème, cependant, est qu'en réponse à ses découvertes, il a reçu une suspension scolaire mineure. Et cela ne s'est produit qu'après qu'il ait épuisé toutes les possibilités de contacter l'entreprise (Follett Corporation) en privé et qu'il ait finalement décidé de faire une déclaration publique pour s'identifier et démontrer sa capacité à pirater leur système. Ses tentatives répétées pour avertir la Follett Corporation de manière éthique sont restées sans réponse, tandis que le logiciel restait vulnérable et que des quantités considérables de données sur les étudiants étaient relativement faciles d'accès, car la plupart d'entre elles n'étaient pas cryptées.

Il s'est également mis en quête d'erreurs dans le logiciel d'une autre entreprise : Blackboard. Les données de Blackboard étaient certes cryptées, mais des attaquants potentiels auraient pu y accéder et s'emparer de millions d'autres enregistrements. Ce logiciel, tout comme le produit de Follett, était utilisé par son école.

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

Demirkapi a présenté ses résultats lors de l'AUF JEDEN FALL de cette année, où les détails les plus malicieux de ses facéties ont été applaudis par le public. À juste titre, vraiment. Bien qu'il ait été initialement mal vu et qu'il ait dû surmonter de nombreux obstacles pour faire reconnaître ses découvertes, la société Follett Corporation lui aurait été reconnaissante de ses efforts et aurait suivi ses conseils pour finalement sécuriser son logiciel et éviter la crise qui aurait pu devenir une nouvelle statistique sur les violations de la protection des données. Après avoir obtenu son diplôme d'études secondaires, il fréquentera également le Rochester Institute of Technology. Il est donc clair qu'il est en bonne voie pour devenir un spécialiste de la sécurité très recherché.

Étant moi-même agent de sécurité, il m'est difficile de ne pas avoir de réserves quant à la manière dont cette situation a été gérée. Même si tout s'est bien terminé dans ce cas précis, il a d'abord été traité comme un adolescent indiscipliné qui se mêle de ce qui ne le regarde pas. Une recherche Google sur cet incident renvoie des articles le qualifiant de « hacker » (aux yeux des profanes en matière de sécurité, cela le positionne à bien des égards comme un méchant), alors que son approche (et celle de beaucoup d'autres) contribue en réalité à protéger nos données.

Nous avons besoin de personnes curieuses, intelligentes et soucieuses de la sécurité qui examinent les rouages du système, et nous avons besoin que cela se produise beaucoup plus souvent. En juillet, plus de quatre milliards d'enregistrements ont été exposés cette année seulement à la suite de violations malveillantes de la protection des données. Ce chiffre pourrait augmenter de cinquante millions supplémentaires grâce à la violation de la marque de mode et de style de vie Poshmark en août.

Nous commettons les mêmes erreurs, et ce qui est encore plus préoccupant, c'est qu'il s'agit souvent de failles de sécurité simples qui nous font trébucher à maintes reprises.

Le Cross-Site-Scripting et l'injection SQL n'ont pas disparu.

Comme l'a rapporté VERKABELT, le logiciel Blackboards Community Engagement et le système d'information étudiant Folletts ont été identifiés par Demirkapi comme présentant des failles de sécurité courantes telles que le Cross-Site Scripting (XSS) et l'injection SQL, qui sont une préoccupation pour les spécialistes de la sécurité depuis les années 1990. Nous avons toléré leur existence pendant un certain temps, en réalité pendant très longtemps, et à l'instar des t-shirts Hypercolor et des disquettes, elles devraient désormais appartenir au passé.

Cependant, ce n'est pas le cas, et il est évident que trop peu de développeurs ont une conscience suffisante des questions de sécurité pour empêcher leur introduction dans leur code. Les outils d'analyse et les vérifications manuelles du code ont une efficacité limitée, et il existe des problèmes de sécurité bien plus complexes que les injections XSS et SQL, pour lesquels ces mesures coûteuses et chronophages pourraient être mieux utilisées.

Des personnes telles que Bill Demirkapi devraient inspirer les développeurs à établir des normes de codage plus élevées. À seulement 17 ans, il a réussi à pénétrer deux systèmes très fréquentés en exploitant des vecteurs de menace qui auraient dû être détectés et corrigés avant même que le code ne soit publié.

Gamification : la clé de l'engagement ?

J'ai beaucoup écrit pour expliquer pourquoi les développeurs continuent de se désintéresser largement de la question de la sécurité, et la réponse courte est que peu d'efforts sont déployés, tant au niveau organisationnel qu'éducatif, pour encourager les développeurs à être attentifs à la sécurité. Si les entreprises prennent le temps de mettre en place une culture de la sécurité qui récompense et reconnaît l'engagement, notamment en mettant en place des formations qui parlent le langage des développeurs et les motivent à persévérer, ces vestiges gênants que sont les failles de sécurité disparaîtront progressivement des logiciels que nous utilisons.

Demirkapi manifeste un intérêt particulier pour la sécurité et a pris le temps d'apprendre à rétroconcevoir des logiciels malveillants, à détecter des bogues et, en quelque sorte, à perturber des éléments qui semblent inaltérables de l'extérieur. Cependant, lors d'une conversation avec LASTER (et à travers ses présentations DEF CON), il a fait une déclaration intéressante concernant son autoformation... il l'a transformée en jeu :

« Dans le but de découvrir quelque chose dans le logiciel de mon école, cela a été une manière divertissante et ludique de me former moi-même à de nombreux tests de pénétration. Bien que j'aie commencé mes recherches dans l'intention d'approfondir mes connaissances, j'ai constaté que la situation était bien plus grave que ce à quoi je m'attendais », a-t-il déclaré.

Bien que tous les développeurs ne souhaitent pas se spécialiser dans la sécurité, chacun devrait avoir la possibilité de se familiariser avec les questions de sécurité, les principes fondamentaux servant en quelque sorte de « licence de programmation » au sein d'une organisation, en particulier pour ceux qui contrôlent les quantités considérables de données sensibles. Si les failles de sécurité les plus simples peuvent être corrigées par chaque développeur avant même d'être écrites, nous serons dans une position beaucoup plus sûre face à ceux qui cherchent à semer le chaos.

Vous êtes intéressé par la formation ludique ? Découvrez notre série Coders Conquer Security. XSS et injection SQL.