Sıfır yetkili IAM kullanıcısı, SNS'ten API Gateway'a uzanan kimlik bilgisi zinciriyle Secrets Manager'dan veri okuyor

Senaryo

dev.to'daki bir yazı, VirajMathpati'ye atfedilen 2025 tarihli bir CloudGoat senaryosunu ele alıyor; bu senaryoda IAM kullanıcısının Secrets Manager'a dokunan hiçbir yetkisi yok. IAM Access Analyzer ile kontrol edildiğinde kimlik temiz görünüyor: erişim yok. AWS'deki yetki yükseltme (privilege escalation) yollarını bulmak için geliştirilmiş bir araç olan PMapper da aynı yanıtı veriyor. Politika tabanlı her inceleme, bu principal'ın hesaptaki tek bir secret'ı bile okuyamayacağı sonucuna varırdı.

Kullanıcı buna rağmen secret'ı yedi API çağrısında elde ediyor.

Dört servisten oluşan zincir

Yazıya göre kullanıcı ile Secrets Manager arasındaki bağlantı bir yetkilendirme değil, dört servis boyunca hareket eden bir kimlik bilgisi değeri:

• Bir SNS topic'i, API Gateway anahtarı içeren mesajlar yayımlıyor. Kullanıcının politikası tüm kaynaklarda sns:Subscribe ve sns:ListTopics yetkilerine izin veriyor ve topic'in kendi kaynak politikası olmadığından tek engel IAM kimlik politikası — ve bu politika aboneliğe izin veriyor.
• Anahtar, mesajın içeriği olarak abonenin gelen kutusuna düşüyor.
• Anahtar, yalnızca anahtarla kimlik doğrulama yapacak şekilde yapılandırılmış — IAM imzası, Cognito veya Lambda authorizer bulunmayan — bir API Gateway'a kimlik doğrulaması sağlıyor.
• Gateway'ın Lambda entegrasyonu, execution role'u altında hedef secret'ı Secrets Manager'dan okuyor ve HTTP yanıt gövdesinde döndürüyor.

Her adım kendi başına yetkilendirilmiş durumda ve her yapılandırma servis bazlı bir kontrol listesine göre sorunsuz görünüyor: geniş ama ilgisiz bir IAM politikası, varsayılan yalnızca sahip erişimi duruşunu kullanan bir topic, gateway üzerinde belgelenmiş bir kimlik doğrulama modu ve secret erişimi için standart deseni izleyen bir Lambda. Kusur parçaların kendi başına değil, birleşme biçiminde — ve tek bir politika SNS'i Secrets Manager'a bağlamıyor.

Yetersiz kalan deny listesi

Senaryonun yazarı bu maruziyeti öngörmüş. Kullanıcının politikası apigateway:GET yetkisini geniş biçimde veriyor ancak API anahtarı listelemelerini, method gövdelerini ve entegrasyon ayrıntılarını kapsayan yedi yolu açıkça reddediyor. dev.to analizine göre bu, sıradan bir inceleme ölçütüyle özenli bir deny.

Yazıda ardından stave adlı bir araç için examples dizininde, bilinen 24 API Gateway yönetim yolu Z3 solver sorguları olarak kodlanmış ve 21'inin hâlâ erişilebilir olduğu görülmüş. Saldırının engellenen uç noktalara ihtiyacı yok: REST API'lerini listelemek tüm API ID'lerini, stage listelemesi stage adlarını, resources listelemesi ise yolları veriyor — invoke URL'sini eksiksiz kurmak ve sızan anahtarla çağırmak için yeterli bu. Yazının vardığı sonuç, deny listelerinin bir servisin yönetim yüzeyinin büyüklüğüne ayak uyduramayacağı.

Zincirin modellenmesi

Analiz, çözüm yazısındaki yapılandırmaya karşı dört, iyileştirilmiş bir sürüme karşı ise dört Z3 sorgusu daha çalıştırıyor. Bulgular birbirinin üzerine inşa ediliyor:

1. Topic hem bu principal tarafından abonelik alınabilir hem de bir kimlik bilgisi yayımlıyor — kimlik politikası, topic politikasının yokluğu ve topic yüküne ilişkin bir veri akışı olgusunun bileşimi.
2. API Gateway deny listesi yönetim yollarının çoğunu açık bırakıyor; invoke URL'sini kurmak için gereken üçü dahil.
3. Beş adımlık bir veri akışı zinciri geçerli: principal abone olabilir; topic bir kimlik bilgisi yayımlıyor; gateway bu kimlik bilgisini IAM auth olmadan kabul ediyor; gateway bir fonksiyonla entegre; ve o fonksiyon Secrets Manager'dan okuma yapıyor. Her adım farklı bir servisin yapılandırmasında gözlemlenen bir olgu ve bunların birleşimi sağlanabilir.
4. Bulguların birleşimi çalışan yetki yükseltmeyi veriyor: topic'leri listele, abone ol, anahtarı çıkar, gateway'ı say, sonra çağır ve secret'ı yanıt gövdesinde al.

Yazının kilit modelleme noktası şu: Tek varlık denetimleri bunu ifade edemez. Olgular dört ayrı gözleme ve bir varlıklar arası iddiaya yayıldığından, bu sorun sınıfını tespit etmek aynı anda birden çok servis üzerinde akıl yürütmeyi gerektiriyor.

Neden önemli

Yetki tarayıcıları — IAM Access Analyzer, PMapper ve genel olarak politika inceleme araçları — kimlikleri tek tek politika bazında değerlendiriyor. Bu senaryo, tüm bu araç sınıfına yapısal olarak görünmez olan bir yetki yükseltme yolunu gösteriyor; çünkü yol bir yetkilendirmeyle değil, meşru entegrasyonlar boyunca akan bir secret değeriyle taşınıyor. Kimlik bilgilerinin mesaj topic'leri veya anahtarla kimlik doğrulanan gateway'lar üzerinden aktığı her ortamda aynı maruziyet var.

Pratik önlemler gösterişsiz: SNS yüklerinde asla kimlik bilgisi yayımlamayın, topic'lere kaynak politikası ekleyin, ayrıcalıklı fonksiyonların önündeki gateway'larda yalnızca anahtar tabanlı auth yerine IAM veya Cognito yetkilendirmesini tercih edin ve tüm kaynaklarda geniş sns:Subscribe yetkisini başlı başına bir bulgu olarak değerlendirin. Daha derin sonuç araçlara dönük: bulut güvenliği analizi, veri akışına duyarlı ve servisler arası akıl yürütmeye ihtiyaç duyuyor — bu yazıdaki solver ile kodlanan birleşim bunun bir taslağı; aksi halde Secrets Manager'da hiçbir yetkisi olmayan bir principal, secret'ları elinde tutarak bitirebilir.