AWS - S3 Post Exploitation

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

S3

For more information check:

AWS - S3, Athena & Glacier Enum

Sensitive Information

Czasami będziesz w stanie znaleźć poufne informacje dostępne do odczytu w bucketach. Na przykład sekrety stanu terraform.

Pivoting

Different platforms could be using S3 to store sensitive assets.
For example, airflow could be storing DAGs code in there, or web pages could be directly served from S3. Attacker with write permissions could modify the code from the bucket to pivot to other platforms, or takeover accounts modifying JS files.

S3 Ransomware

W tym scenariuszu attacker creates a KMS (Key Management Service) key in their own AWS account lub w innym skompromitowanym koncie. Następnie sprawia, że ten key accessible to anyone in the world, pozwalając dowolnemu AWS user, role, or account szyfrować obiekty używając tego key. Jednakże obiekty nie mogą być odszyfrowane.

Attacker identyfikuje docelowy S3 bucket and gains write-level access do niego używając różnych metod. Może to być spowodowane złą konfiguracją bucketu, która wystawia go publicznie, lub attacker gaining access to the AWS environment itself. Attacker zazwyczaj targetuje buckety zawierające wrażliwe informacje, takie jak personally identifiable information (PII), protected health information (PHI), logi, backupy i inne.

Aby określić czy bucket może być celem ransomware, attacker sprawdza jego konfigurację. Obejmuje to weryfikację czy S3 Object Versioning jest włączony oraz czy multi-factor authentication delete (MFA delete) jest włączone. Jeśli Object Versioning nie jest włączone, attacker może kontynuować. Jeśli Object Versioning jest włączone, ale MFA delete jest wyłączone, attacker może disable Object Versioning. Jeśli zarówno Object Versioning jak i MFA delete są włączone, staje się trudniej przeprowadzić ransomware na danym bucketcie.

Używając AWS API, attacker replaces each object in the bucket with an encrypted copy using their KMS key. To skutecznie szyfruje dane w bucketcie, czyniąc je niedostępnymi bez klucza.

Aby dodatkowo wywrzeć presję, attacker planuje usunięcie KMS key użytego w ataku. Daje to targetowi 7-dniowe okno na odzyskanie danych zanim key zostanie usunięty i dane staną się trwale utracone.

Na koniec attacker może wgrać finalny plik, zwykle nazwany “ransom-note.txt”, który zawiera instrukcje dla targetu jak odzyskać pliki. Ten plik jest wgrany bez szyfrowania, prawdopodobnie aby zwrócić uwagę targetu i uświadomić mu atak ransomware.

SSE-C (Customer-Provided Key) Ransomware (Codefinger-like)

Inna odmiana polega na nadużyciu SSE-C (S3 server-side encryption with customer-provided keys). Przy SSE-C, client provides the encryption key on every request i AWS does not store the key. Oznacza to, że jeśli attacker przepisze obiekty używając their own SSE-C key, dane ofiary stają się nieczytelne chyba że ofiara jest w stanie dostarczyć ten attacker-controlled key.

  • Preconditions: Compromised AWS credentials (or any principal with the right permissions) oraz możliwość rewrite objects (np. s3:PutObject na target keys/prefixes). Często parowane z możliwością ustawienia destrukcyjnych lifecycle policies (patrz poniżej), np. s3:PutLifecycleConfiguration.
  • Attack chain:
  1. Attacker generuje losowy 256-bit key (AES-256) i go zachowuje.
  2. Attacker rewrites istniejące obiekty (te same object keys) używając nagłówków SSE-C, tak że przechowywany obiekt jest teraz zaszyfrowany attacker key.
  3. Victim nie może pobrać/odszyfrować bez dostarczenia SSE-C key (nawet jeśli IAM permissions są poprawne).
  4. Attacker może usunąć key (lub po prostu nigdy go nie udostępnić), aby uczynić dane nieodwracalnymi.

Przykład (koncepcyjny) użycia CLI:

# Upload/overwrite an object encrypted with attacker-provided SSE-C key
aws s3 cp ./file s3://<BUCKET>/<KEY> \
--sse-c AES256 \
--sse-c-key <BASE64_32_BYTES>

# Download requires providing the same key again
aws s3 cp s3://<BUCKET>/<KEY> ./file \
--sse-c AES256 \
--sse-c-key <BASE64_32_BYTES>
Adding Pressure: Lifecycle “Timer” Abuse

Aby usunąć opcje odzyskiwania (np. stare wersje), atakujący mogą połączyć przepisywanie za pomocą SSE-C z zasadami cyklu życia, które powodują wygaśnięcie obiektów i/lub usuwanie wersji niebędących aktualnymi po krótkim okresie:

  • s3:PutLifecycleConfiguration na bucket pozwala atakującemu zaplanować usunięcia bez wykonywania jawnych operacji usuwania dla każdego obiektu/wersji.
  • Jest to szczególnie dotkliwe, gdy wersjonowanie jest włączone, ponieważ może usunąć „poprzednią dobrą wersję”, która w innym przypadku umożliwiłaby odzyskanie.
Wykrywanie i środki zaradcze
  • Preferuj SSE-KMS (lub SSE-S3) zamiast SSE-C, chyba że masz silny powód operacyjny, by zezwolić na SSE-C.
  • Monitoruj/wyzwalaj alerty na żądania PutObject używające nagłówków SSE-C (CloudTrail data events dla S3).
  • Monitoruj/wyzwalaj alerty na nieoczekiwane PutBucketLifecycleConfiguration (zmiany zasad cyklu życia).
  • Monitoruj/wyzwalaj alerty na nagłe wzrosty aktywności nadpisywania (te same klucze aktualizowane szybko) oraz usuwanie delete-markerów/wersji.
  • Ogranicz uprawnienia wysokiego ryzyka: ogranicz s3:PutObject do niezbędnych prefiksów; mocno ogranicz s3:PutLifecycleConfiguration i s3:PutBucketVersioning; rozważ wymóg MFA dla wrażliwych działań administracyjnych (gdzie ma zastosowanie) i używaj oddzielnych ról administracyjnych z zatwierdzeniami.
  • Postawa odzyskiwania: korzystaj z wersjonowania, kopii zapasowych oraz niezmiennych/offline kopii (S3 replication do chronionego konta, backup vaults itp.); chroń wersje niebędące aktualnymi przed agresywnym usuwaniem i zabezpieczaj zmiany lifecycle za pomocą SCPs / guardrails.

s3:RestoreObject

Atakujący posiadający uprawnienie s3:RestoreObject może reaktywować obiekty zarchiwizowane w Glacier lub Deep Archive, czyniąc je tymczasowo dostępnymi. Umożliwia to odzyskanie i exfiltration historycznie zarchiwizowanych danych (backups, snapshots, logs, certifications, old secrets), które normalnie byłyby poza zasięgiem. Jeśli atakujący połączy to uprawnienie z uprawnieniami do odczytu (np. s3:GetObject), może uzyskać pełne kopie wrażliwych danych.

aws s3api restore-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--restore-request '{
"Days": <NUMBER_OF_DAYS>,
"GlacierJobParameters": { "Tier": "Standard" }
}'

s3:Delete*

Atakujący posiadający uprawnienie s3:Delete* może usuwać obiekty, wersje i całe buckety, zakłócać kopie zapasowe oraz powodować natychmiastową i nieodwracalną utratę danych, zniszczenie dowodów i kompromitację artefaktów kopii zapasowych lub procesów odzyskiwania.

# Delete an object from a bucket
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY>

# Delete a specific version
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--version-id <VERSION_ID>

# Delete a bucket
aws s3api delete-bucket \
--bucket <BUCKET_NAME>

Więcej informacji check the original research.

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks