Bulut Güvenliği: AWS IAM Hataları ve Mimaride Yetki Yükseltme (Privilege Escalation)

Modern şirketlerin büyük çoğunluğu sunucu mimarilerini geleneksel On-Prem (kendi sistem odalarından) yapılardan Bulut (Cloud) teknolojilerine (AWS, Azure, GCP) çoktan geçirdi. Artık CISO ve Güvenlik ekiplerinin en büyük derdi bir switchi configure etmek değil, Bulut hizmetlerindeki devasa Identity and Access Management (IAM - Kimlik ve Erişim Yönetimi) kaosu ile mücadele etmektir.

Bir geliştiricinin (DevOps), süreci hızlandırmak adına basit bir AWS EC2 sunucusuna "Nasıl olsa kendi makinemiz" diyerek tam yetki (Wildcard *) verdiğini düşünün. Bir siber güvenlik uzmanının (veya siyah şapkalı hackerın) tek bir web zafiyetini adım adım global bir "Cloud Administrator" yetkisine nasıl ulaştırdığını bu Red Team makalemizde ele alacağız.

1. Zincirleme Reaksiyonun Başlangıcı: SSRF ve Metadata Hırsızlığı

Bulut tabanlı bir web sunucusunda (örneğin AWS EC2'de çalışan bir Node.js veya PHP web projesi) sistemin dışında hiçbir açık port bulunmuyor olabilir. Ancak uygulamanın içerisinde, bir URL'in resmini önizleme veya web hook sistemi (URL Fetcher) varsa, hacker bu sayfada bir SSRF (Server-Side Request Forgery) zafiyeti kurgular.

Bulut makinelerinin çok kritik bir özelliği vardır: Kendi kendilerini tanımak ve IAM (Cloud Rolleri) jetonlarını almak için Localhost'a benzeyen "Instance Metadata Service (IMDS)" adresi ile iletişim kurarlar.

Saldırgan URL input kutusuna şu sihirli AWS Metadata adresini yollar: http://169.254.169.254/latest/meta-data/iam/security-credentials/

Web uygulaması (EC2 sunucusu), bu isteği dışarıdaki Google.com yerine kendi içsel Metadata servisine atar ve dönen yanıtı (Response) ekranda basar. AWS sunucusu saldırgana der ki: "Benim adım WebApp-S3-Reader-Role". Hacker aynı adresi bir kademe daha ileri götürür ve o Role'e ait AccessKeyId, SecretAccessKey ve Token değerlerini plain-text (Oturum bileti) olarak ekranda görür. Geçmiş olsun! Uygulama kendi makinesini siber korsana teslim etmiştir.

2. Privilege Escalation (Yetki Yükseltme): Kısıtlı Rolü Tanrı Moduna (Admin) Çıkarmak

Çalınan rol WebApp-S3-Reader-Role sadece S3 bucket okumak için kurgulanmış olabilir. Fakat Bulut güvenliği tecrübelerimizde görüyoruz ki; geliştiriciler genelde AWS Policies yazarken üşengeçlikten "bazı ekstra" yetkileri de açık unutuyorlar. (Over-permissive policies).

Hacker çalınan tokenları kendi bilgisayarındaki AWS CLI (Terminaline) yükler: aws sts get-caller-identity (Evet, sistemdeyiz).

Pacu veya Cloudsplaining adı verilen araçlarla, çalınan bu kimliğin "başka ne yetkileri" olduğuna bakılır. Eğer geliştirici bu role yanlışlıkla (veya test amaçlı) şu politika varyasyonlarından birini bağlamışsa oyun biter:

A. iam:CreatePolicyVersion Zafiyeti

Saldırganın yetkisi kısıtlıdır, ama mevcut IAM kurallarına "yeni versiyon" yazma (Update) yetkisi varsa; anında sisteme {"Effect": "Allow", "Action": "*", "Resource": "*"} (Yani bana tüm izinleri ver) yetkisini içeren yeni bir Policy Versiyonu (v2) yükler ve bunu varsayılan politika (Set as Default) yapar. Tek bir API çağrısı ile misafir hesabı şirket bulut yöneticisine dönüşmüştür.

B. iam:PassRole Zafiyeti

Saldırganın rol yönetimi yetkisi yoktur ancak iam:PassRole (Bir başkasına rol atama) ve ec2:RunInstances (Yeni sunucu açma) yetkisi vardır. Saldırgan hemen AWS konsolundan yeni bir EC2 sunucu açar ve üzerine şirketteki var olan en yüksek rolü (AdministratorAccess profilini) bağlar. Ardından açtığı makineye bağlanıp (SSH veya UserData betiğiyle) Admin yetkisindeki token'ları kendi bilgisayarına indirerek Cloud altyapısını tamamen esir alır.

3. Bulutta Sıfır Güven (Zero-Trust) IAM Pratikleri

AWS, Azure veya GCP altyapınızı kuruyorsanız, Cloud Pentest / Mimari denetim raporlarının bir numaralı önerilerini kulak ardı etmeyin:

IMDSv2 Zorunluluğu Getirin: SSRF saldırıları AWS'in IMDSv1 versiyonunda ölümcüldür. Instance Metadata Service Version 2 (IMDSv2) sadece "Session Token" kullanan özel Header (X-aws-ec2-metadata-token) şartı getirir, böylece SSRF botları ve düz GET istekleri token çalamaz. Terraform / K8s kurgunuzda IMDSv1'i acımasızca devre dışı bırakın.
Wildcard (*) Dehşetinden Uzak Durun: IAM Policy JSON'ları yazılırken, Action: iam:* veya Resource: * gibi yapılar felaket habercisidir. S3 servisine ulaşılacaksa da sadece spesifik bir Bucket ismine ARN bazlı hedef koyun. Principle of Least Privilege uygulanmak zorundadır.
Role Sınırlarını IAM Boundaries ile Cihazlayın: Organizasyon yapınızda Permission Boundaries (İzin Sınırları) kullanın. Bir geliştirici kendi makinesine "Sadece okuma" yetkili sınır atanmışsa, kendi rolünü hackleyip Admin'e çekmeye çalışsa bile Permission Boundary kuralını geçemeyecektir.

Siber korsanlar şirketinizin Active Directory'sine sızmadan önce, genellikle Cloud üzerinde hatalı bırakılmış dışa açık bir konteynerın Metadata yetkisini sömürür. DevSecOps iş hattınızı güvence altında tutmak ve Bulut altyapınızın denetlenebilirliğini sağlamak için Kapsamlı Bulut Sızma Testlerinden (Cloud Pentest) faydalanmalısınız.