Bienvenue sur notre blog.

Prévenir la prise de contrôle totale du nuage par des attaques SSRF

Voici l'histoire d'un attaquant qui a eu accès aux buckets Amazon S3 d'une startup, à des variables d'environnement et à divers secrets d'API internes, le tout par le biais d'un simple formulaire qui envoie un courrier électronique. Bien qu'il s'agisse d'une histoire vraie, je garde le nom de la startup secret.

Comment ils sont entrés

Tout commence par une application PHP qui envoie un courrier électronique. Pour charger certaines images fantaisistes en pièces jointes, l'application doit les télécharger. En PHP, c'est facile. Vous utilisez la fonction file_get_contents et c'est là que tout commence.

Bien entendu, certaines des données saisies par les utilisateurs pour ce courrier électronique n'ont pas été entièrement vérifiées ou codées en HTML, et un utilisateur a donc pu inclure une image telle que <img src=’evil.com’/>. En théorie, ce n'est pas si mal, mais malheureusement, cette fonction PHP est très puissante et peut faire bien plus que charger des images sur Internet. Elle peut également lire des fichiers locaux et, plus important encore, des fichiers sur le réseau local au lieu d'Internet.

Au lieu de evil.com, l'attaquant a saisi une URL locale spéciale. Vous pouvez utiliser cette URL pour obtenir les informations d'identification IAM liées au rôle du serveur AWS EC2 que vous exécutez à l'aide d'une simple requête GET.

<img src=’http://169.254.169.254/latest/meta-data/'>

Le résultat est que l'attaquant a reçu un courriel contenant les identifiants IAM du serveur EC2 dans une pièce jointe de la boîte aux lettres. Ces clés permettent à l'attaquant d'usurper l'identité de ce serveur lorsqu'il communique avec divers services AWS. À partir de là, tout s'écroule...

Pourquoi cela est-il possible ?

Le système qui charge ces clés IAM est appelé IMDSv1 et Amazon a publié une nouvelle version en 2019 appelée IMDSv2. Avec IMDSv2, vous devez envoyer une requête PUT avec un en-tête spécial pour obtenir vos informations d'identification IAM. Cela signifie qu'une simple fonction de chargement d'URL basée sur GET comme file_get_contents ne peut plus causer autant de dégâts.

On ne sait pas exactement quel sera le taux d'adoption d'IMDSv2 en 2023, mais il est clair qu'Amazon prend toujours des mesures pour augmenter son adoption et que nous voyons IMDSv1 encore utilisé dans la nature.

La compromission des clés IAM entraîne d'autres compromissions : Les buckets S3 ont pu être listés et leur contenu lu. Pour aggraver les choses, l'un des buckets S3 contenait un modèle de formation de nuages, qui contenait des variables d'environnement sensibles (par exemple les clés API de Sendgrid).

Comment défendre mon infrastructure en nuage contre ce phénomène ?

Que peut-on faire pour éviter cette perte totale de données ? Vos développeurs pourraient être très prudents et veiller à utiliser une liste d'autorisations pour les URL qu'ils transmettent à file_get_contents. Ils pourraient même vérifier que le contenu qu'ils reçoivent est une image s'ils s'attendent à une image. En réalité, il est difficile d'éviter ce genre d'erreurs en tant que développeur.

Il serait préférable de s'assurer que votre infrastructure dispose de défenses supplémentaires contre ces attaques. Notre nouvelle intégration avec AWS au sein d'Aikido Security vous alertera si votre cloud ne prend pas activement l'une des mesures suivantes. Chacune de ces mesures aurait permis d'arrêter cette attaque, mais nous recommandons de toutes les mettre en œuvre. Utilisez notre compte d'essai gratuit pour voir si votre cloud est déjà défendu contre ces menaces. Découvrez comment Aikdido protège votre application contre les vulnérabilités ici.

Mesures à prendre :

