- Path normalization vuln
- Response header injection
- Sunucu’nun bir isteği olması lazım, sunucu’nun bir kaynağa ürettiği istekten bahsediyor. Server’ın client gibi davrandığı işlerin tamamı.
- Third party bir API’a ulaşıyor olabilir, senden alınan bir URL’den erişim sağlıyor olabilir, birtakım farklı servislere erişim sağlıyor olabilir.
- SSRF konusunda, sunucu bir adrese HTTP talebi göndermekte sen de bu HTTP talebini uygulamanın kendi ağında bulunan sistemlere yönlendirtmesini yapmaya çalışıyoruz.
- Eğer bu uygulama bir Cloud servisi ise, AWS, Azure, Google cloud gibi; AWS metadata curl gibi bir olay karşına çıkıyor.
- Cloud servislerinin içerisindeki her instance’ın erişebildiği sabit bir endpoint bulunmaktadır.
- Bu adrese request oluşturduğun zaman AWS içeriden sana cevap veriyor. İçerideki bilgileri dızlayabiliyorsun yani.
- Service account tokenlarını elde edebilirsen, diğer instance’ları queryleyebiliyorsun.
- Sunucu, kullanıcıdan aldığı inputu valide eder ki onun içerideki servislerine erişemesin diye. Burada da 2 yaklaşım söz konusu:
- Blacklisting
- Whitelisting
- Uygulamanın external bir resource’a erişimini abuse ediyoruz.
- Blind SSRF: External resource dan gelen cevabı uygulama gitti DB’e ya da diske kaydetti. Sana sorgunun cevabını göstermiyor. Alıyor doğrulama yapıyor bir şey yapıyordur ya da web-hook gibi triggerdır. Alıp isteği atıyor o kadar işi bu.
- Ya da belli condition altında tetiklenen kurallar belirlenmiştir.
- Millet bunu RCE’ye çevirmek için uğraşıyor ama RCE ye çevirmek için başka bir zaafiyete de ihtiyaç duyuluyor.
- XXE gibi external bir soruce’a isteği attırabiliyorsun yani kafana otursun. XXE zaafiyetinde de SSRF ve genellikle Blind SSRF’e dönen bir hikaye oluşuyor.
- Adam koyar bir dockera(HARDENING YAPMIŞTIR) senden aldığı URL’i ve docker da internete istediği gibi çıkıyordur ama iç ağıyla iletişim kuramıyordur öyle kalırsın. Ama burda da farklı atak vektörleri de ortaya çıkabiliyor. HTTP Curl gibi uygulamanın kendisi içerisinde blduğun memory corruption zaafiyetlerini de sömürebilmektesin.
- Mesela başka bir zafiyeti kullanarak gittin bu uygulamanın localdeki IP adresini buldun, 10.0.10.2:x/ bu IP adresi üstünde hangi portlar var diye kontrol et, intruder ile daya bunu. Networkün içerisinde de yapabilirsin bunu.
- XXE zafiyeti ile networkte bulunan bir ElasticSearch tespit etmiş, direkt protundan cevabı almış.
- Bir üründe Check Stock yapınca, uygulama bir URL adresine HTTP isteği gönderecek. Arkadaki backend bir proxy gibi davranıyor, senden bir istek alıyor ve onu başka bir yere yönlendirmesini yapıyor.
- Uygulamanın üstündeki localhost’a yönlendirtme yapmaya çalışmaktayız.
- localhost yerine istediğimiz herhangi bir şeyi yazabiliriz.
- Bu uygulamanın üstünde çalışan bir ElasticSearch olsaydı tüm endpointlerine gidebilirdin. Ama POST metodu istiyor olabilir bu endpointler. Sunucu da senin verdiğin inputu GET methodu olarak yolluyor olabilir. Bu tür limitasyonlar ortaya çıkıyor.
- 192.168.0.x:8080/admin ip ve portunda bir açık varmış. X ne ise onu tespit edip ona göre çözeceksin.
- Referrer headerı’ı üstünde bir zafiyet varmış. Gidip oraya google.com yazdığında istek gidiyor 200 OK dönüyor. Sonra bunu collaborator ile deneyince çıkan DNS talebini tespit edebiliyoruz. DNS’i çözmeye çalışıyor yani.
- HTTP istediğimiz adrese çıkıyor ama cevap sana dönmüyor.
-
Bu uygulama sunucusu 302 Redirection gördüğünde bunu takip ediyor mu etmiyor mu böyle bir hikaye var.
-
Application aldığı URL üstünde validation yapıyor, ama validation’ı hangi katmanda yapmakta ne şekilde yapmakta? Localhost’a erişim sağlayamazsın diyor mesela sen de gidip burada Open Redirect zafiyeti tespit ediyoruz.
-
Uygulamanın kendi URL’inde bir adrese gittiğinde senin kontrol edebildiğin bir yere Redirection yapıyor. Bu durumda redirectionlarda validation sağlıyor mu???
-
Adam artık akıllanmış URL almıyor, sadece endpoint alıyor ve ben oraya giderim diyor.
-
Kendi ana sayfasına git diyorsun yani / koy.
-
/afasfashf Not found
-
Bu URL’lerin birinde zafiyet bulsak, bu zafiyet de Open Redirection zafiyeti sağlasa.
- Login sayfasını denedi, giriş yaparak redirection bakıyor sanırım
- Ürünlerde “next product” diye bir buton varmış. ProductId’sine redirection sağlıyor. Bu bilgiyi de path’den alıyor, bu path üstünde HTTP isteği sallayabiliriz.
- Gereksiz parametreleri silmek gerekiyor. “?currentProductId” gibi
- Sonra stockApi parametresi üstüne yazıcaz bunu. Bu path, redirection yapıyor ama adam da bunu kontrol etmiyor(validation sağlamıyor).
- stockApi bunu blacklisting yapıyor olsaydı “nexProduct”ı validation yapıyor olsaydı, giderdi şu istek üstünde uğraşırmış. Admin kısmında new line edip header injection yapabilirsin.
- Bu olay validation’ın yapısına bağlı.
- Response header injection
- Burp’ün “Collaborator Everywhere” diye bir extensionu varmış. Her giden requesti manipüle ediyor, tüm olası headerın içine yazıyor. “Guess Header”ı vuruyorsun aga.
- Elle buldu, Referer alanına yazdı bunu. Sonra Collaborator’den baktı gelen HTTP isteğe User-agent Mozilla olduğunu gördü. İçeride Command line’dan chrome çalıştırıyor olabilir. Host alanına çünkü collaborator adresi gelmiş.
- asd:afas@collaborator yazdı gelen isteğe baktı sonra, iplemediğini gördü.
- Shellshocku görünce ayıktı, User-agent’ı bizden alıyor. eben yazınca collab. gelende de eben yazıyordu.
- Böyle bir şey yaptı, id yerine whoami.
- Port da belli değil ama hayırlısı. Multi-step exploitation yapacaaaaaaaaz.
- Uygulama, Referer’dan aldığı URL’e HTTP talebi gönderirken User-agent kısmına da senden aldığını yazıyor. Tüm iç networkü scan edecek. İç networkteki bir web server cgi, shellschock zafiyeti var.
- Shellshock zafiyeti, User-agent üzerinde cgi larda tetiklenebilen bir zafiyet.
- whoami komutunu bir subdomain olarak dışarı taşıyor.
- curl, wget komutları ile de yapılabilir
- Önce zafiyet hangi makinede onu tespit edicez. curl,wget gibi komutların full pathini yazmak gerekiyor olabilir. O pathi tespit etmeye çalış collab. ile.
- Portu :8080 yaptı oldu 🙂
