Blog

Les codeurs conquièrent la sécurité Série "Infrastructure as Code" : Stockage des mots de passe en clair

Matias Madou, Ph.D.
Publié le 18 mai 2020

Lorsqu'il s'agit de déployer une infrastructure sécurisée sous forme de code dans votre propre organisation, où en êtes-vous ? Il peut s'agir d'une courbe d'apprentissage, mais le fait d'apprendre les ficelles du métier vous permettra d'améliorer vos compétences, de vous démarquer de vos pairs et d' assurer la sécurité des données des utilisateurs finaux.

Avant de commencer ce nouveau chapitre de notre dernière série Coders Conquer Security, j'aimerais vous inviter à jouer à un défi gamifié de la vulnérabilité du stockage des données sensibles ; jouez maintenant et choisissez entre Kubernetes, Terraform, Ansible, Docker ou CloudFormation :

Comment cela s'est-il passé ? Si vos connaissances ont besoin d'être approfondies, lisez ce qui suit :

De nos jours, les mots de passe sont la clé de la plupart des sécurités informatiques. Même si d'autres méthodes de sécurité sont utilisées, comme l'authentification à deux facteurs ou la biométrie, la plupart des organisations utilisent toujours la sécurité basée sur les mots de passe comme un élément de leur protection. Pour de nombreuses entreprises, les mots de passe sont utilisés exclusivement.

Nous utilisons tellement les mots de passe que nous avons même des règles sur la manière de les créer. Cela est censé les rendre moins vulnérables aux attaques par force brute ou même aux devinettes. Bien entendu, certaines personnes continuent d'utiliser des mots de passe faibles, comme le montre un rapport récent de NordPass. Il est difficile de croire qu'en 2020, les gens utilisent encore 12345 ainsi qu'un tas d'autres mots devinables comme chocolat, mot de passe et Dieu pour protéger leurs actifs les plus sensibles.

Il y aura toujours des personnes qui ne se soucient pas d'utiliser des mots de passe forts, mais la plupart des organisations professionnelles obligent les utilisateurs à rédiger leurs mots ou phrases d'accès d'une certaine manière. Nous connaissons tous les règles : les mots de passe doivent comporter au moins huit caractères et être composés de lettres majuscules et minuscules, avec au moins un chiffre et un caractère spécial.

Le problème, c'est que même si les utilisateurs respectent les règles relatives à la création des mots de passe les plus forts, cela ne sert à rien si tous les mots de passe sont stockés en clair. Le mot de passe 12345 est tout aussi mauvais que Nuts53!SpiKe&Dog12 si un pirate informatique est en mesure de lire l'intégralité du fichier de mots de passe.

Pourquoi est-il dangereux de stocker des mots de passe en clair ?

Le stockage des mots de passe en clair est une mauvaise chose car il met en danger à la fois le système et les utilisateurs. Il est évident qu'un pirate informatique capable de trouver et de lire chaque mot de passe utilisé pour accéder à un système serait un désastre. Il lui suffirait de trouver un utilisateur disposant d'identifiants d'administrateur pour compromettre l'ensemble du système ou du site. Et comme il utiliserait des noms d'utilisateur et des mots de passe appropriés, la sécurité interne pourrait ne pas détecter l'intrusion ou la détecter longtemps après que les dégâts ont été causés.

Faciliter le vol des mots de passe stockés en clair par les attaquants nuit également aux utilisateurs, car de nombreuses personnes réutilisent leurs mots de passe. Parce que nous avons rendu les mots de passe si difficiles à créer, beaucoup de gens réutilisent ceux dont ils se souviennent sur plusieurs sites. Si un pirate compromet un fichier de mots de passe, il essaiera presque certainement d'accéder à d'autres systèmes en utilisant le même nom et le même mot de passe, ce qui expose les utilisateurs à un risque élevé de délits secondaires.

Il est relativement facile de stocker accidentellement des mots de passe en texte clair ou de ne pas se rendre compte que cela pourrait causer des problèmes majeurs à l'avenir. Par exemple, le code suivant est une méthode courante utilisée pour stocker les mots de passe lors de la définition d'une ressource AWS à l'aide de modèles Terraform :

ressource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

Dans cet exemple, le mot de passe utilisé pour gérer l'instance de la base de données MySQL dans AWS est stocké en clair. Cela signifie que toute personne ayant accès au dépôt de code source peut le lire, voire le copier.

