Série Coders Conquer Security Infrastructure as Code : Fonctionnalités de sécurité désactivées

Les menaces en matière de cybersécurité sont aujourd'hui omniprésentes et incessantes. À mesure que nos vies se numérisent, les enjeux pour les cybercriminels augmentent : il y a trop de code à sécuriser et les données privées sont trop précieuses. De plus, essayer de suivre et de défendre chaque aspect de la surface d'attaque après le déploiement des programmes est devenu presque impossible.

Il existe des approches permettant d'atténuer certains de ces problèmes, et l'une d'elles devient évidente lorsque les organisations avisées adoptent le concept d'Infrastructure as Code (IaC). Bien entendu, comme pour tout développement, il existe des pièges de sécurité à éviter. Et puisque les développeurs travaillent sur le code qui génère l'infrastructure vitale hébergeant les applications, la sensibilisation à la sécurité est cruciale à chaque étape du processus.

Alors, comment un développeur débutant dans un environnement de serveur cloud peut-il monter en compétences, apprendre les ficelles du métier et aborder la construction avec une conscience accrue de la sécurité ? Nous avons créé la nouvelle série Coders Conquer Security pour aborder les vulnérabilités courantes de l'IaC, et les prochains articles de blog se concentreront sur les mesures que vous, en tant que développeur, pouvez prendre pour commencer à déployer une infrastructure sécurisée en tant que code au sein de votre propre organisation.

Commençons.

Il existe une fable du Far West américain au sujet d'un homme paranoïaque qui craignait que des bandits n'attaquent et ne pillent sa ferme. Pour se protéger, il a investi dans toutes sortes de mesures de sécurité : installation d'une porte d'entrée ultra-résistante, condamnation de toutes les fenêtres et stockage d'armes à portée de main. Pourtant, il fut cambriolé une nuit pendant son sommeil parce qu'il avait oublié de verrouiller la porte latérale. Les bandits ont simplement trouvé la faille dans sa sécurité et ont rapidement exploité la situation.

Désactiver des fonctionnalités de sécurité dans votre infrastructure revient exactement au même. Même si votre réseau dispose d'une infrastructure de sécurité robuste, elle ne sert pas à grand-chose si certains éléments ont été désactivés.

Laissez-moi vous lancer un défi avant de commencer :

