AWS - S3 Persistence

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

• Jeśli chcesz zobaczyć swoją firmę reklamowaną w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź PLANY SUBSKRYPCYJNE!

• Zdobądź oficjalne gadżety PEASS & HackTricks

• Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT

• Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @hacktricks_live.

• Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud na GitHubie.

S3

Aby uzyskać więcej informacji, sprawdź:

pageAWS - S3, Athena & Glacier Enum

Szyfrowanie po stronie klienta KMS

Po zakończeniu procesu szyfrowania użytkownik będzie używał interfejsu API KMS do wygenerowania nowego klucza (aws kms generate-data-key) i przechowa klucz zaszyfrowany w metadanych pliku (przykład kodu w Pythonie), więc podczas deszyfrowania będzie można go ponownie zaszyfrować za pomocą KMS:

W związku z tym atakujący mógłby uzyskać ten klucz z metadanych i zdeszyfrować go za pomocą KMS (aws kms decrypt), aby uzyskać klucz użyty do zaszyfrowania informacji. W ten sposób atakujący będzie miał klucz szyfrowania, a jeśli ten klucz zostanie ponownie użyty do zaszyfrowania innych plików, będzie mógł go wykorzystać.

Korzystanie z ACL S3

Mimo że zazwyczaj ACL dla kubełków są wyłączone, atakujący z wystarczającymi uprawnieniami mógłby je nadużyć (jeśli są włączone lub jeśli atakujący może je włączyć), aby zachować dostęp do kubełka S3.