1. Migrer vos nœuds EC2 IMDSv1 existants pour utiliser IMDSv2
2. Ne stockez aucun secret dans l'environnement de vos serveurs web ou dans les modèles de formation de nuages. Utilisez un outil tel que AWS Secrets Manager pour charger les secrets au moment de l'exécution.
3. Lorsque vous attribuez des rôles IAM à vos serveurs EC2, veillez à ce qu'ils soient assortis de conditions supplémentaires, telles que la restriction de leur utilisation à l'intérieur de votre réseau AWS local (votre VPC). L'exemple ci-dessous permet à votre serveur de lire dans S3, mais uniquement si le serveur EC2 communique via un point d'extrémité VPC spécifique. Cela n'est possible qu'à partir de votre réseau, de sorte que l'attaquant n'aurait pas été en mesure d'accéder aux fichiers S3 depuis son ordinateur local.

{
"Version": "2012-10-17",
"Statement": [
       {
"Sid": "rule-example",
"Effect": "Allow",
"Action": "s3:getObject",
"Resource": "arn:aws:s3:::bucketname/*",
"Condition": {
"StringEquals": {
"aws:SourceVpce": "vpce-1s0d54f8e1f5e4fe"
               }
           }
       }
   ]
}

À propos de "The Kill Chain" (La chaîne de la mort)

The Kill Chain est une série d'histoires réelles d'attaquants atteignant les joyaux de la couronne d'entreprises de logiciels en enchaînant de multiples vulnérabilités. Rédigée par Willem Delbare, elle s'appuie sur ses dix années d'expérience dans la création et le soutien de startups SaaS en tant que directeur technique. Les récits proviennent directement du réseau de Willem et se sont réellement produits.

La startup belge SaaS Aikido Security a levé 2 millions d'euros en financement de pré-amorçage auprès d'investisseurs providentiels renommés qui soutiennent sa mission de simplifier la sécurité des logiciels pour les développeurs.

Ces dernières années, l'industrie du logiciel s'est orientée vers le développement "shift left", ce qui a eu pour effet d'accroître la responsabilité des développeurs en matière de sécurité. Malheureusement, les plateformes actuelles de sécurité logicielle sont difficiles à utiliser pour les développeurs, ce qui leur fait perdre beaucoup de temps. Aikido Security a été fondé pour relever ce défi.

Le tour de pré-amorçage a la chance de pouvoir compter sur le soutien d'un éventail d'investisseurs (anges) qualifiés. Syndicate One, Pieterjan Bouten (Showpad), Louis Jonckheere (Showpad), Christophe Morbee (Besox), Mathias Geeroms (OTA Insight) ont tous décidé de participer. Aikido Security a la chance de pouvoir compter sur leur soutien et leur expertise.

"Les outils de sécurité des logiciels ont rendu ma vie de directeur technique plus difficile".

explique Willem Delbare, fondateur et directeur technique d'Aikido Security. "J'en ai testé un grand nombre et ils souffrent tous des mêmes problèmes. Ils vous surchargent de faux positifs, vous inondent de notifications et rendent le triage difficile. J'ai trouvé cela très épuisant. Nous avons décidé d'y remédier.

L'équipe est composée d'entrepreneurs expérimentés qui ont construit des produits à succès dans diverses industries avant de se réunir au sein d'Aikido Security. L'équipe fondatrice est composée de Willem Delbare (Teamleader, Officient), Roeland Delrue (Showpad, Officient), Amber Rucker (Veriff, Cloudbees) & Felix Garriau (nexxworks, AREA42).

Aikido a récemment achevé la version alpha de son produit, qu'elle teste activement auprès des premiers utilisateurs. Le financement permet à la société d'agrandir son équipe et de compléter les fonctionnalités du produit, tout en développant sa base de clients.

A propos d'Aikido Security

Aikido Security est une plateforme de sécurité logicielle qui s'adresse d'abord aux développeurs. Nous analysons votre code source et votre cloud pour vous montrer quelles vulnérabilités sont réellement importantes à résoudre. Le triage est accéléré en réduisant massivement les faux positifs et en rendant les CVE lisibles par l'homme. Aikido simplifie la sécurisation de vos produits et vous redonne du temps pour faire ce que vous faites le mieux : écrire du code.

