AWS - S3 Post Exploitation

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

S3

For more information check:

AWS - S3, Athena & Glacier Enum

Чутлива інформація

Іноді можна знайти чутливу інформацію, доступну для читання в бакетах. Наприклад, секрети стану terraform.

Pivoting

Різні платформи можуть використовувати S3 для зберігання чутливих активів.
Наприклад, airflow може зберігати там DAGs code, або веб-сторінки можуть безпосередньо обслуговуватись із S3. Зловмисник з правами запису може modify the code у бакеті, щоб pivot на інші платформи, або takeover accounts, модифікуючи JS-файли.

S3 Ransomware

У цьому сценарії, attacker creates a KMS (Key Management Service) key in their own AWS account або в іншому скомпрометованому акаунті. Потім вони роблять цей key accessible to anyone in the world, дозволяючи будь-якому користувачу, ролі або акаунту AWS шифрувати об’єкти за допомогою цього ключа. Проте об’єкти не можуть бути розшифровані.

Attacker визначає цільовий S3 bucket and gains write-level access до нього різними шляхами. Це може бути наслідком поганої конфігурації бакету, яка робить його публічним, або же attacker отримує доступ до самого AWS середовища. Attacker зазвичай націлюється на бакети, що містять чутливу інформацію, таку як personally identifiable information (PII), protected health information (PHI), логи, резервні копії тощо.

Щоб визначити, чи можна націлити бакет для ransomware, attacker перевіряє його конфігурацію. Це включає перевірку, чи увімкнено S3 Object Versioning та чи увімкнено multi-factor authentication delete (MFA delete) is enabled. Якщо Object Versioning не увімкнено, attacker може продовжити. Якщо Object Versioning увімкнено, але MFA delete вимкнено, attacker може disable Object Versioning. Якщо і Object Versioning, і MFA delete увімкнені, attacker важче провести ransomware для конкретного бакету.

Використовуючи AWS API, attacker replaces each object in the bucket with an encrypted copy using their KMS key. Це фактично шифрує дані в бакеті, роблячи їх недоступними без ключа.

Щоб додати додаткового тиску, attacker планує видалення KMS ключа, використаного в атаці. Це дає цілі 7-денне вікно для відновлення даних до того, як ключ буде видалено і дані стануть назавжди втраченими.

Нарешті, attacker може завантажити фінальний файл, зазвичай з іменем “ransom-note.txt”, який містить інструкції для цілі про те, як повернути свої файли. Цей файл завантажується без шифрування, ймовірно, щоб привернути увагу цілі і повідомити про атаку ransomware.

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

Інший варіант — зловживання SSE-C (S3 server-side encryption with customer-provided keys). З SSE-C client provides the encryption key on every request і AWS does not store the key. Це означає, що якщо attacker перезаписує об’єкти, використовуючи their own SSE-C key, дані жертви стають нечитабельними, якщо жертва не може надати цей ключ, контрольований attacker.

  • Preconditions: Скомпрометовані AWS credentials (або будь-який principal з відповідними правами) та можливість rewrite objects (наприклад, s3:PutObject на цільових ключах/префіксах). Це часто поєднується з можливістю встановити руйнівні lifecycle policies (див. нижче), наприклад s3:PutLifecycleConfiguration.
  • Attack chain:
  1. Attacker генерує випадковий 256-бітний ключ (AES-256) і зберігає його.
  2. Attacker rewrites існуючі об’єкти (з тими ж ключами об’єктів) використовуючи SSE-C headers, так що збережений об’єкт тепер зашифрований attacker key.
  3. Victim не може завантажити/розшифрувати без надання SSE-C key (навіть якщо IAM permissions в порядку).
  4. Attacker може видалити ключ (або просто ніколи його не надати), щоб зробити дані невідновними.

Example (conceptual) CLI usage:

# 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>
Додавання тиску: зловживання “таймером” життєвого циклу

Щоб усунути варіанти відновлення (наприклад, старі версії), нападники можуть поєднати перезаписи SSE-C з правилами життєвого циклу, які завершують термін дії об’єктів і/або видаляють noncurrent versions після короткого періоду:

  • s3:PutLifecycleConfiguration на bucket дозволяє атакувальнику запланувати видалення без виконання явних операцій delete для кожного object/version.
  • Це особливо ефективно, коли versioning is enabled, оскільки це може видалити “previous good version”, яка в іншому випадку дозволила б відновлення.
Detection & Mitigations
  • Віддавайте перевагу SSE-KMS (або SSE-S3) над SSE-C, якщо у вас немає вагомої операційної причини дозволяти SSE-C.
  • Моніторити/сповіщати про запити PutObject, що використовують заголовки SSE-C (CloudTrail data events for S3).
  • Моніторити/сповіщати про неочікувані PutBucketLifecycleConfiguration (зміни lifecycle).
  • Моніторити/сповіщати про раптові сплески активності перезапису (одні й ті самі keys оновлюються швидко) та видалення delete-marker/version.
  • Обмежуйте ризикові дозволи: лімітуйте s3:PutObject до необхідних префіксів; суворо обмежуйте s3:PutLifecycleConfiguration та s3:PutBucketVersioning; розгляньте вимогу MFA для чутливих адміністраторських дій (за потреби) та використовуйте окремі admin roles з погодженнями.
  • Постава відновлення: використовуйте versioning, backups та незмінні/офлайн копії (S3 replication to protected account, backup vaults тощо); захищайте noncurrent versions від агресивного видалення та контролюйте зміни lifecycle за допомогою SCPs / guardrails.

s3:RestoreObject

Атакувальник з дозволом s3:RestoreObject може реанімувати об’єкти, заархівовані в Glacier або Deep Archive, роблячи їх тимчасово доступними. Це дозволяє відновлення та exfiltration історично архівованих даних (резервні копії, snapshots, логи, сертифікати, старі секрети), які зазвичай були б недоступні. Якщо атакувальник поєднає цей дозвіл з дозволами на читання (наприклад, s3:GetObject), він зможе отримати повні копії конфіденційних даних.

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

s3:Delete*

Атакувальник із дозволом s3:Delete* може видаляти об’єкти, версії та цілі бакети, порушувати резервні копії та спричиняти миттєву й незворотну втрату даних, знищення доказів і компрометацію артефактів резервного копіювання або відновлення.

# 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>

Детальніше check the original research.

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks