AWS sızma testlerinde ve bulut güvenliği analizlerinde ilk karşılaşılan alanlardan biri IAM (Identity and Access Management) yapılandırmalarıdır. Rhino Security Labs tarafından geliştirilen CloudGoat, bu yapılandırmalardaki güvenlik açıklarını analiz etmek için tasarlanmış bir laboratuvar ortamı sunar.
Bu yazıda, CloudGoat bünyesindeki iam_enum_basics senaryosunu ele alacağız. Amacımız, sınırlı yetkilere sahip Bob kullanıcısı ile AWS hesabı üzerinde keşif (enumeration) yapmak ve sistem mimarisine gizlenmiş 5 adet bayrağı (flag) tespit etmektir.
- Sızma Testinde Altın Kural: IAM keşiflerinde satır içi (inline) ve yönetilen (managed) politikalar mutlaka ayrı ayrı listelenmeli ve sürüm geçmişleri kontrol edilmelidir.
- Bilgi Sızıntısı (Information Leakage): Sadece okuma yetkiniz olsa bile, IAM grup yolları (paths) veya kaynak tanımları kritik veriler sızdırabilir.
- Yanal Hareket (Lateral Movement): Roller arasındaki güven ilişkileri (Trust Policies) dikkatlice analiz edilerek dikey veya yatay yetki yükseltme yolları aranmalıdır.
Senaryo Mimarisi ve Keşif Haritası
Bob kullanıcısının sahip olduğu sınırlı yetkilerle başlayıp AWS IAM bileşenlerini keşfederek 5 adet gizli bayrağa (flag) ulaşma yollarını gösteren mimari harita aşağıdaki gibidir:
Adım 1: Bob'un Kimlik Kartını Oluşturmak
AWS sızma testlerinde ilk adım yerel ortamı yapılandırmaktır. CloudGoat'un sağladığı Access Key ID ve Secret Access Key bilgilerini kullanarak yerel ortamda bob adında izole bir AWS CLI profili tanımlıyoruz.
aws configure --profile bob
Komutu çalıştırdıktan sonra AWS CLI üzerinden Access Key ve Secret Access Key bilgilerini tanımlıyoruz. Varsayılan bölge (Default region) olarak us-east-1 değerini belirliyoruz.
Adım 2: Kullanıcı Keşfi (User Enumeration)
Bulut keşif (reconnaissance) aşamasında, hedef AWS hesabında hangi aktörlerin tanımlı olduğunu bilmek saldırı yüzeyini anlamak için kritik bir adımdır. aws iam list-users komutu, yetkilerimiz dahilinde hesaptaki tüm IAM kullanıcılarını listelememizi sağlar. Kendi kullanıcımızın tam adını ve varsa diğer potansiyel hedefleri haritalandırmak için bu komutu çalıştırıyoruz:
aws iam list-users --profile bob
Komut çıktısında hesaptaki kullanıcılar listelenir. Bu senaryoda kendi kullanıcımız olan cg-bob-cgidf5o4l14u1y değerini ve ARN adresini tespit ederek not alıyoruz. Kullanıcı adının sonundaki benzersiz imza (cgidf5o4...), sonraki adımlarda sorgulayacağımız diğer kaynakları bulmamızda anahtar rol oynayacaktır.
Adım 3: Etrafta Başka Kimler Var? (Grup ve Rol Keşfi)
AWS ortamındaki diğer yapı taşlarını -yani grupları ve rolleri- tarayarak Bob'un yetki alanı dışındaki kaynakları incelemeye başlıyoruz.
aws iam list-groups --profile bob
aws iam list-roles --profile bob
Komut çıktılarında iki adet zayıf nokta ve ipucu tespit ediyoruz:
Atıf Kapsülü: IAM grup yolu (path) öznitelikleri genellikle göz ardı edilir ancak kritik mimari verileri sızdırabilir. Bu senaryoda grupların listelenmesi, doğrudan üçüncü gizli bayrağı barındıran bir grup yolu meta verisini açığa çıkarmaktadır.
- Grup Detayındaki Bayrak (Flag 3): Sistemde yer alan
cg-flag3-group-cgidf504114u1ygrubununPathözniteliğinde üçüncü bayrak değeri saklıdır:HSM_gr0up_m3mb3rsh1p_f0und.
- Rollerin Güven İlişkisi ve Etiketler (Flag 4): Listelenen
cg-flag4-role-cgidf504114u1yrolünün güven dökümanına (AssumeRolePolicyDocument) baktığımızda, bu rolü üstlenme (sts:AssumeRole) yetkisinin doğrudancg-bobkullanıcısına verildiğini görüyoruz. Normal şartlarda bu rolünTags(Etiketler) dizisi içerisine gizlenmiş olan dördüncü bayrağı elde ederiz:HSM-r0l3_trus1_f0und-FLAG.
Eğer bu laboratuvarı LocalStack, Floci veya benzeri bir lokal AWS emülatörü üzerinde çözüyorsanız, emülatörlerin IAM metadata kısıtlamalarından dolayı rolün Description (Açıklama) veya Tags (Etiketler) gibi alanları yukarıdaki ekran görüntüsünde olduğu gibi boş veya eksik gelebilir. Gerçek AWS ortamlarında bu bayrak, rolün etiketler (Tags) alanında açıkça görüntülenecektir.
Adım 4: Politikaların Derinliklerine İnmek (Inline vs. Managed)
Mevcut kullanıcının doğrudan yetkilerini incelemek amacıyla, satır içi (inline) ve yönetilen (managed) politikaları sorguluyoruz.
1. Satır İçi Politikaları (Inline Policies) Listeleme
aws iam list-user-policies --user-name cg-bob-cgidf5o4l14u1y --profile bob
Bu komut, kullanıcının üzerindeki cg-flag2-inline-policy-cgidf504114u1y satır içi politikasını listeler. Politikanın içeriği get-user-policy komutuyla okunduğunda, Sid (Statement ID) alanında ikinci bayrak elde edilir: HSM1nl1n3p0l1cyd1sc0v3r3d.
aws iam get-user-policy --user-name cg-bob-cgidf5o4l14u1y --policy-name cg-flag2-inline-policy-cgidf504114u1y --profile bob
2. Yönetilen Politikaları (Managed Policies) Listeleme
aws iam list-attached-user-policies --user-name cg-bob-cgidf5o4l14u1y --profile bob
Kullanıcıya iliştirilmiş cg-flag1-managed-policy-cgidf504114u1y adında bir yönetilen politika tespit edilir. Normal şartlarda bu politikanın detayları get-policy ile sorgulandığında, Description (Açıklama) alanında birinci bayrak elde edilir: HSM{m4n4g3d_p0l1cy_m4st3r}.
aws iam get-policy --policy-arn arn:aws:iam::000000000000:policy/cg-flag1-managed-policy-cgidf504114u1y --profile bob
Eğer bu laboratuvarı LocalStack, Floci veya benzeri bir lokal AWS emülatörü üzerinde çözüyorsanız, emülatörlerin IAM metadata kısıtlamalarından dolayı Description (Açıklama) veya Tags (Etiketler) gibi alanlar yukarıdaki ekran görüntüsünde olduğu gibi boş gelebilir. Gerçek AWS ortamlarında bu bayrak, politikanın açıklama satırında (Description alanında) açıkça görüntülenecektir.
Adım 5: Son Kale – S3 Sızıntısı
Son bayrağı tespit etmek için cg-flag1 politikasının detaylarına ve sürüm geçmişine bakılması gerekir. Politikanın v1 sürüm dökümanını sorguluyoruz:
aws iam get-policy-version --policy-arn arn:aws:iam::000000000000:policy/cg-flag1-managed-policy-cgidf504114u1y --version-id v1 --profile bob
Politikanın JSON içeriğini incelediğimizde, Statement altındaki Resource (Kaynak) alanında standart bir S3 kova (bucket) ismi yerine doğrudan beşinci bayrağın tanımlandığını görüyoruz: arn:aws:s3:::HSM{s3cr3t_js0n_str1ng}.
Politika bu S3 kaynağı üzerinde ListBucket ve GetObject yetkileri tanımlamıştır. Yani son bayrağımız, Bob kullanıcısının okuma yetkisine sahip olduğu bu S3 kovasının isminin ta kendisidir!
Sıkça Sorulan Sorular (FAQ)
CloudGoat lablarında neden tüm kaynak isimleri karmaşık harfler içeriyor?
Her kurulumda benzersiz ID'ler (örn: cgidf5o4...) üretilir. Bunun nedeni, AWS üzerinde aynı isimde küresel kaynakların çakışmasını önlemek ve izole, güvenli bir lab ortamı yaratmaktır.
IAM ReadOnly yetkisiyle sistemdeki verilere erişilebilir mi?
Doğrudan bir veritabanı içeriğini okuyamazsınız ancak bu senaryoda olduğu gibi politika açıklamaları, grup yolları veya S3 kova isimleri gibi meta verilerin arasına gizlenmiş hassas girdileri ifşa edebilirsiniz. Bulut ortamlarında bilgi sızıntısı hafife alınmamalıdır.
Bir roldeki AssumeRole yetkisi ne işe yarar?
sts:AssumeRole yetkisi, bir kullanıcının veya servisin geçici olarak o rolün haklarına bürünmesini sağlar. Sızma testlerinde bu yetki, yatay veya dikey yetki yükseltme (privilege escalation) için en çok aranan açık kapılardan biridir.
Kapanış ve Son Notlar
iam_enum_basics senaryosu, bulut güvenliğinde salt okuma ve listeleme yetkilerinin bile kritik bilgi sızıntılarına (Information Leakage) yol açabileceğini göstermektedir. Güvenlik analizlerinde ve sızma testlerinde bu yetkilerin sıkılaştırılması, saldırı yüzeyinin daraltılması açısından önem arz eder.
Kaynakça ve ek okuma
- Rhino Security Labs, "CloudGoat GitHub Repository" - Rhino Security Labs
- AWS Documentation, "Configuring the AWS CLI" -
AWS CLI - AWS Documentation, "Identity and Access Management (IAM) Best Practices" - AWS Documentation
Comments