La protection des mots de passe varie en fonction du cadre, mais il existe des méthodes de protection pour chaque plateforme. Par exemple, le mot de passe MySQL peut être stocké dans un espace de stockage sécurisé comme AWS Secrets Manager :

resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

Dans cet exemple, le modèle Terraform obtiendra le mot de passe du service AWS Secrets Manager et il ne sera jamais stocké en clair dans les fichiers du modèle.

Protéger les mots de passe en évitant le stockage en clair

Les mots de passe sont les clés de votre royaume et ne devraient jamais être stockés en clair. Même les personnes internes à une organisation ne devraient pas avoir accès à un grand dépôt non protégé de mots de passe, et cela ne devrait pas être un protocole d'entreprise accepté (il existe de nos jours de nombreux gestionnaires de mots de passe qui permettent le partage crypté des informations d'identification - pas d'excuses !) Il y a également le risque que des personnes internes malveillantes fouillent dans les fichiers et accèdent à des endroits où elles ne le devraient pas.

Et dans le cas d'une attaque extérieure, imaginez le double effet possible si une porte dérobée vers votre base de données est trouvée grâce à quelque chose d'aussi simple qu'une vulnérabilité d'injection SQL, et qu'ils accèdent également au répertoire où les mots de passe sont stockés. Vous pensez qu'il s'agit là d'un trop grand nombre d'étapes truffées d'erreurs pour que cela porte ses fruits ? Malheureusement, c'est exactement ce scénario qui s'est produit lors de la faille de Sony en 2011. Plus d'un million de mots de passe de clients étaient stockés en clair, et le groupe de pirates Lulzsec a accédé à ces mots de passe et à bien d'autres encore par le biais d'une banale attaque par injection SQL.

Tous les mots de passe doivent être protégés par les défenses disponibles dans le cadre d'appui. Pour Terraform, les mots de passe ne doivent jamais être stockés dans des fichiers modèles. Il est recommandé d'utiliser un stockage sécurisé comme AWS Secrets Manager ou Azure Key Vault, en fonction du fournisseur d'infrastructure.

Obliger les utilisateurs à créer des mots de passe sécurisés est une bonne idée, mais vous devez également faire votre part du travail en arrière-plan. Le fait de ne pas stocker les mots de passe en clair contribuera grandement à la protection de vos utilisateurs et de vos systèmes. Le principal danger du stockage des mots de passe en clair est la faiblesse du contrôle d'accès ; en fait, tout le monde peut les voir. Il est impératif (en particulier dans un environnement IaC où soudainement, davantage de personnes ont accès à des informations sensibles) que les mots de passe soient hachés de manière adéquate et que seules les personnes qui ont absolument besoin d'y accéder puissent le faire.

Consultez les pages du Secure Code Warrior pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients contre les ravages causés par d'autres failles de sécurité et vulnérabilités. Vous pouvez également essayer un défi IaC de démonstration sur la plateforme de formation Secure Code Warrior pour maintenir vos compétences en matière de cybersécurité à jour.


Voir la ressource
Voir la ressource

De nos jours, les mots de passe sont la clé de la plupart des sécurités informatiques. Même si d'autres méthodes de sécurité sont utilisées, comme l'authentification à deux facteurs ou la biométrie, la plupart des organisations utilisent toujours la sécurité par mot de passe comme un élément de leur protection.

Vous souhaitez en savoir plus ?

Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Réservez une démonstration
Partager sur :
Auteur
Matias Madou, Ph.D.
Publié le 18 mai 2020

Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.

Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.

Partager sur :

Lorsqu'il s'agit de déployer une infrastructure sécurisée sous forme de code dans votre propre organisation, où en êtes-vous ? Il peut s'agir d'une courbe d'apprentissage, mais le fait d'apprendre les ficelles du métier vous permettra d'améliorer vos compétences, de vous démarquer de vos pairs et d' assurer la sécurité des données des utilisateurs finaux.

Avant de commencer ce nouveau chapitre de notre dernière série Coders Conquer Security, j'aimerais vous inviter à jouer à un défi gamifié de la vulnérabilité du stockage des données sensibles ; jouez maintenant et choisissez entre Kubernetes, Terraform, Ansible, Docker ou CloudFormation :

Comment cela s'est-il passé ? Si vos connaissances ont besoin d'être approfondies, lisez ce qui suit :

