Series · 3 partsWhen Access Checks FailPart 3 · You are here
- 1CI/CD ve OIDC Güven Sınırı: GitHub Actions'tan Buluta Yetki Geçişi
- 2İmza Geçerli. Token Hâlâ Başka Bir Yere Ait: JWT Doğrulama Sınırı
- 3İstek Sunucu Tarafında Kaldı. Kimlik Bilgisi Kalmadı: SSRF ve Cloud MetadataYou are here
60 saniyede SSRF
Bir SSRF bulgusu genellikle bir URL ile gösterilir ve şu cümleyle raporlanır: “Sunucu keyfi giden (outbound) istekler yapabilmektedir.” Bu cümle bir yeteneği tanımlar ancak etki hakkında neredeyse hiçbir şey söylemez.
Sunucunun zaten istek yapmasına izin verilmiştir. Asıl güvenlik sorusu, bu isteklerin neleri devraldığıdır: dahili yönlendirme (routing), güvenilen kaynak IP adresleri, ortam yetkileri (ambient credentials), proxy istisnaları, yönlendirme (redirect) işleme biçimi ve link-local kontrol düzlemlerine (control plane) erişim. SSRF, güvenilmeyen bir girdi bu sınırlardan birini aştığında ve ortaya çıkan istek arayan kullanıcı yerine sunucunun kendisi olarak değerlendirildiğinde ciddileşir.
URL yalnızca ilk kenardır. Asıl bulgu rotanın kendisidir.
Doğrulamadan sonra dört karar gerçekleşir
Uygulama kodlarının çoğu bir metni (string) doğrular, ardından bunu bir dizi ek dönüşüm gerçekleştiren ağ yığınına (network stack) teslim eder:
- Ayrıştırıcı (parser); şemayı (scheme), authority’yi, kullanıcı bilgisini, host’u, portu ve yolu (path) çözümler.
- DNS, kabul edilen hostname’i bir veya daha fazla adrese dönüştürür.
- HTTP istemcisi, muhtemelen yeni bir şemaya veya adrese doğru yönlendirmeleri (redirects) takip eder.
- Bir proxy, servis ağı (service mesh) veya host rotası, isteğin gerçekte nereye gideceğine karar verir.
Eğer güvenlik politikası yalnızca bu dönüşümlerden önce çalışırsa; bir ismi yetkilendirir, ağ ise bir adrese bağlanır. İkisi, tıpkı bir reverse proxy ile uygulamanın bir yol (path) konusunda ayrışabilmesiyle aynı nedenlerle ayrışabilir.
127.0.0.1 için oluşturulmuş bir engelleme listesi (blacklist/blocklist), amaçlanan politikayı ifade etmez. Amaçlanan politika genellikle şudur: “Bu özellik, yalnızca bu hedeflerden genel HTTPS kaynaklarını çekebilir; bu kümenin dışındaki bir yönlendirmeyi takip etmemelidir; ve her DNS çözümlemesinden sonra özel (private), loopback, link-local veya kontrol düzlemi aralıklarına asla ulaşmamalıdır.”
Bu bir izin verilenler listesi (allowlist) artı bağlantı anında yapılan bir adres kontrolüdür; yasaklı metinlerden oluşan bir koleksiyon değildir.
Dahili bir hedefle değil, bir canary ile başlayın
İlk test, özelliğin sunucu taraflı bir istek gerçekleştirip gerçekleştirmediğini ve bu isteğin neye benzediğini yanıtlamalıdır. İstek başına benzersiz bir yola sahip, değerlendirme kontrolündeki bir HTTPS endpoint’i kullanın. Kaynak IP adresini, metodu, header’ları, DNS sorgularını, yönlendirme davranışını ve zamanlamayı kaydedin.
https://canary.example.test/ssrf/<engagement>/<request-id>Bu gözlem, sunucu taraflı getirme (fetch) işlemlerini istemci taraflı gezinmeden ayırır ve dahili bir servise dokunmadan gizli davranışları ortaya çıkarır. Sunucunun çıkış (egress) adresinden gelen bir istek pozitif bir kanıttır. Hiçbir isteğin gelmemesi otomatik olarak negatif bir sonuç değildir: Uygulama işi kuyruğa alıyor olabilir, şemaları kısıtlıyor olabilir, bir proxy üzerinden çözümlüyor olabilir veya yalnızca belirli içerik türlerini çekiyor olabilir. Canary, test genişletilmeden önce beklenen yanıt biçimini yansıtmalıdır.
Ardından her seferinde tek bir özelliği değiştirin:
- İzin verilen bir canary hostname’inden ikinci bir kontrollü hostname’e yönlendirme;
- Birden fazla genel canary adresine çözümlenen bir hostname;
- Zaman aşımı ve yeniden deneme davranışını belirlemek için yavaş bir yanıt;
- Bağlantı kurulmadan önce reddedildiğini teyit etmek için HTTPS dışı bir şema;
- Yasaklanmış bir adrese yönlendiren ve bu hedefe temas etmeden engellenmesi gereken izinli bir hostname.
Bu testler istemcinin durum makinesini haritalandırır. Gerçek dahili host’ları yoklamayı gerektirmez.
DNS’ten sonra ve her yönlendirmeden sonra doğrulayın
Uygulama bir hedefin genel (public) olup olmadığına yalnızca hostname metnine bakarak karar veremez. İsmi çözümlemek, dönen her adresi incelemek ve sonraki bir sorgunun cevabı sessizce değiştirmesine izin vermeden bağlantıyı izin verilen bir sonuca bağlamak zorundadır.
Yönlendirmeler bu süreci yeniden başlatır. Bir 302 yanıtı, orijinal güven kararını devralma izni değildir. Yeni URL’nin ilkiyle aynı şema, host, port, DNS ve adres politikasına ihtiyacı vardır. İstemci yöntem değiştirirse veya hassas header’ları host’lar arasında iletirse, bu davranışlar da bulgunun birer parçasıdır.
En güvenli getirme mekanizması (fetcher) kasıtlı olarak son derece sıkıcıdır:
kanonik HTTPS URL'sini ayrıştır
-> hostname ve portu açık izin verilenler listesi (allowlist) ile karşılaştır
-> tüm adresleri çözümle
-> private, loopback, link-local, multicast ve rezerve sonuçları reddet
-> doğrulanmış adrese bağlan
-> yönlendirmeleri devre dışı bırak veya her sıçrama için kararı baştan çalıştır
-> yanıt boyutu, içerik türü ve süre sınırlarını zorunlu kılGiden bir proxy veya servise özel bir getirme aracısı (fetch broker), bunu tutarlı bir şekilde uygulamayı kolaylaştırır. Uygulama kodu, bir URL kabul eden her özellikte ağ politikasını yeniden üretme konusunda başarısızdır.
Metadata özel bir URL değil, bir kimlik sınırıdır
Bir EC2 instance’ında, Instance Metadata Service link-local bir adres üzerinden erişilebilirdir. Uygulamalar bazen bu düz adresi engellemeyi SSRF düzeltmesi olarak kabul eder. Kalıcı kontrol ise çok daha güçlüdür: IMDSv2’yi zorunlu kılmak, metadata erişilebilirliğini yalnızca ihtiyaç duyan iş yükleriyle sınırlandırmak ve iliştirilen role yalnızca iş yükünün ihtiyaç duyduğu izinleri vermek.
IMDSv2 oturum odaklı bir token kullanır. Bir istemci önce token istemek için bir PUT isteği gönderir, ardından bu token’ı sonraki metadata GET isteklerinde sunar. Bu, yalnızca sabit bir GET gönderebilen veya gerekli header’ı ayarlayamayan birçok basit SSRF primitive’ini engeller. Ancak keyfi sunucu taraflı istek yeteneğini güvenli bir tasarıma dönüştürmez. Yeterince yetenekli bir primitive, yerel bir proxy veya ele geçirilmiş bir süreç bu alışverişi yine de yerine getirebilir.
Hop limit (sıçrama limiti) bir diğer sınırdır. Metadata token yanıtının ne kadar uzağa seyahat edebileceğini kontrol eder; bu da konteyner ağ yapısı bir sıçrama eklediğinde önem kazanır. Doğru değer dağıtım topolojisine bağlıdır; iş yükünü test etmeden bunu genel bir sıkılaştırma kontrol listesinden ayarlamak, ya kimlik bilgisinin teslim edilmesini bozar ya da amaçlanandan daha geniş bir rota bırakır.
Yetkilendirilmiş bir doğrulama için hiçbir kaynak erişimi vermeyen bir lab rolüne sahip özel bir test instance’ı kullanın. Yalnızca uygulamanın yapılandırılmış IMDS modu altında instance metadata bilgisi gibi etkisiz bir metadata yoluna ulaşıp ulaşamadığını kanıtlayın. Rol kimlik bilgilerini çekmeyin veya saklamayın. Kanıt paketinde yeni bir kimlik bilgisi maruziyeti yaratmadan sınırı kanıtladığında bulgu çok daha güçlüdür.
Çıkış (egress), bir hatanın platform yoluna dönüşüp dönüşmeyeceğini belirler
Uygulama doğrulaması ilk kontroldür. Ağ çıkışı ise bağımsız negatif kontroldür. Bir görsel servisinden avatar çekmesi gereken bir iş yükü; her RFC1918 segmentine, orkestrasyon API’sine, metadata endpoint’ine ve yönetim düzlemine giden genel bir rotaya sahip olmamalıdır.
Bu ayrım önemlidir çünkü URL doğrulama kodu sıklıkla değişir. Çıkış politikası, bir parser regresyonunun bir kimlik ihlaline dönüşmesini engelleyebilir. Tersine, mükemmel bir uygulama allowlist’i, ağ sınırının güvenli olduğunun kanıtı olarak kullanılmamalıdır; her kontrol diğerinin başarısız olduğu varsayılarak test edilmelidir.
Kanıt matrisi (Evidence matrix)
| Sinyal | Neyi kanıtlar | Negatif kontrol | Savunucu doğrulaması |
|---|---|---|---|
| Sunucu altyapısından benzersiz canary isteği gelir | Uygulama giden bir istek gerçekleştirmektedir ve getirme davranışını açığa çıkarır | Desteklenmeyen bir şema veya izin verilmeyen bir hostname kullanın ve hiçbir canary teması olmamasını bekleyin | Uygulama istek ID’si, DNS, proxy ve egress log’larını birbiriyle ilişkilendirin |
| Kontrol edilen ikinci bir genel host’a yapılan yönlendirme yeniden doğrulanır veya engellenir | Yönlendirme işlemi, ilk hedefin güvenini körü körüne devralmaz | Yasaklanmış bir test adresine yönlendirin ve host’tan hiçbir bağlantı denemesinin çıkmadığını doğrulayın | Her yönlendirme sıçramasını şema, host, port, çözümlenen adres, metot ve iletilen header’lar açısından test edin |
| Tüm DNS yanıtları denetlenir ve bağlantı izin verilen bir sonuca bağlı kalır | Politika yalnızca orijinal hostname’e değil, adreslere de uygulanır | İzin verilen ve yasaklanan karma bir yanıt kümesi dönün ve reddedilmesini bekleyin | Bağlantı anında çözümleyici (resolver) sonuçlarını ve hedef IP’yi izleyin |
| IMDSv2 zorunlu test instance’ı, header içermeyen basit bir metadata çekme isteğini reddeder | Metadata sınırı, temel GET tabanlı SSRF’e direnç gösterir | Aynı iş yükündeki meşru bir SDK’nın amaçlanan kimliğini hâlâ elde ettiğini doğrulayın | HttpTokens, hop limit, metadata maruziyeti ve iliştirilmiş rol izinlerinin envanterini çıkarın |
| Çıkış politikası private, link-local ve kontrol düzlemi rotalarını reddeder | Bir parser hatası otomatik olarak dahili bir sıçrama noktasına (pivot) dönüşmez | Üretim servislerine dokunmadan reddedilen her sınıfta onaylanmış bir canary bağlantısı deneyin | İş yükü kimliğinden rota tablolarını, proxy’leri, service-mesh politikasını ve host güvenlik duvarını doğrulayın |
Sürekli gördüğüm model
Uygulama ekibi girdi metnini düzeltir. Ağ ekibi egress’in sahibidir. Bulut ekibi iş yükü rolünün sahibidir. Her biri kendi katmanından görünen parçayı kapatır ve aralarındaki istek yolu dokümante edilmeden kalır.
Bir bulgunun, onu kimin okuduğuna bağlı olarak “Yüksek” ile “Düşük” arasında gidip gelmesinin nedeni budur. Biri bir URL getirme mekanizması görür. Diğeri metadata kimlik bilgileri varsayar. Hiçbiri zincirin tamamı için kanıta sahip değildir.
Savunuculara teslim edilmesi gerekenler
Çözümlenen rotayı sunun. Kanonik URL’yi, her DNS yanıtını, yönlendirme sıçramasını, hedef adresi, proxy yolunu ve aşılan kesin güven sınırını kaydedin.
Kabiliyeti etkiden ayırın. Genel bir canary, sunucu taraflı getirme yeteneğini kanıtlar. Dahili erişilebilirlik bir ağ sınırı başarısızlığını kanıtlar. Kimlik etkisi iddia edilmeden önce metadata veya kontrol düzlemi erişimi bağımsız ve güvenli bir şekilde doğrulanmalıdır.
İki kontrol sahibi. Getiriciyi (fetcher) bir allowlist ve çözümleme sonrası doğrulama ile düzeltin; platformu ise egress kısıtlamaları, IMDSv2 ve en düşük ayrıcalıklı iş yükü kimliği ile düzeltin. Kontrollerden herhangi biri gerileyebilir (regress). Rotadan sağ çıkılmasını sağlayan ikisinin birlikteliğidir.
İstek sunucudan hiç çıkmayabilir. Ancak taşıdığı güven, ortamın yarısını boydan boya aşabilir.
Bu teknik not ne kadar güncel?
En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.
Yazar teknik incelemeyi tamamladı. Bu etiket tek başına laboratuvar yeniden üretimi iddiası taşımaz.