Devam eden S3 veri sızdırmasını durdurmak için IAM role oturumlarını iptal etmek: adım adım

Senaryo

dev.to'da yayınlanan bir rehber, bulut güvenlik ekiplerinin prova ettiği ama nadiren hazır bir script bulabildiği bir durumu ele alıyor: hassas veri içeren bir bucket üzerinde s3:GetObject yetkisi veren bir IAM role ile çalışan bir EC2 instance'ı ele geçiriliyor. Saldırgan, instance metadata servisinden geçici credentials'ları topluyor ve nesneleri toplu olarak indirmeye başlıyor. Amazon GuardDuty bir Exfiltration:S3/AnomalousBehavior bulgusu yükseltiyor, ancak geliştirme ekibinin bir patch yayınlaması dört saat sürecek. Yazının hedefi, hırsızlığı komutlar, doğrulama adımları ve her kararın arkasındaki gerekçelerle birlikte derhal kesmek.

Bulgudan role adına

İlk görev, GuardDuty bulgusundaki instance kimliğini, çağrıları asıl yapan IAM principal'ına çevirmek. Yazı, instance profile ARN'sini sorgulamak için aws ec2 describe-instances komutunu kullanıyor, ardından bu profile'ı aws iam get-instance-profile ile bir role adına çözümlüyor. Örnekte instance, ProdDataAccessRole adlı bir role altında çalışıyor ve bu role, sonrasındaki her şeyin hedefi.

Kilit hamle: role'ün aktif oturumlarını iptal etmek

Rehber, bucket'a ya da ağa dokunmak yerine, role'ün halihazırda verdiği tüm geçici credentials'ları iptal ediyor. Mekanizma, role'e eklenen ve credential'ın aws:TokenIssueTime değeri mevcut UTC zamanına ayarladığınız bir zaman damgasından önceyse tüm kaynaklardaki tüm eylemleri reddeden bir inline policy. AWS console, aynı işlemi role'ün Revoke Sessions sekmesi üzerinden sunuyor ve bu sekme eşdeğer inline policy'yi otomatik olarak ekliyor.

Yazıya göre bu işe yarıyor çünkü geçici credentials'larla imzalanan her API çağrısı token issue time değerini taşıyor ve red, her istekte herhangi bir yayılma gecikmesi olmadan değerlendiriliyor. Saldırganın on dakika önce çıkardığı credentials'lar, önbelleğe aldığı credentials'lar ve tamamen farklı bir ağdan yeniden oynattığı (replay) credentials'ların hepsi aynı anda reddediliyor.

Önce kesintiyi doğrulayın, sonra workload'u

Rehber doğrulamayı iki kontrol halinde bölüyor. Birincisi, iptalin etkili olduğunu doğrulamak: aws iam get-role-policy inline policy'yi gösteriyor ve kesim zaman damgasından sonra s3.amazonaws.com kaynaklı AccessDenied olaylarına yönelik bir CloudTrail sorgusu, saldırganın GetObject çağrılarının artık başarısız olduğunu kanıtlıyor. İkincisi, meşru trafiğin ayakta kaldığını doğrulamak: yalıtılmamış bir instance, token issue time değeri kesim noktasından sonra olan yeni credentials'ları otomatik olarak alır, dolayısıyla role'ü paylaşan sağlıklı bir instance'dan bucket'a yapılan bir test head-object çağrısı hâlâ başarılı olmalı.

Bariz alternatifler neden başarısız oluyor

Yazı, ayakta kalamayan iki sezgisel yaklaşıma önemli ölçüde yer ayırıyor:

1. Ağ yalıtımı. Instance'ı boş bir security group'a taşımak bağlantısını keser ama makineden zaten kopyalanmış credentials'lar için hiçbir şey yapmaz. Yazının açıkladığına göre saldırganın standart hamlesi, access key ID'yi, secret key'i ve session token'ı metadata endpoint'inden okumak, bunları başka herhangi bir makinede export etmek ve orijinal instance ile ilgisiz bir kaynak IP'den toplu bir sync çalıştırmaktır.
2. Herkese s3:GetObject'yi reddeden bir bucket policy. Bu saldırganı durdurur — ve aynı veriyi okuyan uygulama sunucularını, backup işlerini ve analytics pipeline'larını da. Aktif okuma trafiği varken, bu, onarım penceresi boyunca bucket'ın her tüketicisi için bir kesinti anlamına gelir.

Buna karşılık oturum iptali cerrahi bir işlem: tam olarak kesim noktasından önce verilmiş credentials'ları geçersiz kılar ve çalışan diğer tüm principal'ları olduğu gibi bırakır.

Akılda tutulması gereken ödünleşimler

Rehber üç uyarıya dikkat çekiyor:

• İptal, bir remediation değildir. Role çalışmaya devam eder ve instance'ı hâlâ kontrol eden bir saldırgan, zaman damgası kontrolünden geçen yeni credentials'lar edinebilir. Önerilen sıra, önce iptal etmektir — ele geçmiş credentials'ları öldürerek — ardından yeni credentials'ların verilmesini önlemek için instance'ı durdurmak veya karantinaya almaktır. Ters sıra, çalınmış credentials'ları kullanılabilir bırakır.
• Sadece süre dolması çok yavaştır. Instance profile credentials'ları kendi kendine expires olur — yazı en fazla altı saatten söz ediyor, varsayılan ise bir saat — ancak hassas verilerin aktif olarak sızdırıldığı bir süreçte saatin dolmasını beklemek uygulanabilir değildir.
• Sonrasında temizlik yapın. Düzeltme dağıtıldıktan sonra inline deny policy, aws iam delete-role-policy ile kaldırılmalıdır; yazı, bunu ekli bırakmanın önbelleğe alınmış credentials'lar tutan süreçleri etkileyebileceği konusunda uyarıyor.

Neden önemli

Bulut saldırılarında önemli varlık, ele geçirilen makine değil, çalınan credential'dır. Bir instance'dan taşınan geçici IAM credentials'ları ağ düzeyindeki kapsamayı tamamen etkisiz kılar ve bucket geneline yayılan kaba reddeler bir güvenlik olayını üretim kesintisine dönüştürür. Bu rehberin değeri, GuardDuty bulgusu biçimindeki tespiti, saldırının gerçek mekanikleriyle eşleşen bir müdahaleyle eşleştirmesindedir: çalınanı geçersiz kılmak için oturumları iptal edin, yeniden verilmesini durdurmak için instance'ı yalıtın, ardından her iki sonucu da CloudTrail ve fonksiyonel bir testle doğrulayın. Bu sıralama neredeyse her AWS hesabına taşınabilir ve gerçek bir bulgunun dört saatlik bir telaşa yol açmasından önce provası yapmaya değer bir playboook türüdür.