De nos jours, les mots de passe sont la clé de la plupart des sécurités informatiques. Même si d'autres méthodes de sécurité sont utilisées, comme l'authentification à deux facteurs ou la biométrie, la plupart des organisations utilisent toujours la sécurité basée sur les mots de passe comme un élément de leur protection. Pour de nombreuses entreprises, les mots de passe sont utilisés exclusivement.

Nous utilisons tellement les mots de passe que nous avons même des règles sur la manière de les créer. Cela est censé les rendre moins vulnérables aux attaques par force brute ou même aux devinettes. Bien entendu, certaines personnes continuent d'utiliser des mots de passe faibles, comme le montre un rapport récent de NordPass. Il est difficile de croire qu'en 2020, les gens utilisent encore 12345 ainsi qu'un tas d'autres mots devinables comme chocolat, mot de passe et Dieu pour protéger leurs actifs les plus sensibles.

Il y aura toujours des personnes qui ne se soucient pas d'utiliser des mots de passe forts, mais la plupart des organisations professionnelles obligent les utilisateurs à rédiger leurs mots ou phrases d'accès d'une certaine manière. Nous connaissons tous les règles : les mots de passe doivent comporter au moins huit caractères et être composés de lettres majuscules et minuscules, avec au moins un chiffre et un caractère spécial.

Le problème, c'est que même si les utilisateurs respectent les règles relatives à la création des mots de passe les plus forts, cela ne sert à rien si tous les mots de passe sont stockés en clair. Le mot de passe 12345 est tout aussi mauvais que Nuts53!SpiKe&Dog12 si un pirate informatique est en mesure de lire l'intégralité du fichier de mots de passe.

Pourquoi est-il dangereux de stocker des mots de passe en clair ?

Le stockage des mots de passe en clair est une mauvaise chose car il met en danger à la fois le système et les utilisateurs. Il est évident qu'un pirate informatique capable de trouver et de lire chaque mot de passe utilisé pour accéder à un système serait un désastre. Il lui suffirait de trouver un utilisateur disposant d'identifiants d'administrateur pour compromettre l'ensemble du système ou du site. Et comme il utiliserait des noms d'utilisateur et des mots de passe appropriés, la sécurité interne pourrait ne pas détecter l'intrusion ou la détecter longtemps après que les dégâts ont été causés.

Faciliter le vol des mots de passe stockés en clair par les attaquants nuit également aux utilisateurs, car de nombreuses personnes réutilisent leurs mots de passe. Parce que nous avons rendu les mots de passe si difficiles à créer, beaucoup de gens réutilisent ceux dont ils se souviennent sur plusieurs sites. Si un pirate compromet un fichier de mots de passe, il essaiera presque certainement d'accéder à d'autres systèmes en utilisant le même nom et le même mot de passe, ce qui expose les utilisateurs à un risque élevé de délits secondaires.

Il est relativement facile de stocker accidentellement des mots de passe en texte clair ou de ne pas se rendre compte que cela pourrait causer des problèmes majeurs à l'avenir. Par exemple, le code suivant est une méthode courante utilisée pour stocker les mots de passe lors de la définition d'une ressource AWS à l'aide de modèles Terraform :

ressource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

Dans cet exemple, le mot de passe utilisé pour gérer l'instance de la base de données MySQL dans AWS est stocké en clair. Cela signifie que toute personne ayant accès au dépôt de code source peut le lire, voire le copier.

La protection des mots de passe varie en fonction du cadre, mais il existe des méthodes de protection pour chaque plateforme. Par exemple, le mot de passe MySQL peut être stocké dans un espace de stockage sécurisé comme AWS Secrets Manager :

resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

Dans cet exemple, le modèle Terraform obtiendra le mot de passe du service AWS Secrets Manager et il ne sera jamais stocké en clair dans les fichiers du modèle.

Protéger les mots de passe en évitant le stockage en clair

Les mots de passe sont les clés de votre royaume et ne devraient jamais être stockés en clair. Même les personnes internes à une organisation ne devraient pas avoir accès à un grand dépôt non protégé de mots de passe, et cela ne devrait pas être un protocole d'entreprise accepté (il existe de nos jours de nombreux gestionnaires de mots de passe qui permettent le partage crypté des informations d'identification - pas d'excuses !) Il y a également le risque que des personnes internes malveillantes fouillent dans les fichiers et accèdent à des endroits où elles ne le devraient pas.

Et dans le cas d'une attaque extérieure, imaginez le double effet possible si une porte dérobée vers votre base de données est trouvée grâce à quelque chose d'aussi simple qu'une vulnérabilité d'injection SQL, et qu'ils accèdent également au répertoire où les mots de passe sont stockés. Vous pensez qu'il s'agit là d'un trop grand nombre d'étapes truffées d'erreurs pour que cela porte ses fruits ? Malheureusement, c'est exactement ce scénario qui s'est produit lors de la faille de Sony en 2011. Plus d'un million de mots de passe de clients étaient stockés en clair, et le groupe de pirates Lulzsec a accédé à ces mots de passe et à bien d'autres encore par le biais d'une banale attaque par injection SQL.

Tous les mots de passe doivent être protégés par les défenses disponibles dans le cadre d'appui. Pour Terraform, les mots de passe ne doivent jamais être stockés dans des fichiers modèles. Il est recommandé d'utiliser un stockage sécurisé comme AWS Secrets Manager ou Azure Key Vault, en fonction du fournisseur d'infrastructure.

Obliger les utilisateurs à créer des mots de passe sécurisés est une bonne idée, mais vous devez également faire votre part du travail en arrière-plan. Le fait de ne pas stocker les mots de passe en clair contribuera grandement à la protection de vos utilisateurs et de vos systèmes. Le principal danger du stockage des mots de passe en clair est la faiblesse du contrôle d'accès ; en fait, tout le monde peut les voir. Il est impératif (en particulier dans un environnement IaC où soudainement, davantage de personnes ont accès à des informations sensibles) que les mots de passe soient hachés de manière adéquate et que seules les personnes qui ont absolument besoin d'y accéder puissent le faire.

Consultez les pages du Secure Code Warrior pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients contre les ravages causés par d'autres failles de sécurité et vulnérabilités. Vous pouvez également essayer un défi IaC de démonstration sur la plateforme de formation Secure Code Warrior pour maintenir vos compétences en matière de cybersécurité à jour.


Voir la ressource
Voir la ressource

Remplissez le formulaire ci-dessous pour télécharger le rapport

Nous aimerions que vous nous autorisiez à vous envoyer des informations sur nos produits et/ou sur des sujets liés au codage sécurisé. Nous traiterons toujours vos données personnelles avec le plus grand soin et ne les vendrons jamais à d'autres entreprises à des fins de marketing.

Soumettre
Pour soumettre le formulaire, veuillez activer les cookies "Analytics". N'hésitez pas à les désactiver à nouveau une fois que vous aurez terminé.

Lorsqu'il s'agit de déployer une infrastructure sécurisée sous forme de code dans votre propre organisation, où en êtes-vous ? Il peut s'agir d'une courbe d'apprentissage, mais le fait d'apprendre les ficelles du métier vous permettra d'améliorer vos compétences, de vous démarquer de vos pairs et d' assurer la sécurité des données des utilisateurs finaux.

Avant de commencer ce nouveau chapitre de notre dernière série Coders Conquer Security, j'aimerais vous inviter à jouer à un défi gamifié de la vulnérabilité du stockage des données sensibles ; jouez maintenant et choisissez entre Kubernetes, Terraform, Ansible, Docker ou CloudFormation :

Comment cela s'est-il passé ? Si vos connaissances ont besoin d'être approfondies, lisez ce qui suit :

De nos jours, les mots de passe sont la clé de la plupart des sécurités informatiques. Même si d'autres méthodes de sécurité sont utilisées, comme l'authentification à deux facteurs ou la biométrie, la plupart des organisations utilisent toujours la sécurité basée sur les mots de passe comme un élément de leur protection. Pour de nombreuses entreprises, les mots de passe sont utilisés exclusivement.

Nous utilisons tellement les mots de passe que nous avons même des règles sur la manière de les créer. Cela est censé les rendre moins vulnérables aux attaques par force brute ou même aux devinettes. Bien entendu, certaines personnes continuent d'utiliser des mots de passe faibles, comme le montre un rapport récent de NordPass. Il est difficile de croire qu'en 2020, les gens utilisent encore 12345 ainsi qu'un tas d'autres mots devinables comme chocolat, mot de passe et Dieu pour protéger leurs actifs les plus sensibles.

Il y aura toujours des personnes qui ne se soucient pas d'utiliser des mots de passe forts, mais la plupart des organisations professionnelles obligent les utilisateurs à rédiger leurs mots ou phrases d'accès d'une certaine manière. Nous connaissons tous les règles : les mots de passe doivent comporter au moins huit caractères et être composés de lettres majuscules et minuscules, avec au moins un chiffre et un caractère spécial.

Le problème, c'est que même si les utilisateurs respectent les règles relatives à la création des mots de passe les plus forts, cela ne sert à rien si tous les mots de passe sont stockés en clair. Le mot de passe 12345 est tout aussi mauvais que Nuts53!SpiKe&Dog12 si un pirate informatique est en mesure de lire l'intégralité du fichier de mots de passe.

Pourquoi est-il dangereux de stocker des mots de passe en clair ?

Le stockage des mots de passe en clair est une mauvaise chose car il met en danger à la fois le système et les utilisateurs. Il est évident qu'un pirate informatique capable de trouver et de lire chaque mot de passe utilisé pour accéder à un système serait un désastre. Il lui suffirait de trouver un utilisateur disposant d'identifiants d'administrateur pour compromettre l'ensemble du système ou du site. Et comme il utiliserait des noms d'utilisateur et des mots de passe appropriés, la sécurité interne pourrait ne pas détecter l'intrusion ou la détecter longtemps après que les dégâts ont été causés.

Faciliter le vol des mots de passe stockés en clair par les attaquants nuit également aux utilisateurs, car de nombreuses personnes réutilisent leurs mots de passe. Parce que nous avons rendu les mots de passe si difficiles à créer, beaucoup de gens réutilisent ceux dont ils se souviennent sur plusieurs sites. Si un pirate compromet un fichier de mots de passe, il essaiera presque certainement d'accéder à d'autres systèmes en utilisant le même nom et le même mot de passe, ce qui expose les utilisateurs à un risque élevé de délits secondaires.

Il est relativement facile de stocker accidentellement des mots de passe en texte clair ou de ne pas se rendre compte que cela pourrait causer des problèmes majeurs à l'avenir. Par exemple, le code suivant est une méthode courante utilisée pour stocker les mots de passe lors de la définition d'une ressource AWS à l'aide de modèles Terraform :

ressource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

Dans cet exemple, le mot de passe utilisé pour gérer l'instance de la base de données MySQL dans AWS est stocké en clair. Cela signifie que toute personne ayant accès au dépôt de code source peut le lire, voire le copier.

La protection des mots de passe varie en fonction du cadre, mais il existe des méthodes de protection pour chaque plateforme. Par exemple, le mot de passe MySQL peut être stocké dans un espace de stockage sécurisé comme AWS Secrets Manager :

resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

Dans cet exemple, le modèle Terraform obtiendra le mot de passe du service AWS Secrets Manager et il ne sera jamais stocké en clair dans les fichiers du modèle.

Protéger les mots de passe en évitant le stockage en clair

Les mots de passe sont les clés de votre royaume et ne devraient jamais être stockés en clair. Même les personnes internes à une organisation ne devraient pas avoir accès à un grand dépôt non protégé de mots de passe, et cela ne devrait pas être un protocole d'entreprise accepté (il existe de nos jours de nombreux gestionnaires de mots de passe qui permettent le partage crypté des informations d'identification - pas d'excuses !) Il y a également le risque que des personnes internes malveillantes fouillent dans les fichiers et accèdent à des endroits où elles ne le devraient pas.

Et dans le cas d'une attaque extérieure, imaginez le double effet possible si une porte dérobée vers votre base de données est trouvée grâce à quelque chose d'aussi simple qu'une vulnérabilité d'injection SQL, et qu'ils accèdent également au répertoire où les mots de passe sont stockés. Vous pensez qu'il s'agit là d'un trop grand nombre d'étapes truffées d'erreurs pour que cela porte ses fruits ? Malheureusement, c'est exactement ce scénario qui s'est produit lors de la faille de Sony en 2011. Plus d'un million de mots de passe de clients étaient stockés en clair, et le groupe de pirates Lulzsec a accédé à ces mots de passe et à bien d'autres encore par le biais d'une banale attaque par injection SQL.

Tous les mots de passe doivent être protégés par les défenses disponibles dans le cadre d'appui. Pour Terraform, les mots de passe ne doivent jamais être stockés dans des fichiers modèles. Il est recommandé d'utiliser un stockage sécurisé comme AWS Secrets Manager ou Azure Key Vault, en fonction du fournisseur d'infrastructure.

Obliger les utilisateurs à créer des mots de passe sécurisés est une bonne idée, mais vous devez également faire votre part du travail en arrière-plan. Le fait de ne pas stocker les mots de passe en clair contribuera grandement à la protection de vos utilisateurs et de vos systèmes. Le principal danger du stockage des mots de passe en clair est la faiblesse du contrôle d'accès ; en fait, tout le monde peut les voir. Il est impératif (en particulier dans un environnement IaC où soudainement, davantage de personnes ont accès à des informations sensibles) que les mots de passe soient hachés de manière adéquate et que seules les personnes qui ont absolument besoin d'y accéder puissent le faire.

Consultez les pages du Secure Code Warrior pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients contre les ravages causés par d'autres failles de sécurité et vulnérabilités. Vous pouvez également essayer un défi IaC de démonstration sur la plateforme de formation Secure Code Warrior pour maintenir vos compétences en matière de cybersécurité à jour.


Accès aux ressources

Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Voir le rapportRéservez une démonstration
Partager sur :
Vous souhaitez en savoir plus ?

Partager sur :
Auteur
Matias Madou, Ph.D.
Publié le 18 mai 2020

Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.

Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.

Partager sur :

Lorsqu'il s'agit de déployer une infrastructure sécurisée sous forme de code dans votre propre organisation, où en êtes-vous ? Il peut s'agir d'une courbe d'apprentissage, mais le fait d'apprendre les ficelles du métier vous permettra d'améliorer vos compétences, de vous démarquer de vos pairs et d' assurer la sécurité des données des utilisateurs finaux.

Avant de commencer ce nouveau chapitre de notre dernière série Coders Conquer Security, j'aimerais vous inviter à jouer à un défi gamifié de la vulnérabilité du stockage des données sensibles ; jouez maintenant et choisissez entre Kubernetes, Terraform, Ansible, Docker ou CloudFormation :

Comment cela s'est-il passé ? Si vos connaissances ont besoin d'être approfondies, lisez ce qui suit :

De nos jours, les mots de passe sont la clé de la plupart des sécurités informatiques. Même si d'autres méthodes de sécurité sont utilisées, comme l'authentification à deux facteurs ou la biométrie, la plupart des organisations utilisent toujours la sécurité basée sur les mots de passe comme un élément de leur protection. Pour de nombreuses entreprises, les mots de passe sont utilisés exclusivement.

Nous utilisons tellement les mots de passe que nous avons même des règles sur la manière de les créer. Cela est censé les rendre moins vulnérables aux attaques par force brute ou même aux devinettes. Bien entendu, certaines personnes continuent d'utiliser des mots de passe faibles, comme le montre un rapport récent de NordPass. Il est difficile de croire qu'en 2020, les gens utilisent encore 12345 ainsi qu'un tas d'autres mots devinables comme chocolat, mot de passe et Dieu pour protéger leurs actifs les plus sensibles.

Il y aura toujours des personnes qui ne se soucient pas d'utiliser des mots de passe forts, mais la plupart des organisations professionnelles obligent les utilisateurs à rédiger leurs mots ou phrases d'accès d'une certaine manière. Nous connaissons tous les règles : les mots de passe doivent comporter au moins huit caractères et être composés de lettres majuscules et minuscules, avec au moins un chiffre et un caractère spécial.

Le problème, c'est que même si les utilisateurs respectent les règles relatives à la création des mots de passe les plus forts, cela ne sert à rien si tous les mots de passe sont stockés en clair. Le mot de passe 12345 est tout aussi mauvais que Nuts53!SpiKe&Dog12 si un pirate informatique est en mesure de lire l'intégralité du fichier de mots de passe.

Pourquoi est-il dangereux de stocker des mots de passe en clair ?

Le stockage des mots de passe en clair est une mauvaise chose car il met en danger à la fois le système et les utilisateurs. Il est évident qu'un pirate informatique capable de trouver et de lire chaque mot de passe utilisé pour accéder à un système serait un désastre. Il lui suffirait de trouver un utilisateur disposant d'identifiants d'administrateur pour compromettre l'ensemble du système ou du site. Et comme il utiliserait des noms d'utilisateur et des mots de passe appropriés, la sécurité interne pourrait ne pas détecter l'intrusion ou la détecter longtemps après que les dégâts ont été causés.

Faciliter le vol des mots de passe stockés en clair par les attaquants nuit également aux utilisateurs, car de nombreuses personnes réutilisent leurs mots de passe. Parce que nous avons rendu les mots de passe si difficiles à créer, beaucoup de gens réutilisent ceux dont ils se souviennent sur plusieurs sites. Si un pirate compromet un fichier de mots de passe, il essaiera presque certainement d'accéder à d'autres systèmes en utilisant le même nom et le même mot de passe, ce qui expose les utilisateurs à un risque élevé de délits secondaires.

Il est relativement facile de stocker accidentellement des mots de passe en texte clair ou de ne pas se rendre compte que cela pourrait causer des problèmes majeurs à l'avenir. Par exemple, le code suivant est une méthode courante utilisée pour stocker les mots de passe lors de la définition d'une ressource AWS à l'aide de modèles Terraform :

ressource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

Dans cet exemple, le mot de passe utilisé pour gérer l'instance de la base de données MySQL dans AWS est stocké en clair. Cela signifie que toute personne ayant accès au dépôt de code source peut le lire, voire le copier.

La protection des mots de passe varie en fonction du cadre, mais il existe des méthodes de protection pour chaque plateforme. Par exemple, le mot de passe MySQL peut être stocké dans un espace de stockage sécurisé comme AWS Secrets Manager :

resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

Dans cet exemple, le modèle Terraform obtiendra le mot de passe du service AWS Secrets Manager et il ne sera jamais stocké en clair dans les fichiers du modèle.

Protéger les mots de passe en évitant le stockage en clair

Les mots de passe sont les clés de votre royaume et ne devraient jamais être stockés en clair. Même les personnes internes à une organisation ne devraient pas avoir accès à un grand dépôt non protégé de mots de passe, et cela ne devrait pas être un protocole d'entreprise accepté (il existe de nos jours de nombreux gestionnaires de mots de passe qui permettent le partage crypté des informations d'identification - pas d'excuses !) Il y a également le risque que des personnes internes malveillantes fouillent dans les fichiers et accèdent à des endroits où elles ne le devraient pas.

Et dans le cas d'une attaque extérieure, imaginez le double effet possible si une porte dérobée vers votre base de données est trouvée grâce à quelque chose d'aussi simple qu'une vulnérabilité d'injection SQL, et qu'ils accèdent également au répertoire où les mots de passe sont stockés. Vous pensez qu'il s'agit là d'un trop grand nombre d'étapes truffées d'erreurs pour que cela porte ses fruits ? Malheureusement, c'est exactement ce scénario qui s'est produit lors de la faille de Sony en 2011. Plus d'un million de mots de passe de clients étaient stockés en clair, et le groupe de pirates Lulzsec a accédé à ces mots de passe et à bien d'autres encore par le biais d'une banale attaque par injection SQL.

Tous les mots de passe doivent être protégés par les défenses disponibles dans le cadre d'appui. Pour Terraform, les mots de passe ne doivent jamais être stockés dans des fichiers modèles. Il est recommandé d'utiliser un stockage sécurisé comme AWS Secrets Manager ou Azure Key Vault, en fonction du fournisseur d'infrastructure.

Obliger les utilisateurs à créer des mots de passe sécurisés est une bonne idée, mais vous devez également faire votre part du travail en arrière-plan. Le fait de ne pas stocker les mots de passe en clair contribuera grandement à la protection de vos utilisateurs et de vos systèmes. Le principal danger du stockage des mots de passe en clair est la faiblesse du contrôle d'accès ; en fait, tout le monde peut les voir. Il est impératif (en particulier dans un environnement IaC où soudainement, davantage de personnes ont accès à des informations sensibles) que les mots de passe soient hachés de manière adéquate et que seules les personnes qui ont absolument besoin d'y accéder puissent le faire.

Consultez les pages du Secure Code Warrior pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients contre les ravages causés par d'autres failles de sécurité et vulnérabilités. Vous pouvez également essayer un défi IaC de démonstration sur la plateforme de formation Secure Code Warrior pour maintenir vos compétences en matière de cybersécurité à jour.


Table des matières

Voir la ressource
Vous souhaitez en savoir plus ?

Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Réservez une démonstrationTélécharger
Partager sur :
Centre de ressources

Ressources pour vous aider à démarrer

Plus d'articles
Centre de ressources

Ressources pour vous aider à démarrer

Plus d'articles