Server Side Request Forgery(SSRF) de Neymiş?


Herkese merhabalar. Bu yazımda SSRF (server side request forgery) konusuna giriş yapacam. SSRF olayına birde ben giriş yapayaım diyerek kaleme aldım. İstiyorsanız başlayalım.
İlk merak ettiğimiz olay SSRF Nedir?
SSRF - Sunucu Taraflı İsteği Sahteciliği - bir saldırgan sunucu adına istek gönderebildiğinde ortaya çıkan bir güvenlik açığıdır. Saldırganların güvenlik açığı bulunan sunucunun istek imzalarını "şekillendirmelerini" sağlar, bu nedenle bir ağ üzerinde ayrıcalıklı bir pozisyon üstlenir, güvenlik duvarı denetimlerini atlayarak ve dahili hizmetlere erişim kazanır.
Örneğin, bir şirketin ağında halka açık bir web sunucusu olduğunu hayal edin: "ornek.example.com"
ornek.example.com , ornek.example.com/proxy adresinde bulunan ve “url” parametresinde belirtilen web sayfasını alan ve kullanıcıya geri döndürecek bir proxy hizmetine ev sahipliği yaptığını varsayalım. Örneğin, kullanıcı URL’ye eriştiğinde:

https://ornek.example.com/proxy?url=google.com

web uygulaması “google.com” ana sayfasını gösterecektir.
Şimdi diyelim ki admin_panel.example.com gizli bir yönetici panelini barındıran dahili bir sunucudur. Yalnızca çalışanların yönetici paneline erişebilmesi için, erişim kontrolü, panele Internet üzerinden erişilemeyecek, ancak geçerli bir dahili IP'den (bir çalışan iş istasyonu gibi) erişilebilecek şekilde ayarlandı. Şimdi, bir kullanıcı aşağıdaki URL’ye erişirse ne olur?

https://ornek.example.com/proxy?url=admin_panel.example.com

SSRF koruma mekanizması mevcut değilse, web uygulaması yönetici panelini tekrar kullanıcıya gösterecektir, çünkü istek ağda güvenilir bir makine ornek.example.com'dan geliyor !
Normalde firewall'ler bunu dışardan herhangi bir saldırı yönteminde engeller ama bu sefer istek içerden geldiği için herhangi bir önleme yapmaz.
Bunun nedeni, ağın çevre tarafında bulunan - halka açık web sunucuları ve İnternet makineleri arasında - güvenli ağdaki makineler arasında - ornek.example.com ve admin_panel.example.com arasında bulunmasıdır.
Güvenlik açığı bulunan sunucuya verilen izinlere bağlı olarak, saldırgan hassas dosyaları okuyabilir, dahili API çağrıları yapabilir ve gizli yönetici panelleri gibi dahili servislere erişebilir.
İki tür SSRF güvenlik açığı vardır: Normal SSRF ve Blind SSRF. Her iki güvenlik açığının arkasındaki mekanizmalar aynıdır: ikisi de aynı ağdaki makineler arasındaki güvenden yararlanır. Tek fark, blind SSRF'lerde, saldırganın sunucudan bir HTTP yanıtı veya bir hata mesajı ile geri bildirim almamasıdır ( yukarıdaki örnekte admin_panel.example.com'un nasıl gösterildiği gibi). Bu, veri sızma ve ağ arama işlemlerini zorlaştırsa da, blind SSRF'ler saldırgan için çok kullanışlıdır.