Les Lockfiles jouent un rôle essentiel dans la sécurisation de la chaîne d'approvisionnement des logiciels grâce à une gestion cohérente des dépendances. Ils spécifient les versions exactes des dépendances utilisées, garantissant ainsi la reproductibilité et évitant les changements inattendus.

Dans un environnement de développement rapide rempli de bibliothèques open-source et de paquets tiers, les lockfiles constituent une défense contre les attaques de la chaîne d'approvisionnement. En verrouillant les dépendances sur des versions spécifiques, ils empêchent les mises à jour automatiques vers des versions potentiellement compromises.

De nombreuses équipes de développement négligent les fichiers de verrouillage et ne parviennent pas à en exploiter tout le potentiel. Cet article souligne l'importance des fichiers de verrouillage pour garantir l'intégrité et la sécurité des projets logiciels.

Comprendre les Lockfiles

Les Lockfiles sont des fichiers qui capturent les versions exactes de chaque dépendance et de leurs sous-dépendances dans un projet. Ils garantissent l'uniformité des versions des dépendances dans toutes les instances d'un projet, évitant ainsi l'"enfer des dépendances" et les risques potentiels pour la sécurité.

Les fichiers de verrouillage sont différents pour chaque langue et peuvent varier en fonction des cadres, mais suivent généralement des formats similaires.

Javascript - yarn.lock

lodash@^4.17.15:
  version "4.17.21"
 résolu "https://registry.yarnpkg.com/lodash/-/lodash-4.17.21.tgz#acfcd7438b5d260f06a1d052c2a3b32ddc91c6b8"
 intégrité sha512-v2kDE6syb5rK+X8bykjh3W7n4P3NV8axFypa8DwO8DK+RVZk9vft6xEhjxzIlc6DCwCPkMKSk4eQF6QNHOu9pw==.

react@^17.0.1:
  version "17.0.2"
 résolu "https://registry.yarnpkg.com/react/-/react-17.0.2.tgz#cdc8d94b0d7091f440c51d1427ff2a3d6e14e664"
 intégrité sha512-y8vQ43+qMOpbD/3k1Vw4E4i4UgFqxMwI0AZc5fxyIfZK4kHRZ5Klg5zh/5Nq1Nk3JZqf6byFAkyoGZkbSnYt9w==.

Python - poetry.lock

[[package]]
name = "requests"
version = "2.25.1"
description = "Python HTTP for Humans."
category = "main"
optional = false
python-versions = ">=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*, <4"

[package.dependencies]
certifi = ">=2017.4.17"
chardet = ">=3.0.2,<5"
idna = ">=2.5,<3"
urllib3 = ">=1.21.1,<1.27"

Cette entrée précise le nom du paquet (click), les hachages acceptés et la version exacte (8.0.3). Cette spécificité garantit la cohérence des installations dans les environnements de développement, de test et de production.

Les gestionnaires de paquets génèrent des fichiers de verrouillage (lockfiles) lors de l'installation de dépendances ou de mises à jour. Il est essentiel de livrer ces fichiers au contrôle de version avec le code source du projet. Cette pratique permet de s'assurer que tous les contributeurs du projet utilisent des dépendances identiques, ce qui réduit les incohérences et rend les constructions plus prévisibles.

Les différents langages et gestionnaires de paquets ont leurs propres formats de fichiers de verrouillage : Node.js utilise package-lock.json pour npm, Python utilise Pipfile.lock pour Pipenv, et Ruby utilise Gemfile.lock pour Bundler. L'utilisation de lockfiles permet de maintenir une base de projet cohérente et sécurisée, réduisant ainsi les risques associés à la gestion des dépendances.

Se défendre contre les attaques de la chaîne d'approvisionnement

Les attaques de la chaîne d'approvisionnement sur les dépendances des logiciels libres sont de plus en plus fréquentes. Les attaquants peuvent compromettre une bibliothèque populaire, injecter un code malveillant qui se propage dans les projets dépendants. Les Lockfiles constituent une défense solide contre ces attaques.

