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.

Saha Kontrol Notları

DevSecOps güvenliği, pipeline’a araç eklemekten daha fazlasıdır. Asıl hedef, riskli değişikliğin production’a taşınmadan görünür ve durdurulabilir hale gelmesidir.

İnceleme sırasında şu kanıtlar toplanmalıdır:

CI/CD token’ları hangi kaynaklara erişiyor?
Secret bulunduğunda otomatik revoke veya rotate akışı var mı?
Branch protection ve environment approval açık mı?
Build artefact’ları imzalanıyor mu?
Container image kaynakları doğrulanıyor mu?
Dependency güncellemeleri güven politikasıyla yönetiliyor mu?
Pipeline loglarında hassas veri tutuluyor mu?
Deploy kimliği kişisel hesaplardan ayrılmış mı?
Incident halinde hangi secret’ın kullanıldığı görülebiliyor mu?
Retest için pipeline kanıtı üretilebiliyor mu?

Uygulama Kontrol Listesi

Uzun ömürlü token’lar azaltılmalı.
Secret scanning rotasyon akışıyla bağlanmalı.
İmzasız artefact production’a alınmamalı.
Kritik branch’lerde review ve status check zorunlu olmalı.
Pipeline yetkileri ortam bazında ayrılmalı.
Olay müdahalesi kod temizliğiyle sınırlı bırakılmamalı.

Karar Noktası

Secret veya CI/CD token production erişimi sağlayabiliyorsa olay acildir. Eresus Security pipeline, token ve artefact zincirini birlikte inceleyerek gerçek etki alanını çıkarır.

Operasyonel İnceleme Checklisti

Secret bulunduğunda revoke ve rotate akışı var mı?
CI/CD token kapsamı minimum yetkide mi?
Branch protection zorunlu mu?
Environment approval kritik deploylarda açık mı?
Artefact imzası doğrulanıyor mu?
Pipeline logları secret sızdırıyor mu?
Dependency güveni build aşamasında kontrol ediliyor mu?
Container registry erişimi sınırlı mı?
Git history temizliği olay müdahaleden ayrıldı mı?
Token kullanım kanıtı loglardan çıkarılabiliyor mu?
Kapsam net yazıldı mı?
Etkilenen varlık sahibi belli mi?
Test ortamı production etkisinden ayrıldı mı?
Kullanıcı rolleri doğru temsil ediliyor mu?
Hassas veri sınıfı tanımlandı mı?
Yetki sınırı teknik olarak doğrulandı mı?
Log kaynağı ve saklama süresi belli mi?
Bulgu tekrar üretilebilir kanıtla destekleniyor mu?
İş etkisi teknik etkiden ayrı açıklandı mı?
Düzeltme sahibi belirlendi mi?
Retest kriteri yazıldı mı?
Benzer risklerin nerelerde tekrar edebileceği kontrol edildi mi?
Monitoring veya alert tarafında görünürlük var mı?
Olay müdahale adımı gerekiyorsa planlandı mı?
Yönetim özeti teknik jargona boğulmadan hazırlanabilir mi?

Sonraki Teknik Adım

Bu checklist tamamlandıktan sonra bulgular önem sırasına göre backlog’a taşınmalı, kritik riskler için retest planı çıkarılmalı ve ilgili servis/hub sayfasına iç bağlantı verilmelidir. Eresus Security bu aşamada kapsam netleştirme, kanıt üretme ve remediation önceliklendirme konusunda teknik ekiplerle birlikte çalışır.

Ek Kontrol Soruları

Bu risk hangi varlıkları etkiliyor?
Hangi kullanıcı rolleri bu akışa erişebiliyor?
Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
Bulgunun müşteri verisine etkisi var mı?
Loglardan olayın izi sürülebiliyor mu?
Düzeltme sonrası retest nasıl yapılacak?
Geçici önlem ile kalıcı çözüm ayrıldı mı?
İş etkisi teknik ekibin dışında da anlaşılır mı?
Benzer hata için önleyici kontrol eklenebilir mi?
Ekip bu kontrolü release sürecine bağlayabilir mi?
Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?

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