Un avis ? Un commentaire ?
Cet espace est pour vous.
Notre série d’article sur le défi de Ministry of Testing, 30 Days of Security Testing, se termine aujourd’hui avec un article dans lequel sont regroupé les défis qui permettent d’enrichir sa connaissance générale des tests de sécurité (actualités, aspects sociologiques, mises en application).
Pour rappel, en anglais « to hack » veut simplement dire « bidouiller », il n’y a pas de connotation négative en soi.
Alors que le hacker malveillant (ou black hat) tire profit des failles de sécurité à des fins personnelles, l’ethical hacker (ou white hat) les documente et propose des pistes afin de les solutionner. Il est en possession de toutes les autorisations nécessaires pour entrer dans le système à tester.
Comme vu précédemment, certaines entreprises embauchent des spécialistes en tests de sécurité (qui, par nature, sont des ethical hackers) afin de réaliser un audit. D’autres choisissent de récompenser les personnes qui leur rapportent bénévolement des failles de sécurité découvertes dans les limites de la légalité. Ces récompenses sont appelées « bounties ».
Si le hacker entre dans le système sans disposer des autorisations nécessaires, mais ne commet aucun acte malveillant, on parle de hacker « gray hat ». Des sites comme CVE Details (common vulnerabilities exposure) ou NVD (National Vulnerability Database) répertorient les failles de sécurité d’une multitude de produits.
L’imagerie populaire du hacker est déconcertante : nous serions tentés de croire que tous portent une capuche en permanence. En cause, une méconnaissance de l’activité de hacking, comme en témoigne cette interview d’un photographe de la banque d’images Shutterstock. Il serait pourtant utile que l’activité de hacking, de même que la sécurité informatique, soit mieux comprise, afin que chacun puisse mettre en oeuvre le nécessaire pour se protéger.
Lorsqu’une faille de sécurité est découverte dans un SI, volontairement ou non, le fait de la rapporter à l’organisation concernée sans exploiter la faille est appelé « disclosure ». Un acte bénévole dont il peut être risqué de parler, comme l’a montré en 2009 l’affaire Forever living products contre Zataz. Le fait de rendre une faille publique avant sa correction (chose que n’avait pas fait Zataz) est appelé « full disclosure ».
L’équipe Project Zero, qui regroupe sous l’égide de Google des spécialistes en sécurité informatique, a pour objectif de trouver des failles de sécurité « zero day », c’est-à-dire n’ayant jamais été exploitées. Leur ligne de conduite : informer immédiatement l’organisation responsable de l’application (disclosure), et ne procéder à une full disclosure qu’après que celle-ci a fourni un patch, ou au bout de 90 jours.
Le 25 novembre dernier, Google a informé Microsoft d’une faille de sécurité présente dans les navigateurs Internet Explorer et Edge. Malheureusement, Microsoft n’a pas été en mesure de fournir un patch dans les temps, et la faille est désormais publique et exploitable même dans la dernière version ! Voici son ticket d’anomalie.
Une attaque DDOS (Distributed Denial Of Service) est une attaque visant à rendre indisponible un serveur. Son qualificatif « Distributed » est employé lorsque l’attaque provient de plusieurs machines différentes. Lorsque l’origine est une unique machine, on parle simplement d’attaque DOS.
On peut distinguer les attaques DDOS réseau et applicatives. Dans le premier cas, on sature la connexion réseau d’un serveur afin de le rendre incapable de répondre aux requêtes. Dans le second, après identification des actions de l’application qui demandent beaucoup de ressources (par exemple, des calculs impactant de nombreuses lignes en base de donnée), l’attaque consiste à les répéter jusqu’à saturation du serveur (source).
Un site web permet de visualiser sur une carte les récentes attaques DDOS.
La liste des 10 failles de sécurité les plus courantes est éditée tous les trois ans par la fondation OWASP. La liste qui devait paraître en 2016 a été repoussée en 2017. L’équipe OWASP explique que le classement est resté sensiblement le même. Voici donc le classement de 2013.
Les tests à effectuer dépendent des menaces inhérentes à un système donné.
Certaines menaces sont propres aux applications web, comme les vulnérabilités liées aux cookies. Ces petits fichiers, stockés sur la machine cliente au cours de la navigation, qui contiennent des informations utiles : pages visitées, actions effectuées sur le site, mots de passe.
D’autres sont spécifiques aux applications mobiles, qui demandent des permissions susceptibles de compromettre les informations personnelles de l’utilisateur.
Mais les frontières des menaces tendent à se brouiller, notamment avec l’essor de frameworks tels que Cordova ou Ionic, qui permettent de développer des applications mobiles en se servant de technologies web. Les applications mobiles ne sont plus, logiquement, à l’abri des injections Javascript.
BYOA signifie « bring your own application » : cette tendance désigne par exemple les employés utilisant Google Docs avec leur compte personnel en lieu et place du SharePoint de leur entreprise. On parle aussi de shadow IT.
Plusieurs points peuvent être soulevés :
Pour répondre à ces risques, certaines entreprises mettent en place une politique d’utilisation de logiciels tiers afin de sensibiliser aux menaces de cette tendance et de responsabiliser les employés.
Nous avons choisi de ne pas nous pencher sur un domaine en particulier, mais plutôt sur un type d’applicatif que nous utilisons quotidiennement : les logiciels open-source.
Logiquement, les failles d’un logiciel open source sont plus susceptibles d’être découvertes par le public que celles d’un logiciel propriétaire. Mais elles sont également plus susceptibles d’être révélées à son éditeur par la communauté, et donc plus vite corrigées. A contrario, les failles d’un logiciel propriétaires ne sont susceptibles d’être découvertes que par son éditeur lui-même, ou par les hackers black et grey hat. Les logiciels propriétaires ne sont pas à l’abris du reverse engineering, une pratique pourtant souvent interdite par les conditions générales d’utilisation.
Voici quelques articles ressources que nous avons trouvé sur le sujet :
Voilà qui est fait. Déjà la fin des 28 jours de test de sécurité ! Si vous aussi avez participé au défi, laissez-nous un commentaire avec vos articles de blog, nous sommes curieux de les lire.
Notre saga du test audiovisuel
Cet espace est pour vous.