En spécifiant les versions exactes des dépendances, les lockfiles empêchent les mises à jour automatiques vers des versions potentiellement compromises. Cet aspect est crucial lorsque des vulnérabilités sont identifiées dans les dépendances. Grâce aux lockfiles, les projets restent stables avec des versions sûres connues jusqu'à ce que l'équipe décide de les mettre à jour après des tests approfondis.

Vous trouverez ci-dessous un exemple de package-lock.json utilisé dans les projets Node.js pour verrouiller des versions spécifiques de dépendances. Cela permet de s'assurer que toutes les personnes travaillant sur le projet installent exactement les mêmes versions, ce qui favorise la cohérence et la sécurité.

{
  "name": "my-project",
  "version": "1.0.0",
  "lockfileVersion": 2,
  "requires": true,
  "packages": {
    "": {
      "name": "my-project",
      "version": "1.0.0",
      "dependencies": {
        "lodash": "4.17.21",
        "axios": "0.21.1"
      }
    },
    "node_modules/lodash": {
      "version": "4.17.21",
      "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "integrity": "sha512-v2kDE6syb5rK+X8bykjh3W7n4P3NV8axFypa8DwO8DK+RVZk9vft6xEhjxzIlc6DCwCPkMKSk4eQF6QNHOu9pw=="
    },
    "node_modules/axios": {
      "version": "0.21.1",
      "resolved": "https://registry.npmjs.org/axios/-/axios-0.21.1.tgz",
      "integrity": "sha512-pbkHfFgC6F4ltGeoyTeHRtUkZo/FZ9EoElV3MzDLeO2uYxLqGm6Qcbx93jUOJISyYSC/tzjK4NHH3MAYsDKUTA==",
      "dependencies": {
        "follow-redirects": "^1.10.0"
      }
    },
    "node_modules/follow-redirects": {
      "version": "1.14.1",
      "resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.14.1.tgz",
      "integrity": "sha512-0gh4nEbdUdDra9mJKpAB+Y4gG61sQiKsbiqS8c5LEnFOh8fbov3/xp0FnWE2+IxKTozhJSdEV8ujvQjU+Ub3dg=="
    }
  },
  "dependencies": {
    "lodash": {
      "version": "4.17.21",
      "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "integrity": "sha512-v2kDE6syb5rK+X8bykjh3W7n4P3NV8axFypa8DwO8DK+RVZk9vft6xEhjxzIlc6DCwCPkMKSk4eQF6QNHOu9pw=="
    },
    "axios": {
      "version": "0.21.1",
      "resolved": "https://registry.npmjs.org/axios/-/axios-0.21.1.tgz",
      "integrity": "sha512-pbkHfFgC6F4ltGeoyTeHRtUkZo/FZ9EoElV3MzDLeO2uYxLqGm6Qcbx93jUOJISyYSC/tzjK4NHH3MAYsDKUTA==",
      "requires": {
        "follow-redirects": "^1.10.0"
      }
    },
    "follow-redirects": {
      "version": "1.14.1",
      "resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.14.1.tgz",
      "integrity": "sha512-0gh4nEbdUdDra9mJKpAB+Y4gG61sQiKsbiqS8c5LEnFOh8fbov3/xp0FnWE2+IxKTozhJSdEV8ujvQjU+Ub3dg=="
    }
  }
}

Ce que fait ce fichier

• Verrous Versions spécifiques:
  Il verrouille lodash à la version 4.17.21 et axios à 0.21.1. Quel que soit le moment ou l'endroit où vous installez ce projet, ces versions exactes seront utilisées, ce qui évitera les mises à jour accidentelles vers des versions susceptibles de contenir des changements radicaux ou des problèmes de sécurité.
• Capture de l'arbre de dépendance:
  Il comprend des dépendances imbriquées, comme suivre les redirectionsqui est utilisé en interne par axios.
• Prise en charge des outils de sécurité:
  Des outils comme Aikido utilisent ce fichier de verrouillage pour rechercher les vulnérabilités connues. Comme le fichier contient des URL résolues et des hachages de version, les scanners peuvent :
  • Identifier précisément les paquets à risque.
  • Recommander des correctifs ou des solutions de rechange sûres.
  • Suivre les modifications apportées aux dépendances au fil du temps.

Risques liés à l'ignorance des fichiers verrouillés

Négliger les fichiers de verrouillage peut déstabiliser et compromettre les projets logiciels. Sans fichiers de verrouillage, les versions des dépendances peuvent varier d'un environnement à l'autre, ce qui entraîne des incohérences qui compliquent le débogage. Ces variations peuvent être à l'origine de bogues insaisissables, retardant les projets et augmentant les charges de maintenance.

Sans fichier de verrouillage, le suivi des dépendances devient difficile. En l'absence d'enregistrement clair, il est difficile de déterminer quelles versions sont utilisées, ce qui complique la gestion de la chaîne d'approvisionnement. En cas de vulnérabilité, les développeurs ont du mal à identifier rapidement les dépendances à risque, ce qui retarde les délais de réaction.

Les mises à jour automatiques présentent des risques importants en l'absence de fichiers de verrouillage. Les mises à jour non contrôlées peuvent introduire des paquets compromis, exposant ainsi les projets à des failles de sécurité. Même des bibliothèques réputées peuvent receler des menaces cachées, ce qui rend la surveillance des fichiers de verrouillage cruciale pour le maintien d'une base de code sécurisée.

Bonnes pratiques pour l'utilisation des Lockfiles

Intégrez les lockfiles dans votre flux de travail de développement pour en tirer pleinement parti. L'inclusion des lockfiles dans le contrôle de version établit une source unique de vérité pour les dépendances, ce qui favorise un environnement de développement cohérent. Cette approche réduit les variations indésirables et améliore la fiabilité de la production.

La mise à jour et l'examen réguliers des fichiers de verrouillage sont essentiels à la détection précoce des menaces. Cette stratégie proactive permet aux équipes de remédier rapidement aux vulnérabilités et de maintenir un niveau de sécurité élevé. Utilisez des outils d'évaluation continue des dépendances pour automatiser la détection des risques dans la chaîne d'approvisionnement des logiciels.

L'ancrage des dépendances à des versions spécifiques dans les fichiers manifestes renforce la sécurité. Cette pratique complète les fichiers de verrouillage et sert de filet de sécurité en cas de divergences. Sensibiliser les équipes de développement à l'importance des fichiers de verrouillage renforce la gestion diligente des dépendances, améliorant ainsi la sécurité globale.

Maintenir les dépendances à jour avec les Lockfiles

Pour maintenir les dépendances à jour, il faut combiner l'automatisation et un examen approfondi. Les mises à jour régulières des fichiers de verrouillage devraient faire partie des cycles de développement, afin d'intégrer les dernières améliorations et les correctifs de sécurité tout en préservant la cohérence. Les mises à jour régulières minimisent les interruptions imprévues et renforcent la sécurité.

Des outils automatisés comme Dependabot aident à gérer les mises à jour en générant des demandes d'extraction pour les nouvelles versions de dépendances. Ces outils assurent une surveillance continue, permettant des mises à jour opportunes et permettant aux équipes de se concentrer sur d'autres tâches. Toutefois, il est essentiel d'examiner les changements pour s'assurer qu'ils répondent aux besoins du projet et éviter les problèmes.

Il est également essentiel de mettre au point un processus manuel de mise à jour du fichier de verrouillage. Déployer les dépendances mises à jour dans un environnement de test pour évaluer l'impact et la compatibilité. Cette approche permet d'éviter les perturbations et de maintenir la cohérence, en minimisant les risques liés aux changements de version fréquents.

L'intégration de lockfiles dans votre processus de développement renforce votre chaîne d'approvisionnement en logiciels contre les menaces de sécurité en constante évolution. L'adoption de bonnes pratiques et la sensibilisation de votre équipe aux dépendances sont essentielles au maintien d'une base de code robuste. Prêt à renforcer la sécurité de votre chaîne d'approvisionnement ? Commencez gratuitement avec Aikido et simplifiez votre parcours de sécurité.