OzzTech - SSRF – Sunucu Tarafı İstek Sahteciliği

SSRF – Sunucu Tarafı İstek Sahteciliği

Sunucu Tarafı İstek Sahteciliği- SSRF

Sunucu tarafı istek sahteciliği, diğer adıyla SSRF, bir saldırganın sunucu tarafı uygulamayı, saldırganın seçtiği rastgele bir etki alanına HTTP istekleri yapması için teşvik etmesine olanak tanıyan bir web güvenlik açığıdır.

Tipik bir SSRF saldırısında, saldırgan sunucunun kuruluşun altyapısındaki yalnızca dahili hizmetlere bağlantı kurmasına neden olabilir. Diğer durumlarda, sunucuyu rastgele harici sistemlere bağlanmaya zorlayabilir ve yetkilendirme kimlik bilgileri gibi hassas verileri potansiyel olarak sızdırabilirler.

SSRF saldırılarının etkisi nedir?

Başarılı bir SSRF saldırısı, genellikle yetkisiz eylemlere veya kuruluş içindeki verilere, savunmasız uygulamanın kendisinde veya uygulamanın iletişim kurabileceği diğer arka uç sistemlerinde erişime neden olabilir. Bazı durumlarda, SSRF güvenlik açığı, bir saldırganın rastgele komut yürütme gerçekleştirmesine izin verebilir.

Harici üçüncü taraf sistemlere bağlantılara neden olan bir SSRF istismarı, güvenlik açığı bulunan uygulamayı barındıran kuruluştan geliyormuş gibi görünen kötü niyetli saldırılara neden olabilir.

Yaygın SSRF saldırıları

SSRF saldırıları, güvenlik açığı bulunan uygulamadan bir saldırıyı yükseltmek ve yetkisiz eylemler gerçekleştirmek için genellikle güven ilişkilerinden yararlanır. Bu güven ilişkileri, sunucunun kendisiyle veya aynı kuruluş içindeki diğer arka uç sistemleriyle ilgili olarak mevcut olabilir.

Sunucunun kendisine karşı SSRF saldırıları

Sunucunun kendisine yönelik bir SSRF saldırısında, saldırgan uygulamayı, geri döngü ağ arabirimi aracılığıyla uygulamayı barındıran sunucuya bir HTTP isteği göndermeye teşvik eder. Bu genellikle, 127.0.0.1 (geri döngü bağdaştırıcısına işaret eden ayrılmış bir IP adresi) veya yerel ana bilgisayar localhost (aynı bağdaştırıcı için yaygın olarak kullanılan bir ad) gibi bir ana bilgisayar adına sahip bir URL sağlamayı içerir.

Örneğin, kullanıcının belirli bir mağazada bir ürünün stokta olup olmadığını görmesini sağlayan bir alışveriş uygulamasını düşünün. Stok bilgilerini sağlamak için uygulamanın, söz konusu ürüne ve mağazaya bağlı olarak çeşitli arka uç REST API'lerini sorgulaması gerekir. İşlev, URL'yi bir ön uç HTTP isteği aracılığıyla ilgili arka uç API uç noktasına ileterek uygulanır. Bu nedenle, bir kullanıcı bir öğenin stok durumunu görüntülediğinde, tarayıcısı şöyle bir istekte bulunur:
Bu, sunucunun belirtilen URL'ye istekte bulunmasına, stok durumunu almasına ve bunu kullanıcıya iade etmesine neden olur.

Bu durumda, saldırgan, sunucunun kendisinde yerel bir URL belirtmek için isteği değiştirebilir. Örneğin:

Sunucu Tarafı İstek Sahteciliği- SSRF

Burada sunucu /admin URL'sinin içeriğini alacak ve kullanıcıya geri gönderecektir.

Şimdi, elbette, saldırgan /admin URL'sini doğrudan ziyaret edebilir. Ancak yönetim işlevine normalde yalnızca uygun kimliği doğrulanmış kullanıcılar tarafından erişilebilir. Bu nedenle, doğrudan URL'yi ziyaret eden bir saldırgan, ilgi çekici bir şey görmez. Ancak /admin URL'sine istek yerel makinenin kendisinden geldiğinde, normal erişim kontrolleri atlanır. Uygulama, istek güvenilir bir konumdan geliyor gibi göründüğü için yönetim işlevine tam erişim sağlar.

Uygulamalar neden bu şekilde davranıyor ve yerel makineden gelen isteklere dolaylı olarak güveniyor? Bu, çeşitli nedenlerle ortaya çıkabilir:

  • Erişim denetimi denetimi, uygulama sunucusunun önünde bulunan farklı bir bileşende uygulanabilir. Sunucunun kendisine tekrar bağlantı yapıldığında, kontrol atlanır.
  • Olağanüstü durum kurtarma amacıyla, uygulama, yerel makineden gelen herhangi bir kullanıcıya oturum açmadan yönetici erişimine izin verebilir. Bu, bir yöneticinin kimlik bilgilerini kaybetmeleri durumunda sistemi kurtarması için bir yol sağlar. Buradaki varsayım, yalnızca tamamen güvenilir bir kullanıcının doğrudan sunucunun kendisinden geleceğidir.
  • Yönetim arabirimi, ana uygulamadan farklı bir bağlantı noktası numarasını dinliyor olabilir ve bu nedenle kullanıcılar tarafından doğrudan erişilemeyebilir.

Yerel makineden kaynaklanan isteklerin normal isteklerden farklı şekilde işlendiği bu tür güven ilişkileri, genellikle SSRF'yi kritik bir güvenlik açığı haline getiren şeydir.

Diğer arka uç sistemlere karşı SSRF saldırıları

Sunucu tarafı istek sahteciliğinde sıklıkla ortaya çıkan başka bir güven ilişkisi türü, uygulama sunucusunun, kullanıcılar tarafından doğrudan erişilemeyen diğer arka uç sistemlerle etkileşime girebilmesidir. Bu sistemler genellikle yönlendirilemez özel IP adreslerine sahiptir. Arka uç sistemler normalde ağ topolojisi tarafından korunduğundan, genellikle daha zayıf bir güvenlik duruşuna sahiptirler. Çoğu durumda, dahili arka uç sistemleri, sistemlerle etkileşime girebilen herkes tarafından kimlik doğrulaması yapılmadan erişilebilen hassas işlevler içerir.

Önceki örnekte, arka uç URL'sinde bir yönetim arayüzü olduğunu varsayalım.Sunucu Tarafı İstek Sahteciliği- SSRFBurada bir saldırgan, aşağıdaki isteği göndererek yönetim arabirimine erişmek için SSRF güvenlik açığından yararlanabilir:

Sunucu Tarafı İstek Sahteciliği- SSRF

Ortak SSRF savunmalarını atlatmak

Kötü niyetli istismarı önlemeyi amaçlayan savunmalarla birlikte SSRF davranışı içeren uygulamalara sıkça rastlanır. Çoğu zaman, bu savunmalar atlatılabilir.

Kara liste tabanlı giriş filtreleri

Bazı uygulamalar, 127.0.0.1 ve localhost gibi ana bilgisayar adlarını veya /admin gibi hassas URL'leri içeren girişi engeller. Bu durumda, genellikle çeşitli teknikler kullanarak filtreyi atlatabilirsiniz:

  • 2130706433, 017700000001 veya 127.1 gibi alternatif bir 127.0.0.1 IP temsili kullanma.
  • 127.0.0.1'e çözümlenen kendi alan adınızı kaydetme. Bunun için spoofed.burpcollaborator.net'i kullanabilirsiniz.
  • URL kodlaması veya büyük/küçük harf değişimi kullanarak engellenen dizeleri gizleme.

Beyaz liste tabanlı giriş filtreleri

Bazı uygulamalar yalnızca izin verilen değerlerin bir beyaz listesiyle eşleşen, onunla başlayan veyabir beyaz liste içeren girdilere izin verir. Bu durumda, bazen URL ayrıştırmadaki tutarsızlıklardan yararlanarak filtreyi atlatabilirsiniz.

URL spesifikasyonu, URL'lerin ad hoc ayrıştırma ve doğrulaması uygulanırken göz ardı edilebilecek bir dizi özellik içerir:

  • @ karakterini kullanarak kimlik bilgilerini ana bilgisayar adından önce bir URL'ye gömebilirsiniz. Örneğin:Sunucu Tarafı İstek Sahteciliği- SSRF
  • Bir URL parçasını belirtmek için # karakterini kullanabilirsiniz. Örneğin:Sunucu  Tarafı İstek Sahteciliği- SSRF
  • Kontrol ettiğiniz tam nitelikli bir DNS adına gerekli girişi yerleştirmek için DNS adlandırma hiyerarşisinden yararlanabilirsiniz. Örneğin: Sunucu TarafI İstek Sahteciliği- SSRF
  • URL ayrıştırma kodunu karıştırmak için karakterleri URL kodlaması yapabilirsiniz. Bu, özellikle filtreyi uygulayan kod, URL kodlu karakterleri arka uç HTTP isteğini gerçekleştiren koddan farklı şekilde işliyorsa kullanışlıdır.
  • Bu tekniklerin kombinasyonlarını birlikte kullanabilirsiniz.

Açık yeniden yönlendirme yoluyla SSRF filtrelerini atlamak

Açık bir yeniden yönlendirme güvenlik açığından yararlanarak her türlü filtre tabanlı savunmayı atlatmak bazen mümkündür.

Önceki SSRF örneğinde, kullanıcı tarafından gönderilen URL'nin, SSRF davranışının kötü niyetli olarak istismar edilmesini önlemek için kesin olarak doğrulandığını varsayalım. Ancak, URL'lerine izin verilen uygulama bir açık yeniden yönlendirme güvenlik açığı içeriyor. Arka uç HTTP isteğini yapmak için kullanılan API'nin yeniden yönlendirmeleri desteklemesi koşuluyla, filtreyi karşılayan ve istenen arka uç hedefine yönlendirilen bir istekle sonuçlanan bir URL oluşturabilirsiniz.

Örneğin, uygulamanın aşağıdaki URL'ye sahip bir açık yeniden yönlendirme güvenlik açığı içerdiğini varsayalım:

URL filtresini atlamak için açık yeniden yönlendirme güvenlik açığından yararlanabilir ve SSRF güvenlik açığından aşağıdaki gibi yararlanabilirsiniz:


Bu SSRF istismarı, uygulamanın ilk olarak sağlanan stockAPI URL'sinin izin verilen bir etki alanında olduğunu doğruladığı için çalışır. Uygulama daha sonra açık yeniden yönlendirmeyi tetikleyen sağlanan URL'yi ister. Yönlendirmeyi takip eder ve saldırganın seçtiği dahili URL'ye istekte bulunur.

Kör SSRF güvenlik açıkları

Kör SSRF güvenlik açıkları, bir uygulamanın sağlanan bir URL'ye arka uç HTTP isteği göndermesi için tetiklenebildiğinde ortaya çıkar, ancak arka uç isteğinden gelen yanıt, uygulamanın ön uç yanıtında döndürülmez.

Kör SSRF'den yararlanmak genellikle daha zordur, ancak bazen sunucuda veya diğer arka uç bileşenlerinde tam uzaktan kod yürütülmesine neden olabilir.

SSRF güvenlik açıkları için gizli saldırı yüzeyi bulma

Uygulamanın normal trafiği, tam URL'leri içeren istek parametrelerini içerdiğinden, birçok sunucu tarafı istek sahteciliği güvenlik açığını tespit etmek nispeten kolaydır. SSRF'nin diğer örneklerini bulmak daha zordur.

İsteklerdeki kısmi URL'ler

Bazen bir uygulama, istek parametrelerine yalnızca bir ana bilgisayar adını 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 ana bilgisayar adı veya URL yolu olarak kolayca tanınırsa, olası saldırı yüzeyi açık olabilir. Ancak, istenen URL'nin tamamını kontrol etmediğiniz için tam SSRF olarak kullanılabilirlik sınırlı olabilir.

Veri biçimleri içindeki URL'ler

Bazı uygulamalar, veri ayrıştırıcısı tarafından format için talep edilebilecek URL'lerin dahil edilmesine izin veren şartlara 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. XXE enjeksiyon güvenlik açıklarına baktığımızda bunu daha ayrıntılı olarak ele alacağız.

Yönlendirme başlığı aracılığıyla SSRF

Bazı uygulamalar, ziyaretçileri izleyen sunucu tarafı analiz yazılımı kullanır. Bu yazılım, özellikle gelen bağlantıların izlenmesi için önemli olduğundan, isteklerde Yönlendiren başlığını günlüğe kaydeder. Genellikle analiz yazılımı, Yönlendiren başlığında görünen herhangi bir üçüncü taraf URL'sini gerçekten ziyaret eder. Bu genellikle, gelen bağlantılarda kullanılan bağlantı metni dahil, yönlendiren sitelerin içeriğini analiz etmek için yapılır.

Sonuç olarak, Yönlendirme başlığı genellikle SSRF güvenlik açıkları için verimli saldırı yüzeyini temsil eder. Yönlendiren üstbilgisini içeren güvenlik açıklarının örnekleri için Kör SSRF güvenlik açıklarına bakın.


İlginizi Çekebilecek Makaleler
FortiGate ACME Sertifika Desteği
Siber Güvenlik

FortiGate ACME Sertifika Desteği

Ocak 24, 2022 1:22

Otomatik Sertifika Yönetim Ortamı (ACME), RFC 8555’te tanımlandığı üzere, ücretsiz SSL sunucu sertifikaları sağlamak için genel Let’s...

Android Reverse Mühendisliği Araçları Örnek Vakalar
Siber Güvenlik

Android Reverse Mühendisliği Araçları Örnek Vakalar

Ocak 24, 2022 12:39

Bir önceki yazıda yeni çıkan android reverse mühendisliği araçları hakkında bilgi vermiştim. Bu yazımda...

Emotet Artık Alışılmadık IP Adreslerini Kullanıyor
Siber Güvenlik

Emotet Artık Alışılmadık IP Adreslerini Kullanıyor

Ocak 24, 2022 9:44

Emotet kötü amaçlı yazılım botnetinin dağıtımını içeren sosyal mühendislik kampanyaları, güvenlik çözümlerinin tespitinden kaçınmak...

FortiWeb Kurulumu 5-Operation Modu
Siber Güvenlik

FortiWeb Kurulumu 5-Operation Modu

Ocak 24, 2022 7:49

FortiWeb kurulumunu anlattığımız beşinci yazımızda operation modu ve FortiWeb cihazı açıldıktan sonra, FortiWeb cihazını...

FortiWeb Kurulumu 4- Admin Şifresi Değiştirme
Siber Güvenlik

FortiWeb Kurulumu 4- Admin Şifresi Değiştirme

Ocak 23, 2022 10:21

FortiWeb kurulumunu anlattığımız serinin dördüncü yazısında Admin şifresi nasıl değiştirceğinizi, saat ve günü nasıl...

Metasploittable 2
Siber Güvenlik

Metasploittable 2

Ocak 22, 2022 11:57

Metasploittable 2 Nedir? Neden Kullanılır? Nasıl Kurulur? Metasploittable 2 Metasploit firması tarafından bizlerin güvenli...

FortiWeb Kurulumu 3- Firmware Güncellenmesi
Siber Güvenlik

FortiWeb Kurulumu 3- Firmware Güncellenmesi

Ocak 22, 2022 11:56

FortiWeb kurulumunu anlattığımız serinin üçüncü yazısında Firmware güncellemesini anlatacağız. FortiWeb cihazınız gönderildiğinde en son...

FortiWeb Kurulumu 2- Web UI ve CLI Bağlama
Siber Güvenlik

FortiWeb Kurulumu 2- Web UI ve CLI Bağlama

Ocak 21, 2022 7:50

FortiWeb kurulumu yazımızın ikinci serisinde Web UI veya CLI bağlamanın nasıl yapılacağını anlatacağız. Eğer...

Yapay Zeka Nedir?
Yazılım Geliştirme

Yapay Zeka Nedir?

Ocak 20, 2022 10:57

Sürekli olarak değişen, gelişen ve oldukça hızlı bir şekilde boyut atlayan, günümüze kadar gelen...

İletişim
OZZTECH Bilgi Teknolojileri olarak siber güvenlik danışmanlığı ve bilgi güvenliği eğitimleri alanlarında 10 yılı aşkın bir süredir ülkemizin önde gelen kurumlarına hizmet vermeye devam etmektedir. Detaylı bilgi ve danışmanlık hizmetlerimiz için aşağıdaki formu kullanarak veya [email protected] adresimiz üzerinden bizlerle iletişime geçebilirsiniz.