Visitez le lien ci-dessus pour accéder à notre plateforme de formation ludique, où vous pourrez tenter de neutraliser une vulnérabilité liée à une fonctionnalité de sécurité désactivée dès maintenant. (Remarque : cela s'ouvrira sur Kubernetes, mais vous pouvez utiliser le menu déroulant pour choisir entre Docker, CloudFormation, Terraform et Ansible).

Comment vous en êtes-vous sorti ? S'il vous reste encore du travail, poursuivez votre lecture :

Les fonctions de sécurité peuvent être désactivées pour diverses raisons. Pour certaines applications et certains frameworks, elles peuvent être désactivées par défaut et doivent être activées pour fonctionner. Il est également possible que des administrateurs désactivent des fonctions de sécurité spécifiques afin d'effectuer certaines tâches plus facilement sans être constamment sollicités ou bloqués (par exemple, rendre public un bucket AWS S3). Une fois leur travail terminé, ils peuvent oublier de réactiver ces fonctions. Ils peuvent aussi préférer les laisser désactivées pour faciliter leurs futures interventions.

Pourquoi les fonctionnalités de sécurité désactivées sont si dangereuses

Avoir une ou plusieurs fonctionnalités de sécurité désactivées est problématique pour plusieurs raisons. D'une part, la fonctionnalité de sécurité a été intégrée aux ressources de l'infrastructure pour protéger contre une exploitation, une menace ou une vulnérabilité connue. Si elle est désactivée, elle ne pourra pas protéger vos ressources.

Les attaquants chercheront toujours en priorité les vulnérabilités faciles à exploiter et peuvent même utiliser des scripts pour passer en revue les faiblesses courantes. C'est un peu comme un voleur qui vérifierait toutes les voitures dans une rue pour voir si une portière est déverrouillée, ce qui est bien plus simple que de briser une vitre. Les pirates pourraient être surpris de constater qu'une défense de sécurité courante est inactive. Mais lorsque cela arrive, ils ne tardent pas à l'exploiter.

Deuxièmement, mettre en place une bonne sécurité pour ensuite la désactiver crée un faux sentiment de sécurité. Les administrateurs peuvent penser qu'ils sont protégés contre les menaces courantes s'ils ignorent que quelqu'un a désactivé ces défenses.

Pour illustrer comment un attaquant pourrait tirer parti d'une fonctionnalité de sécurité désactivée, prenons l'exemple de la fonctionnalité « Bloquer l'accès public » d'AWS S3. Avec cette option, les administrateurs de compte et les propriétaires de buckets peuvent facilement mettre en place des contrôles centralisés pour limiter l'accès public à leurs ressources Amazon S3. Cependant, certains administrateurs rencontrant des problèmes d'accès au bucket S3 décident de le rendre public pour accomplir leur tâche au plus vite. S'ils oublient de réactiver cette fonctionnalité de sécurité, un attaquant aura un accès complet aux informations stockées dans ce bucket S3, provoquant non seulement une divulgation d'informations, mais entraînant également des coûts supplémentaires liés aux frais de transfert de données.

Comparons du code réel ; jetez un œil à ces extraits CloudFormation :

Vulnérable :

CorporateBucket:
   Type: AWS::S3::Bucket
   Properties:
     PublicAccessBlockConfiguration:
       BlockPublicAcls: false
       BlockPublicPolicy: false
       IgnorePublicAcls: false
       RestrictPublicBuckets: false
     VersioningConfiguration:
       Status: Enabled
     BucketEncryption:
       ServerSideEncryptionConfiguration:
         - ServerSideEncryptionByDefault:
             SSEAlgorithm: "AES256"

Sécurisé :

CorporateBucket:
   Type: AWS::S3::Bucket
   Properties:
     PublicAccessBlockConfiguration:
       BlockPublicAcls: true
       BlockPublicPolicy: true
       IgnorePublicAcls: true
       RestrictPublicBuckets: true
     VersioningConfiguration:
       Status: Enabled
     BucketEncryption:
       ServerSideEncryptionConfiguration:
         - ServerSideEncryptionByDefault:
             SSEAlgorithm: "AES256"

Prévenir la désactivation des fonctionnalités de sécurité

Empêcher la désactivation des fonctionnalités de sécurité de nuire à votre organisation relève autant de la politique que de la pratique. Une politique stricte doit être en place, stipulant que ces fonctionnalités ne peuvent être désactivées que dans des circonstances très précises. Les cas où elles doivent être temporairement désactivées pour résoudre un problème ou mettre à jour des applications doivent être consignés. Une fois le travail terminé, il faut vérifier que les fonctionnalités ont été entièrement réactivées.

Si une fonction de sécurité doit être désactivée de manière permanente pour rationaliser les opérations, d'autres protections doivent être mises en place pour garantir que les pirates ne puissent pas accéder aux données en l'absence de la protection par défaut. Si une fonctionnalité de protection nécessaire est désactivée, ce n'est qu'une question de temps avant qu'un attaquant ne trouve cette porte ouverte et n'exploite la situation.

Pour aller plus loin et vous tester :

Consultez les pages du blog de Secure Code Warrior pour obtenir plus d'informations sur cette vulnérabilité et savoir comment protéger votre organisation et vos clients contre les ravages d'autres failles et vulnérabilités de sécurité.

Prêt à identifier et corriger cette vulnérabilité après avoir lu cet article ? Il est temps de relever un défi de sécurité IaC ludique sur la plateforme Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.

Cette série hebdomadaire couvre nos huit principales vulnérabilités liées à l'Infrastructure as Code ; revenez la semaine prochaine pour la suite !