⚔️ Red vs. Blue #5 — Bulut Yetki Yükseltme: AWS IAM Privilege Escalation Herkese Selamlar, Bugün ⚔️ Red vs. Blue serimizin 5. bölümünde, bulut güvenliğinin en tehlikeli ve en çok gözden kaçan konularından birine odaklanıyoruz: Masum görünen IAM izinleriyle nasıl tam yetkili (AdministratorAccess) olunur? Geleneksel sistemlerde "Admin değilsen yetkin kısıtlıdır" mantığı işler. Ancak AWS ortamlarında güvenlik, sadece rolün adına bakılarak ölçülmez. Bazen sisteme tanımlanmış "masum" iki izin yan yana geldiğinde, saldırgana tüm bulut altyapısının anahtarını altın tepside sunabilir. Gelin, bulut dünyasında en sık rastlanan privilege escalation (yetki yükseltme) senaryolarından birine Red Team ve Blue Team gözüyle bakalım. 🔴 Red Team Perspektifi: "Sadece Sunucu Açabiliyorum" Yalanı Bir saldırganın, kısıtlı yetkilere sahip bir geliştirici hesabını ele geçirdiğini düşünelim. Saldırgan politikaları incelediğinde şu iki izne sahip olduğunu görüyor: ec2:RunInstances (Yeni bir EC2 sunucusu başlatabilme) iam:PassRole (Sisteme mevcut bir IAM rolünü geçirebilme/bağlayabilme) İlk bakışta "Bu kullanıcı sadece sunucu açabilir, zararsız" gibi görünür. Ancak saldırgan kurnazca şu adımları izlerse iş çığırından çıkabilir: Saldırgan, AWS hesabında önceden tanımlanmış ve tam yetkiye sahip (AdministratorAccess) bir EC2 rolü olup olmadığını tarar. Ardından Yeni bir EC2 sunucusu başlatır ve iam:PassRole yetkisini kullanarak bu yeni sunucuya o Admin rolünü atar. Sunucu açıldıktan sonra EC2 içerisine sızar ve AWS IMDS (Instance Metadata Service) üzerinden o Admin rolüne ait geçici erişim anahtarlarını (Access Key & Secret Key) çeker. Tebrikler! Saldırgan artık tüm AWS hesabının yöneticisidir. 🔵 Blue Team Perspektifi: Peki ya Nasıl Önleriz ve Tespit Ederiz? Bu tür yetki yükseltme tuzaklarına düşmemek için Blue Team tarafında atılması gereken kritik adımlar şunlardır: Least Privilege & Wildcard Yasağı: iam:PassRole yetkisi verilirken asla Resource: "*" kullanılmamalıdır. Kullanıcının sadece belirli ve kısıtlı rolleri sunuculara bağlamasına izin verilmelidir. IMDSv2 Zorunluluğu: EC2 Metadata servislerinde IMDSv1 yerine mutlaka token tabanlı IMDSv2 zorunlu tutulmalı, yetkisiz metadata okumaları zorlaştırılmalıdır. CloudTrail & GuardDuty Alarm: Bir kullanıcının yüksek yetkili bir IAM rolünü EC2 gibi bir servise bağlaması veya alışılmadık bir IP'den bu rolün geçici kimlik bilgileriyle işlem yapılması durumunda anlık alarm mekanizmaları kurgulanmalıdır. 📌 Siber Güvenlik Dersi: Bulut güvenliğinde en büyük zafiyet açıkça verilen Admin yetkisi değil, farkında olunmadan yan yana getirilen ve birleştiğinde ölümcül bir arka kapıya dönüşen kısıtlı yetki kombinasyonlarıdır. "Bulutta güvenlik rollerin isimleriyle değil, izinleriyle ölçülür" 💬 Mustafa soruyor: AWS veya Azure ortamlarınızda IAM politikalarını denetlerken otomatik analiz araçları (PMapper, ScoutSuite vb.) mı kullanıyorsunuz, yoksa kuralları manuel mi inceliyorsunuz? Bulutta karşılaştığınız en şaşırtıcı yetki zafiyeti neydi? Yorumlarda buluşalım!