Sunucu tarafı isteği amplifikasyonu için Kısa SSRF, avukatlıklar en etkili web güvenlik açıklarından biridir. Hedefler üzerinde daha az yaygın olarak bulunsa da, OWASP Top 10 2021 merdiveni en son yer (A10) puanlamada gerçekleşirler. SSRF güvenlik açıklarının, kötü aktörlere tamamen yeni, genellikle içsel bir altyapı açabilecekleri için önemli bir etkisi olduğu bilinmektedir. Genellikle saldırganların müşteri verileri (PII dahil) ve yapılandırma dosyaları gibi hassas verileri veya sistem dosyalarını okumasına veya değiştirmesine izin verir, ancak şiddetli durumlarda, kritik üçüncü taraf hizmetlerde (AWS ve GCP gibi) değişikliklerin getirilmesine de izin verir.
Bu makalede, SSRF güvenlik açıklarının nasıl tanımlanacağınızı ve bunları nasıl kullanabileceğinizi de ele alacağız. Ayrıca bazı gelişmiş vakaları da ele alacağız. Önce SSRF güvenlik açıklarının ne olduğunu tanımlamakla başlayalım.
SSRF güvenlik açıkları, tasarlanmamış kullanıcı girişi, örneğin bir HTTP isteği hazırlamaktan sorumlu bir işlev veya bileşene iletildiğinde ortaya çıkar. Bu, kullanıcının sunucu adına harici veya dahili bir kaynak istemesini sağlar.
Bağlam ve savunmasız bileşene bağlı olarak, bu genellikle harici veya dahili bir kaynak talep etmeye (API uç noktası gibi), istemci e -posta sunucusu (SMTP destekleniyorsa) adına bir e -posta göndermeye ve hatta dahili sistem yapılandırma dosyalarını okumaya yol açabilir.
Bunun yerine bir videoyu mı tercih ediyorsunuz? SSRF’yi 100 saniyede izleyin!
SSRF güvenlik açıkları, güvenli olmayan kullanıcı girişi, giden bir bağlantı kurmaktan sorumlu bir işlev veya bileşende doğrudan kullanıldığında (HTTP isteği gibi) ortaya çıkar. Bu kriterleri karşılayan herhangi bir özellik veya işlevi aramalıyız.
İşte genellikle sunucu tarafı istek tazminlerine karşı savunmasız birkaç ortak özellik:
Profil görüntü yükleyicileri (genellikle kullanıcıların bir URL belirtmesine izin verir)
WebHook Hizmetleri ve Harici Veri İşlemcileri
PDF jeneratörleri
Sınırsız dosya yüklemeleri (örneğin bir XML dosyası üzerinden)
CORS vekilleri (CORS tarayıcı kısıtlamalarını atlamak için kullanılır)
İstek başlık işleme (ana bilgisayar veya x-forward için istek başlığı gibi)
SSRF güvenlik açıkları bulma şansınızı artırmak için kapsamlı içerik keşfi yapmalısınız. Proxy Interceptor’unuzu açıp ilginç HTTP isteklerini inceleyerek web uygulamasına göz atarak bunu yapabilirsiniz.
UÇ! Bir istekte herhangi bir URL ile eşleşecek bir eşleşme ve değiştirme kuralı ayarlayın ve kontrol ettiğiniz kanarya jeton / URL’nizle değiştirin!
Proxy Interceptor Eşleştirme ve Değiştir Kuralı
Başka bir ipucu JavaScript dosyalarını asla zayıflatmaktır. JavaScript dosyaları, bazı bir sonraki SSRF güvenlik açığınızı bulmanıza yardımcı olabilecek yeni uygulama yollarını ve API uç noktalarını numaralandırmaya yardımcı olmak için böcek ödül avcılarının altın madenidir:
Artık SSRF güvenlik açıklarının ne olduğunu ve bunları nerede bulacağımızı bildiğimize göre, bunları nasıl kullanabileceğimizi bazı yollara inceleyelim.
Aşağıdaki savunmasız kod snippet’ine bir göz atın:
Burada birkaç sorun bulabiliriz. Her şeyden önce, burada içerik türü doğrulama yapılmadı. Bu işlev, bir kullanıcının profil resmini almaktan sorumludur, burada yalnızca bir görüntü yanıtı türü kabul edilmelidir. Burada başka bir sorun, neye ulaşabileceğimiz konusunda bir doğrulama yoktur, yani sunucu adına dahili kaynaklar talep edebiliriz.
Bu durumda, basitçe ayarlayabiliriz imgURL Gövde parametresi LocalHost gibi herhangi bir URL için ve tam yanıtı alın (kaydedilen görüntüyü açarak):
POST /api/v2/profile-img HTTP/2
Host: api.example.com
Content-Type: application/json
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.3
{
"imgURL": "http://localhost/"
}Karşılaşacağınız çoğu hedef, girdinizi bir şekilde doğrular ve dahili hizmetlere ulaşmanızı veya talep etmenize izin verilen herhangi bir kaynak istemenizi önlemeye çalışır. Geliştiricilerin harekete geçmesinin bir yolu, verilen URL’nin ana bilgisayar adını doğrulamak ve bir izin listesi veya beyaz listeye göre eşleştirmektir.
Bu kısıtlamaları atlayabilmemizin 3 ana yolu vardır:
Doğrulama için gevşek bir şekilde yerleştirilmiş bir Regex deseni kullanılırsa, eşleşerek atlayabiliriz.
İsteği almaktan sorumlu ana işlev de yönlendirmeleri takip edecek şekilde yapılandırılmışsa, sunucularımıza gelen herhangi bir trafiği erişmek istediğimiz kaynağa yönlendirebiliriz.
Ve DNS Rebinding aracılığıyla (bu makalenin ilerleyen dönemlerinde bu sömürü tekniği hakkında daha fazla bilgi)
Localhost’a erişimi önlemek için yeni bir doğrulama kuralının eklendiği önceki savunmasız kod snippet örneğine daha yakından bakalım.
Bu durumda, kısıtlamaları yukarıda tarif ettiğimiz 3 şekilde atlayabiliriz. Saldırgan kontrollü sunucumuza ulaşmak için aşağıdaki bypass’ı kullanabiliriz:
https://assets.example.com.attacker.com/Ve savunmasız bileşen de yönlendirmeleri takip edecek şekilde ayarlandığından, tüm trafiği yeniden yönlendirmek için sunucumuzu ayarlayabiliriz. http://localhost Aksi takdirde kısıtlanmış herhangi bir dahili hizmete ulaşmak için.
İşte daha katı filtreler ve desenlerden kaçmaya yardımcı olacak birkaç baypas daha:
.{CANARY_TOKEN}
@{CANARY_TOKEN}
example.com.{CANARY_TOKEN}
example.com@{CANARY_TOKEN}
example.comx.{CANARY_TOKEN}
{CANARY_TOKEN}#example.com
{CANARY_TOKEN}?example.com
{CANARY_TOKEN}#@example.com
{CANARY_TOKEN}?@example.com
127.0.0.1.nip.io
example.com.127.0.0.1.nip.io
127.1
localhost.me“{Canary_token}” ı kontrollü ana bilgisayar adınızla değiştirin ve “Örnek.com” u beyaz listeye alınmış bir hedef ana bilgisayarla değiştirin.
UÇ! Bazen Beyaz listeli ana bilgisayarlarda tanımlanan açık URL yönlendirme güvenlik açıkları, yukarıdaki örnekte gördüğümüz gibi kısıtlamaları atlamak için kullanılabilir!
Yük filtrelere daha fazla baypas bulmak için kullanabileceğiniz gelişmiş SSRF yükleri olan bir depodur:
https://github.com/swisskyrepo/payloadsallthethings/tree/master/server%20side%20Request%20Forgery
Çoğu hedef, yalnızca bir yol belirtmenize izin vererek girdinizi sınırlamaya çalışır. Bununla birlikte, bazı durumlarda hala bir protokol belirleyebilir ve savunmasız bileşene belirtilen harici kaynağımızı talep etmesini isteyebiliriz.
İşte birkaç baypas:
//{CANARY_TOKEN}
\\{CANARY_TOKEN}
////{CANARY_TOKEN}
\\\\{CANARY_TOKEN}
http:{CANARY_TOKEN}
https:{CANARY_TOKEN}
/%00/{CANARY_TOKEN}
/%0A/{CANARY_TOKEN}
/%OD/{CANARY_TOKEN}
/%09/{CANARY_TOKEN}“{Canary_token}” i kontrollü ana bilgisayar adınızla değiştirin.
Hedefleriniz ayrıca kullanıcı girişine dayalı PDF’ler üretiyor olabilir, tüm ayrıntılarınızla ödeme yaptıktan sonra bir fatura yayınlayan bir e-ticaret web mağazasını düşünün. Veya başarılı bir uygulama içi işlemden sonra herhangi bir onay makbuzu.
Bu PDF jeneratörlerinin bazıları, HTML kodunu bir PDF dosyasına dönüştüren bir paket kullanır. Ve tasarlanmamış girişiniz belgeye dahil edilmişse, HTML etiketlerini oluşturabilir ve PDF dosyasına temel içerik enjekte edebilirsiniz.
Bu basit HTML enjeksiyonunu, bir IFrame-TAG veya dışarı çıkacak basit bir JavaScript işlevi enjekte ederek (PDF dosyasını oluşturan hizmet adına) bir IFrame-TAG veya basit bir JavaScript işlevi enjekte ederek tam olarak okunan bir sunucu tarafı isteği ambalajından yararlanabiliriz.
İşte bir kavram kanıtı nasıl olurdu:
Veya basit bir JavaScript işlevi kullanmak:
UÇ! Bazı PDF jeneratörleri, sanal alan güvenliği etkin ve kök ayrıcalıkları olmayan krom ağ tarayıcısına güvenir. Bu genellikle uzaktan kod yürütülmesine daha fazla yükseltilebilir!
İkinci dereceden SSRF’ler genellikle tespit etmek için daha zordur, ancak sömürü tekniği aynı kalır. Bununla birlikte, bu durumda, tasarlanmamış girdiniz kaydedilir ve daha sonra alınır veya HTTP isteğini yapmaktan sorumlu ikinci (dahili) bir API uç noktasına veya bileşene aktarılır.
Birden fazla API’den (harici ve iç-bakan olanlar) oluşan modern web uygulamalarında genellikle mevcut olan aşağıdaki örneğe bir göz atın:
Yukarıdaki çizimden fark edebileceğiniz gibi, bir saldırgan, dahili API’nın arayacağı yeni bir ana bilgisayar belirleyebilir. Saldırganın hassas verileri görüntülemesine veya yetkisiz değişiklikler yapmasına izin vereceği için, içe dönük API’da başka bir yetkilendirme kontrolü gerçekleştirilmezse bu sert olabilir.
Kör SSRF güvenlik açıkları SSRF’lerdir, ancak sınırlı olmayan yanıt öğeleri size geri dönmemiştir. Bu, sömürüyü önemli ölçüde zorlaştırır. Örneğin daha fazla bilgi edinmek için kör bir SSRF güvenlik açığından yararlanabileceğiniz durumlar vardır.
Yanıtın bir kısmı size (HTTP durum kodu gibi) döndürülürse veya mevcut ana bilgisayarlar ve mevcut olmayanlar arasında belirgin bir zaman gecikmesi olması durumunda, bir saldırgan tüm özel IP’lerde 65K ağ bağlantı noktalarına bir HTTP isteği yaparak bir dahili ağı numaralandırabilir. Bu taramadan elde edilen bilgiler ileri saldırılarda kullanılabilir.
HTTP bağlantıları yapmaktan sorumlu olan temel kütüphane veya paket de diğer protokolleri destekliyorsa, şunlar mümkün olabilir:
UÇ! AssetNote’un halka açık bir GitHub deposu var Kör SSRF güvenlik açıklarını daha da artırmak için kullanılabilecek birkaç zincire sahip!
Hedeflerinizden bazıları bir adım daha ileri gidecek ve ana bilgisayarı bir izin listesine karşı doğrulamak için bir DNS sorgusu yapacak. Bununla birlikte, savunmasız bileşen Toctou’ya karşı savunmasızsa (çek zamanı, kullanım zamanı), bu doğrulama kontrolünü DNS Rebinding aracılığıyla atlayabiliriz.
Yukarıdaki kod snippet’inde, ana bilgisayarı doğrulamak için bir DNS sorgusu yaptığını görebiliriz ve geçerli ise, başka bir DNS sorgusunu yapan bir sonraki işleve geçer (tam HTTP isteğini yapmadan önce). Bu, kendi özel DNS sunucumuzu ayarlamamıza ve yapılan ilk DNS sorgusunda izin verilen bir ana bilgisayar adıyla yanıt vermemize ve daha sonra gelecekteki DNS sorgularında başka bir ana bilgisayar adıyla yanıt vermemize olanak tanır. Bu, belirli kısıtlamaları atlamamıza izin verecektir.
SSRF güvenlik açıklarının tespit edilmesi daha zordur, ancak genellikle saldırganların yetkisiz hizmetlere veya bileşenlere erişmesine izin veren önemli bir etki taşır. SSRF güvenlik açıkları için hedeflerinizi, özellikle bu makalede belirtilen tüm sömürü yöntemlerine karşı test etmek her zaman iyi bir fikirdir.
Yani, SSRF güvenlik açıkları hakkında yeni bir şeyler öğrendiniz … şu anda, becerilerinizi test etme zamanı! Intigriti’deki 70+ genel böcek ödül programlarımıza göz atın, diğer birçok avcı zaten Intigriti’de SSRF güvenlik açıklarını buldu ve bildirdi ve kim bilir, belki bugün bizimle bir ödül kazanmanız için bir sonraki!
Bugün Intigriti’de hacklemeye başlayın