Sırada ki sorumuz SSRF Açıkları Nasıl Tespit Edilir?
SSRF açıklarını keşfetmenin en iyi yolu, tüm URL girişlerinin doğrulanıp onaylanmadığını görmek için manuel bir kod incelemesidir. Bununla birlikte, kaynak kod bulunmadığında ve tam kod incelemesinin mümkün olmadığı durumlarda, SSRF'ye en yatkın olan özelliklerin test edilmesine odaklanılmalıdır.
Bir sunucu harici kaynaklar gerektirdiğinde SSRF'ler oluşur. Örneğin, bazen bir web uygulamasının bir görüntünün URL'sinden bir küçük resim oluşturması veya başka bir siteden (youtube.com gibi) bir videonun ekran görüntüsü oluşturması gerekebilir. Bir sunucu iç kaynaklara erişimi kısıtlamazsa, SSRF açıkları ortaya çıkar.
Ornek.example.com adresindeki aşağıdaki sayfa, kullanıcıların Internet'ten profil fotoğrafı yüklemelerine olanak sağlar:

https://ornek.example.com/upload_profile_from_url.php?url=www.google.com/ssrf_ozan.jpeg

ssrf_ozan.jpeg isimli dosyayı getirmek için gelen ornek.example.com , google.com'dan web uygulaması ziyaret etmek ve içeriğini almak zorunda kalacak  . Sunucu iç ve dış kaynaklar arasında bir ayrım yapmazsa, bir saldırgan istediği bilgiyi o kadar kolay talep edebilir:

https://ornek.example.com/upload_profile_from_url.php?url=localhost/secret_password_file.txt

Ve web sunucusunun, web sunucusunun şifresini içeren dosyayı göstermesini sağlayabilir. Genellikle SSRF'ye karşı hassas olan özellikler arasında webhooks'lar, URL yoluyla dosya yükleme, belge ve görüntü işlemcileri, bağlantı genişletme ve proxy hizmetleri (bu özelliklerin tümü harici kaynakları ziyaret etmeyi ve almayı gerektirir) içerir. Ancak, kullanıcı tarafından sağlanan bir URL'yi işleyen herhangi bir uç noktayı test etmek denenebilir.
SSRF testleri genellikle URL girişini dahili bir adresle sağlayarak başlar. Ağ yapılandırmasına bağlı olarak, birkaç farklı adres denemeniz gerekebilir. İlk önce denemek için birkaç tane:

127.0.0.0/8 
192.168.0.0/16 
10.0.0.0/8

Düzenli SSRF durumunda, sunucunun dahili servisle ilgili herhangi bir bilgiyi açığa çıkaran bir cevap verip vermediğini kontrol edin. Yanıt iç bannerlarda servis banner'ları veya HTML içeriyor mu?
Örneğin;

https://ornek.example.com/upload_profile_from_url.php?url=127.0.0.1:22

Sunucu şöyle cevap verirse;

Error: cannot upload image: SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4

Blind SSRF durumunda, genellikle açık ve kapalı portlar arasında sunucu davranışında bir fark olup olmadığını belirlemeye çalışın (portlar 80 ve 443, portlar 11 değilken, genellikle açık portlardır). Özellikle yanıt süresi ve HTTP yanıt kodlarındaki farklılıkları araştırın.
Örneğin, aşağıdaki istek 200 HTTP durum koduyla sonuçlanır (“Tamam” için durum kodu).

https://ornek.example.com/webhook?url=127.0.0.1:80

Aşağıdaki istek 500 HTTP durum koduyla sonuçlanırken (“Dahili Sunucu Hatası” için Durum kodu).

https://ornek.example.com/webhook?url=127.0.0.1:11

SSRF'nin var olduğunu doğrulayabilir ve 80 numaralı bağlantı noktasının açık olduğunu ve 11 numaralı bağlantı noktasının sunucuda kapalı olduğunu tespit ederiz.

Bu yazıyı burada sonlandırıyorum. Yakında youtube kanalıma kısa bir video halinde atarım. Eksiğim yada hatam olduysa AFFOLA. Başka bir yazıda görüşmek üzere..:)

Yorumlar

Bu blogdaki popüler yayınlar

Bazı JavaScript Kütüphaneleri Ve Zafiyetleri

NASA Reflected XSS Write Up

Herşey Bir Tırnakla Başladı