Server Side Request Forgery (SSRF) Zafiyeti Nedir?
SSRF zafiyeti web uygulamaları üzerinde server side (sunucu taraflı) yapılan istek sahteciliği sonucunda oluşan zafiyete denir. Zafiyetin birçok ciddi etkileri bulunmakta bunlar:
Saldırgan kritik bilgilere erişebilir (leaking sensitive data), internal servislere erişim sağlayabilir, kullanıcıların yapamaması gereken işlemleri yaparak bazı ekleme, silme, değiştirme vb.. İşlemlere olanak sağlamaktadır.
Zafiyetin Nedenleri
- URL validation olmazsa bu zafiyet meydana gelebilir.
- Bazen bir uygulama, istek parametrelerine yalnızca bir hostname veya bir URL yolunun bir kısmını yerleştirir. Gönderilen değer daha sonra sunucu tarafında istenen tam URL’ye dahil edilir. Değer, bir hostname veya URL yolu olarak kolayca tanınırsa, olası saldırı yüzeyi açık olabilir.
- Bazı uygulamalar, veri ayrıştırıcısı tarafından format için talep edilebilecek URL’lerin dahil edilmesine izin veren spesifikasyonlara sahip formatlarda veri iletir. Bunun açık bir örneği, yapılandırılmış verileri istemciden sunucuya iletmek için web uygulamalarında yaygın olarak kullanılan XML veri formatıdır. Bir uygulama XML biçimindeki verileri kabul edip ayrıştırdığında, XXE enjeksiyonuna karşı savunmasız olabilir ve karşılığında XXE aracılığıyla SSRF’ye karşı savunmasız olabilir.
Zafiyetin Tespiti
- Bir şekilde application’dan gelen istekler içerideki başka bir server ya da sunucudan işlem yapmasını sağlayabilirsek bu zafiyeti bulmuş olabiliriz.
- Api’den bilgi çekiliyor ise bunun üzerinden erişim sağlamaya çalışarak tespit edilebilir.
- Giden istekteki Referrer header’i üzerinde yapılan değişiklikler ile de bulunabilir.
Önce Teorik olarak zafiyetin nasıl meydana geldiğini ele aldığımıza göre biraz daha pratik uygulamalar eşliğinde konuya devam edelim. Pratik uygulamaları PortSwigger lab’ları üzerinden gösteriyor olacağım.
Lab 1: Basic SSRF against the local server
Bu lab’da bizden carlos kullanıcısını silmemiz istenmektedir. Bir ürünü açtıktan sonra aşağıda “check stock” butonu olduğunu görüyoruz. Butonu tıkladıktan sonra bu isteği intercept ediyoruz çünkü elindeki stock bilgisini api’den alabilir diye düşündük ve aşağıdaki ekran görüntüsünden de görüldüğü üzere yanılmadık.
Daha sonra basit bir şekilde stockApi değerini https://localhost olarak güncelliyoruz ve 200 döndü hiçbir koruma olmadığı için direkt sonuç alabildik.
Ekran üzerinde görmek için açılan sayfayı aşağıdaki ekran görüntüsündeki gibi in current browser session seçiyoruz ve değeri kopyalayıp tarayıcımızdan açıyoruz.
Açtığımızda karşımıza aşağıdaki gibi bir ekran çıkmakta.
Görüldüğü üzere carlos kullanıcısını silebiliriz admin panel’ine erişim sağlamış durumdayız. Bu panel üzerinden silmek istesek de silemeyiz çünkü admin yetkilerine sahip olduğumuzu belirten api parametresi buradaki istek üzerinde yoktu.
Sonuç 401 döndü ama buradan bir silme işlemi yapılacaksa hangi parametre ve değerler gittiğini öğrenmiş oluyoruz. delete?username=carlos ile carlos’u silme işlemi yapılıyor biz bu değeri alıp stocApi parametresine ekleyerek silme işlemini gerçekleştirebileceğiz.
Yukarıdaki ekran görüntüsündeki gibi edindiğimiz parametre ve değeri api’nin devamına ekleyip bu isteği gönderdiğimizde lab’ın çözümünü sağlamış oluyoruz.
Lab 2: Basic SSRF against another back-end system
Bu lab’da da amacımız carlos kullanıcısını silmek. Api’ye istek atarak stock durumunu kontrol eden isteği intercept ederek repeater’a gönderiyoruz. Daha sonra aşağıdaki ekran görüntüsündeki gibi localhost:/admin deniyoruz ama 500 döndü bizim içerideki servis’e erişimimize izin vermedi.
Bazı internal servisler non routable ip adresi üzerinden erişim sağlayabilmektedirler. Bunu denemek için isteği intruder’a gönderiyoruz. Api değerini 192.168.0.0:8080 yapıyoruz ve aşağıdaki gibi position ayarlıyoruz.
Daha sonra aşağıdaki ekran görüntüsündeki gibi numbers seçip 1 ile 255 arasında olacak şekilde payload kısmını ayarlıyoruz.
Saldırıyı başlatıyoruz ve aşağıdaki ekran görüntüsünü incelediğimizde 171 ip değerine erişim sağladığımızı görüyoruz 200 sonucu dönmüş.
Bulduğumuz ip adresini ekliyoruz ve devamını carlos’u silmek için gereken şekilde düzenleyip aşağıdaki ekran görüntüsünde olduğu gibi gönderiyoruz ve lab’ın çözümünü sağlamış oluyoruz.
Lab 3: SSRF with blacklist-based input filter
Lab’ı açıyoruz ve önceki örneklerde yaptıklarımız gibi api isteğini repeater’a gönderip inceliyoruz.
Yukarıdaki gibi bir hata aldık burada herhangi bir şey blacklisting ile engelleniyor olabilir bu nedenle URL encode yaparak yeniden göndermeyi deniyoruz.
Yukarıdaki ekran görüntüsündeki gibi encode edip yeniden gönderiyoruz.
Bir sonuç alamıyoruz 2. Bir URL encode yapıp yeniden deniyoruz bunun nedeni application kontrolleri yaparken encode işlemlerine karşı 1 kere URL decode yaparak kontrol gerçekleştirebilmektedir. Eğer saldırgan 2 kere encode yaparsa bunu atlatabilmektedir. Aşağıdaki ekran görüntüsündeki gibi deniyoruz ama yine sonuç alamıyoruz.
İlk olarak localhost yerine geçen ip adres değeri ile deniyoruz 127.0.0.1 ama sonuç alamıyoruz. Buna bir alternatif olarak aradaki 0 değerlerini silerek aşağıdaki ekran görüntüsündeki gibi deniyoruz ve sonunda olumlu sonuç alıyoruz.
Neden 127.1 olarak denedik ve nasıl sonuç aldık?
Aradaki boş bıraktığımız octet değerlerini istek giderken otomatik olarak 0 ile doldurup gönderilmektedir. Bu nedenle giden isteği değerlendiren sistem 127.0.0.1 olarak değerlendirmektedir aynı zamanda kontrolden geçerken 127.1 olarak değerlendirildiğinden ve bu değer blacklist’in içinde bu değer olmadığı için bypass etmeyi başarıyoruz.
Yukarıdaki gibi /admin ekliyoruz ama yine 400 döndü burada da bir URL encode deneyerek bunu aşabiliriz çünkü dönen sonuçtan anlaşılıyor ki admin değeri de blacklist içinde. Aşağıdaki ekran görüntüsündeki gibi admin değerini 2 defa URL encode yapıyoruz.
Bunu isteğe ekleyip gönderiyoruz ve aşağıdaki ekran görüntüsündeki gibi 200 döndü istenilen sonucu aldık.
Geri kalan sadece carlos’u silmek için gerekli değerleri eklemek ve aşağıdaki ekran görüntüsündeki gibi ekleyip gönderdiğimizde lab’ın çözümünü sağlıyoruz.
Lab 4: SSRF with filter bypass via open redirection vulnerability
Bu lab kapsamında yine carlos kullanıcısını silmeye çalışacağız. Yine benzer şekilde api’ye istek atan parametreyi bulup inceliyoruz.
Api üzerinde denemeler yaptım fakat sonuç alamadım. Soru bize bir ip adresi vermişti hali hazırda bunu open redirect zafiyeti ile birleştirip kullanmayı deniyorum ve POST isteğini aşağıdaki ekran görüntüsündeki gibi güncelliyorum. Görüldüğü üzere 200 döndü yani open redirect zafiyeti bulunmakta.
Daha sonra bu zafiyet üzerinden ilerlemeyi deniyorum ama aşağıdaki gibi sonuç alamadım.
Daha sonra biraz daha sayfayı incelediğimizde bir “next product” butonu görüyoruz ve onu inceliyoruz.
Bu istek bizi sonuca götürmekte büyük bir rehber olacak çünkü redirect yazdığımda başarılı oldu ama carlos’u silemedik demek ki uygulama bu parametreye bu işlem için izin vermedi ama bu istekte bir nextProduct parametresi ve devamında da bazı değerler görüyoruz. Burada önemli olan path parametresi çünkü bir path’i (yol) belirtirken kullanılmış tıpkı bizim yapmak isteğimiz gibi bu nedenle redirect yerine path parametresini deneyebiliriz.
Yukarıdaki gibi isteği path parametresini ekleyerek güncellediğimizde lab’ın çözümünü sağlamış oluyoruz.
Lab 5: Blind SSRF with out-of-band detection
Bu lab’da out-of-band yani dışarıdaki farklı bir domain’e istek atmaya çalışacağız. Herhangi bir ürünü incelemek için açtığımızda aşağıdaki ekran görüntüsündeki gibi bir istek gittiği görülmektedir.
Zafiyetin tespiti aşamasında referer header’den bahsetmiştik burada onun üzerinden ilerleyeceğiz. Burp Collabolator Client üzerinden domain adresini kopyalıyoruz ve aşağıdaki ekran görüntüsündeki gibi referer header’ina yapıştırıyoruz.
İsteğin başarılı şekilde gittiği görülmektedir daha sonra Collaborator Client üzerindeki “pull now” butonu ile istekleri alıyoruz ve lab’ın çözümünü sağlıyoruz.
Lab 6: SSRF with whitelist-based input filter
Giden istekleri inceleyip api ile ilgili olan isteği intercept edip repeater’a gönderiyoruz.
Ardından birkaç deneme yapıyoruz ve dönen cevaba göre burada bir whitelisting var ve istenilen host olmaz ise isteği göndermediğini aşağıdaki ekran görüntüsünden anlıyoruz.
Burada yapacağımız şey ise istenilen host değerini silmeden onun önüne ya da sonuna istediğimiz bir değeri ekleyerek sonuç almaya çalışmak olacaktır.
Yukarıdaki ekran görüntüsündeki gibi bir şey deniyoruz ve sonuç verdi gibi şimdi bunu üzerinden silme işlemini deniyoruz.
Yukarıdaki gibi birkaç işlem denedim ama sonuç alamadım bizde kendi host değerimizi bu sefer başa eklemeyi deniyoruz ve diğer host ile arasına bazı işaretler koyarak onları ayırmayı deniyoruz.
Yukarıdaki gibi @ işareti ve # işaretinin encode edilmiş halini yani %2523 koyduğumuzda 200 değeri dönmekte bundan sonra geriye kalan carlos kullanıcısını silen isteği göndermek oluyor.
Yukarıdaki gibi isteği gönderdiğimiz zaman lab’ın çözümünü sağlamış oluyoruz.
Lab 7: Blind SSRF with Shellshock exploitation
Bu lab’da shellshock zafiyeti ile blind SSRF senaryosunu gerçekleştireceğiz.
İlk olarak yukarıdaki gibi isteği repeater’a gönderiyoruz.
Daha sonra Google’dan shellshock zafiyetini arttığımızda kullanılan payload karşımıza çıkıyor bunu User-Agent’e şekildeki gibi ekliyoruz. En sondaki yer alan domain ise Burp Collabolator’un domain adresi.
İstek başaralı dönüyor ama bir sonuç vermedi Collaborator üzerinde bu nedenle referer header’ına da 192.168.0.1:8080 ekliyoruz ve bunu üzerinden intruder aracılığı ile bir saldırı deneyeceğiz.
Yukarıdaki ekran görüntüsündeki gibi position’u ekliyoruz. Daha sonra payload kısmını da numbers olarak seçip 1 ile 255 arasını seçiyoruz. Bu şekilde saldırıyı başlatıyoruz.
Saldırı bittikten sonra Collaborator kısmından “pull now” butonuna bastığımızda aşağıdaki ekran görüntüsündeki gibi sonucun başarılı bir şekilde döndüğü görülmektedir.
Bu şekilde dönen domain’i submit ettiğimizde lab’ın çözümünü gerçekleştirmiş oluyoruz.
Çözüm Yolları
- Whitelisting yöntemi uygulanabilir.
- Blacklisting yöntemi uygulanabilir.
- Gelip giden istekler içinde parametreler ve bilgiler tutarlı ve detaylı kontrollerden geçmelidir.
Elimden geldiğince konudaki bilgilerimi aktarmaya çalıştım umarım faydalı olmuştur. Başka konularda görüşmek üzere.
Emin FİDAN tarafından hazırlanmıştır.
