On dit que la programmation est ce qui se rapproche le plus de la magie aujourd’hui. Et vous savez quoi ? C’est vrai. Quelques lignes de code qui ressemblent à du charabia pour les non-initiés — et vous pouvez créer des mondes entiers. Comment cela pourrait-il être autre chose que de la magie ?
De l’autre côté, quelques lignes de code différentes peuvent créer les systèmes de sécurité les plus élaborés. Mais plus ils sont élaborés, plus leur chute est lourde. C’est là qu’interviennent les menaces de sécurité logicielle. Des menaces comme la mauvaise configuration de sécurité rendent les systèmes, grands et petits, vulnérables à toutes sortes de cyberattaques.
La mauvaise configuration de sécurité est-elle cependant la menace la plus pressante ? Et qu’implique ce terme, pour être honnête, quelque peu vague ? Lisez la suite pour le découvrir.
Mauvaise configuration de sécurité : explications, exemples et prévention
Un terme générique (dans une certaine mesure), la mauvaise configuration de sécurité couvre les contrôles de sécurité laissés non sécurisés ou mal configurés, mettant les données et, parfois, l’ensemble du système en danger. En termes simples, tout problème technique au sein d’un composant pouvant découler des paramètres de configuration de l’application et non d’un mauvais code peut être classé comme une vulnérabilité de mauvaise configuration de sécurité.
Des paramètres par défaut mal gérés, des modifications de configuration insuffisamment documentées, des autorisations incorrectes — tout cela tombe sous ce parapluie.
Les cas les plus fréquents proviennent généralement des erreurs les plus simples (comme les exemples ci-dessous). Mais il n’y a rien de simple dans les conséquences auxquelles les organisations font souvent face en raison de ces erreurs. De l’exposition de données sensibles à la prise de contrôle complète de serveurs, de pages web et d’applications, la mauvaise configuration de sécurité a causé de sérieux dommages à d’innombrables entreprises par le passé. Et, considérant la 5e place sur le classement OWASP des 10 principaux risques de sécurité des applications web que cette menace a obtenue l’année dernière, elle ne va nulle part. Vous pouvez donc espérer qu’elle vous épargnera, ou vous pouvez en apprendre davantage sur la mauvaise configuration de sécurité, notamment comment la prévenir et la gérer.
Cela vous semble intéressant ? Allons-y.
Comment se produit la mauvaise configuration de sécurité
Comme nous l’avons appris précédemment, il existe des raisons plus complexes et inhabituelles de vulnérabilité de mauvaise configuration de sécurité, mais il en existe aussi des très simples et courantes. Ces dernières incluent :
Débogage activé
La plupart des entreprises travaillent avec des environnements séparés. Imaginez ceci : vous activez le débogage dans un environnement de développement pour accélérer le processus de débogage. Rien d’inhabituel, n’est-ce pas ?
Mais il n’y a rien d’inhabituel non plus à oublier de désactiver cette petite fonctionnalité avant la phase de production. Ainsi, tout ce que les attaquants ont à faire, c’est déclencher des erreurs détaillées contenant des données internes et, et voilà, ils sont DEDANS.
Identifiants par défaut
Une préoccupation banale la plupart du temps, mais les identifiants par défaut peuvent, parfois, causer également de sérieux ravages. Et, neuf fois sur dix, la mauvaise configuration de sécurité en est la cause.
Vous voyez, les identifiants par défaut sont généralement livrés avec une multitude de solutions intégrées. On les retrouve dans les applications web, les différents dispositifs réseau, pratiquement tout ce qui nécessite une authentification. Et, lorsque vous ne les modifiez pas une fois l’installation terminée, vous ouvrez grand les portes. Et, qui l’eût cru, les premières personnes à franchir ces portes sont généralement les hackers.
Autorisations mal configurées
La négligence. C’est toujours la négligence. Mais oui, même les meilleurs développeurs oublieront parfois de définir les bonnes autorisations sur des répertoires exposés (publiquement aussi), des consoles d’administration et des tableaux de bord. Ainsi, même les hackers les moins qualifiés peuvent accéder à ces fichiers non autorisés sans problème.
Vous pourriez penser que le problème ici est un exploit de contrôle d’accès défaillant, mais ce n’est pas le cas. Non, le BAC est le résultat, mais le responsable ici est un problème de mauvaise configuration de sécurité. Il était présent avant que le module n’atteigne une quelconque fonctionnalité de l’application web, c’est simplement que vous le découvrez généralement à ce stade.
Mauvaise configuration dans le cloud
Le cloud est une belle chose. Grâce aux solutions de stockage cloud et de partage de fichiers, les petites entreprises comme les grandes peuvent déployer des centres de données entiers en quelques minutes, sans se soucier de ne pas disposer des ressources nécessaires.
Mais avec une grande liberté vient une grande… vous connaissez la suite. Qui plus est, les entreprises qui utilisent ces solutions doivent suivre le modèle de responsabilité partagée. C’est-à-dire que ce qui se passe dans le cloud reste dans le cloud est la responsabilité du client, pas des propriétaires du service cloud.
Ce que cela signifie également, c’est que, qu’on le veuille ou non, les violations qui surviennent en raison d’une mauvaise configuration de sécurité dans le cloud continueront à se produire. Pour vous donner un exemple rapide de vulnérabilité de mauvaise configuration de sécurité, les mauvaises configurations d’Amazon S3 à elles seules ont généré plus de 400 000 résultats Google, incluant des violations de sécurité des plus grands noms du secteur.
Mauvaise configuration matérielle
De l’autre côté, les dispositifs réseau et de sécurité peuvent également être mal configurés, causant de réels problèmes à la fois à long terme et dès le départ.
Ce qui arrive assez fréquemment, c’est que les ingénieurs réseau font preuve d’un peu de laxisme dans les configurations des dispositifs réseau. Et, nous le comprenons, le dépannage des problèmes réseau peut être fastidieux. Mais ce n’est pas une raison d’oublier la configuration de sécurité suivante.
Car lorsque vous ne le faites pas (ou lorsque vous le faites à moitié), les attaquants pourraient avoir la possibilité d’accéder aux ressources internes, d’exécuter des shells inversés sans aucune restriction, et bien plus encore. De plus, des solutions mal configurées comme IPS, SIEM et IDS peuvent créer d’autres vulnérabilités de sécurité. Pour en citer une : lorsque vous oubliez de configurer un shell lié lors de la phase d’intervention, les hackers n’auront aucun mal à défigurer votre page web.
Et ce n’est qu’effleurer la surface. Les vulnérabilités de mauvaise configuration de sécurité se produisent également en raison de :
- L’activation de fonctionnalités inutiles (généralement par défaut) comme des services, comptes, privilèges, ports, pages inutiles, etc.
- Le recours à des en-têtes et répertoires non sécurisés ou leur configuration à des valeurs non sécurisées
- Le manque d’attention aux paramètres de sécurité (c’est-à-dire aussi NE PAS les définir à des valeurs sécurisées) dans les serveurs d’applications, les frameworks d’applications, les bibliothèques, les bases de données, etc.
- L’utilisation de composants vulnérables et/ou obsolètes (qui, soit dit en passant, figure juste derrière la mauvaise configuration de sécurité dans le classement OWASP des 10 principaux risques de sécurité des applications web mentionné ci-dessus)
- L’absence de mesures de durcissement de sécurité appropriées dans l’ensemble de la pile applicative (pratiquement n’importe quelle partie de celle-ci)
- Et, last but not least, ne pas désactiver les comptes par défaut avec des mots de passe standard (oui, croyez-le ou non, cela arrive TRÈS souvent).
Cela semble encore un peu vague ? Examinons quelques exemples de scénarios d’attaque par mauvaise configuration.
Scénarios d’attaque possibles
Le serveur d’application est livré avec des exemples d’applications qui n’ont pas été retirés du serveur de production. Souvent, ces exemples d’applications incluent des failles de sécurité connues, des failles que les attaquants peuvent exploiter pour compromettre votre nouveau serveur. Supposons que l’une de ces applications soit une console d’administration avec des comptes par défaut activés. Dans ce cas, tout ce que les hackers ont à faire, c’est accéder à cette console avec un mot de passe par défaut et, c’est tout, ils sont désormais aux commandes.
L’exploration de répertoires n’a pas été désactivée. Encore une fois, un scénario pas si rare, aussi regrettable soit-il. Les hackers sondent les serveurs pour cette vulnérabilité en priorité. Supposons donc qu’ils découvrent qu’ils peuvent simplement lister les répertoires. Un peu plus compliqué, mais des attaquants expérimentés n’auront alors aucun mal à trouver et télécharger les classes Java compilées. À partir de là, ils peuvent les décompiler et les rétro-ingénier pour voir le code du serveur. À ce stade, localiser une faille critique de contrôle d’accès dans l’application n’est plus qu’une question de temps.
Le serveur d’application est configuré pour renvoyer des messages d’erreur détaillés (comme des traces de pile) aux utilisateurs. Dans ce scénario, vous pouvez laisser toutes sortes de failles sous-jacentes exposées. Des informations sensibles, certes, mais aussi les versions des composants qui ont des vulnérabilités bien connues. Lorsqu’ils les découvrent, il n’y a pas de limite à ce que les hackers pourraient faire avec votre serveur. Et, comme vous pouvez l’imaginer, tout ce qu’ils ont à faire (et, selon toute probabilité, FERONT) est de demander ces messages d’erreur détaillés, ce qui est un jeu d’enfant.
Le cloud a des autorisations de partage par défaut ouvertes (et disponibles pour quiconque demande) par d’autres utilisateurs du service. Vous vous souvenez du modèle de responsabilité partagée mentionné précédemment ? C’est bien celui-là. Cela signifie que, parfois, il n’est même pas nécessaire que ce soit vous. Il suffit qu’un de vos voisins dans le cloud oublie de désactiver les autorisations par défaut et, en les utilisant, les cybercriminels peuvent accéder à vos données sensibles au sein de ce service de stockage cloud. Selon ces autorisations, les hackers pourraient même être en mesure d’obtenir un accès de haut niveau au système.
Vous pensez que ce ne sont que des hypothèses qui ne se produisent pas dans la réalité ? Détrompez-vous.
Exemples réels de mauvaise configuration de sécurité
Les problèmes de vulnérabilité de mauvaise configuration de sécurité sont aussi anciens que les mesures de sécurité elles-mêmes, nous avons donc vu d’innombrables exemples dans le passé. En voici quelques-uns :
L’incident NASA/Jira
On aurait pu penser que l’une des entreprises les plus avancées technologiquement et les plus axées sur le progrès au monde en saurait davantage. Hélas, ce n’était pas le cas.
Il a suffi d’un humble passionné de sécurité pour identifier une mauvaise configuration de sécurité dans l’outil de collaboration le plus utilisé (et peut-être le plus controversé) — Jira. Ce moment de mauvaise configuration d’autorisation par défaut a laissé plusieurs entreprises du Fortune 500, dont la NASA, vulnérables. Grâce à cette vulnérabilité, des tiers pouvaient accéder aux données internes des utilisateurs, notamment les noms, les adresses e-mail, les détails des projets et d’autres informations sensibles.
Que s’est-il passé ? Lorsque Jira a développé des tableaux de bord et des filtres pour des tickets individuels ou des projets entiers, les paramètres de visibilité ont été définis par défaut sur Tous les utilisateurs et Tout le monde. Bien sûr, idéalement, des éléments comme les tâches de feuille de route auraient dû être partagés au sein de l’organisation, mais le « bien-aimé » Jira les a partagés avec le public.
Point clé : Assurez-vous de vérifier les configurations de partage de fichiers dans chaque SaaS que vous utilisez pour éviter d’exposer des données confidentielles.
Les déboires d’Amazon S3
Le Simple Storage Service d’Amazon, également connu sous le nom d’Amazon S3, a été exploité par des hackers plus de fois qu’on ne peut le compter. Du bucket S3 mal configuré qui a révélé 50 000 dossiers de patients aux États-Unis à ceux qui ont exposé plus de 80 municipalités américaines, les attaquants n’ont épargné personne.
Même l’United States Army Intelligence and Security Command a divulgué plusieurs fichiers sensibles par le passé via Amazon S3, notamment des volumes OVA (Oracle Virtual Appliance) avec des parties marquées top secret.
Point clé : Le fait que des centaines de corporations (y compris des agences militaires et gouvernementales) s’appuient sur Amazon S3 ne signifie pas qu’il est sécurisé. En fait, compte tenu des dizaines d’incidents de sécurité passés, vous devriez surveiller attentivement les autorisations du service si vous décidez de l’utiliser.
Comment prévenir la mauvaise configuration de sécurité
Vous vous souvenez de la façon dont se produisent les mauvaises configurations de sécurité ? C’est exactement ce que vous devriez éviter de faire. En d’autres termes :
Désactivez le débogage. Lorsque vous déplacez l’application de la phase de développement à la phase de production, assurez-vous de vérifier deux fois toutes les fonctionnalités de débogage dans l’ensemble de la configuration. C’est juste, elles doivent TOUTES être désactivées.
Modifiez les identifiants par défaut. La première chose que vous devriez faire une fois un logiciel installé est de changer les identifiants par défaut. En fait, nous vous recommandons d’en faire une habitude obligatoire au sein de votre entreprise.
Limitez l’accès aux panneaux d’administration et aux consoles. La deuxième pratique obligatoire que vous devriez mettre en œuvre à l’échelle de l’entreprise est la désactivation de l’accès aux outils d’administration avant le déploiement. Il va sans dire que seuls les utilisateurs qui en ont besoin devraient y avoir accès. De même, assurez-vous de respecter cette pratique lors d’audits systématiques.
Désactivez l’exploration de répertoires et vérifiez les autorisations des répertoires. L’application déployée ne doit pas autoriser l’exploration de répertoires, tout simplement. En dehors de cela, assurez-vous que les autorisations sur les dossiers et fichiers séparés sont correctement définies.
Appliquez des mesures de durcissement de sécurité reproductibles. Lorsqu’il est correctement configuré, un processus de durcissement reproductible permettra de déployer d’autres environnements (également correctement sécurisés) rapidement et facilement. Assurez-vous donc que les environnements de développement, de QA et de production sont configurés de manière identique, en utilisant des identifiants différents pour chaque environnement. Automatisez-le et vous pourrez configurer de nouveaux environnements sécurisés sans effort.
Utilisez une architecture d’application segmentée. Une architecture d’application segmentée assure une séparation efficace et, plus important encore, sécurisée entre ses composants et ses locataires. En plus de la segmentation, l’architecture devrait intégrer la conteneurisation et/ou des groupes de sécurité cloud (ACL).
Maintenez la plateforme propre. Débarrassez-vous de toutes les fonctionnalités, composants, documentations et exemples inutiles. En plus d’être pratiquement inutiles (d’où le terme « inutiles »), ils représentent également une menace pour la sécurité. Supprimez également tous les frameworks que vous n’utilisez pas. Idéalement, vous n’auriez pas dû les installer en premier lieu.
Récapitulatif
La mauvaise configuration de sécurité est un terme générique désignant tout contrôle de sécurité non sécurisé ou mal configuré. Lorsqu’elle est exploitée, elle permet aux hackers d’accéder à des informations confidentielles ou de prendre le contrôle de l’ensemble de la page web, du serveur ou de l’application. L’impact de la mauvaise configuration de sécurité a paralysé d’innombrables géants dans le passé. Assurez-vous donc de vous informer sur le sujet et de suivre les conseils de prévention de la mauvaise configuration de sécurité que nous avons abordés ci-dessus. Bonne continuation et que les probabilités jouent toujours en votre faveur.
Configurez-le correctement : le guide de référence ultime pour prévenir la mauvaise configuration de sécurité
