Bug Bounty Öğrenme Serüvenim

1 year ago 70
BOOK THIS SPACE FOR AD
ARTICLE AD

Merhaba, ben Kayra. Çanakkale 18 Mart Üniversitesinde Bilgisayar Mühendisliği 3. sınıf öğrencisiyim. Necdet Yücel hocam vasıtasıyla eski öğrencilerinden olan Mithat Göğebakan hocam ile tanıştım ve bu yolda ilerlememde yardımcı olacaklarını söylediler.

İlk ödevim herhangi bir bug bounty platformu üzerinden bir adet valid bug raporlamaktı. Daha önce herhangi bir valid bug raporlamamıştım, hatta rapor bile yazmamıştım. Bu yüzden ne yapacağımı bilmeyerek hata aramaya başladım. HackerOne ve BugCrowd üzerinden yeni yüklenmiş programlarda, çok temel bilgilerim ile belki şansıma bir tane denk gelir de bulurum düşüncesi ile hata arıyordum. Belli bir arayıştan sonra umudumu kaybederek XSS çalışmaya başlamıştım. XSS’i seçmemin sebebi anlaşılması daha basit olmasıydı.

Daha sonra Mithat Hocam “Nasıl hata arayacağını neden sormadın?” dedi. Henüz yeni tanıştığımız için kendisini pek tanımıyordum. O yüzden, çekinmiştim ve soramamıştım. Bu konuda deneyimsiz olduğumu anlayan Mithat Hocam, daha önce raporlanmış olan bugların raporlarının bulunduğu bir site attı ve buradan 50 adet rapor inceleyip ne aramak istediğime karar vermemi istedi.

Ertesi gün benden istediklerini yapmıştım. XSS ve Open Redirect zaafiyetlerini aramaya karar vermiştim. İletişime geçtiğimde yeni bir ödevim olmuştu. XSS ve Open Redirect zaafiyeti içeren test case’ler yazmam istenmişti. Daha önce böyle bir tecrübem de yoktu ama öğrenmem zor olmadı. Birkaç gün içinde XSS test caselerini yazdım ve Mithat hocama attım.

Böyle bir tepki almıştım, hoşuma gitmişti ve daha da hırslandım. Dediklerini yaptım ve repo’nun son hali şu şekilde:

Bu ödevi de yaptıktan sonra yenisini bekliyordum. Ardından yeni ödevin gelmesi uzun sürmedi. OWASP ZAP kurmamı ve oluşturduğum test caseler üzerinde tarama yapmamı istedi. ZAP’ı seçmemizin sebebi isetarama yaparken requestleri tek tek göstermesiydi. Request’leri tek tek incelememi istedi ve ardından bunlar hakkında konuşacaktık. Taramayı yaptım ve inceledim. Gözlemlerimi bir text dosyasına yazdım. Dosyanın içeriği ise ekteki gibidir.


Öncelikle bütün inputların(butonlar dahil) başına ve sonuna "0W45pz4p" yazarak çıktılarının sitenin herhangi bir yerinde değiştirilmeden kullanılıp kullanılmadığına bakıyor.
Başına ve sonuna yazmasının sebebini bilmiyorum.

Daha sonra "0W45pz4p" yazdığı inputa sırayla payloadlarını uygulamaya başlıyor.
GET parametresine url üzerinden payloadlarını uyguluyor.
POST parametresine ise araya girerek HTTP request message body üzerindeki değişkenlere payloadlarını uyguluyor.
Payloadların çift veya tek tırnakla başlamasının sebebi kaynak kodlarda payload uyguladığımız yerin bir attribute içinde olabilme ihtimalidir.
Payloadlarda harfler hariç bütün özel karakterlere URL encoding işlemi uyguluyor(kontrolleri atlatmak için) ve bazı payloadlarına da script tag'ından önce NULL(%00) karakter koyuyor.
Bunu yapmasının sebebini de tam olarak anlayamadım.
Script kelimesinin harflerini büyük küçük harf karışık yazmasının sebebi kontrolleri atlatmaktır.
onMouseOver ve onerror gibi attributeları kullanmasının nedeni alert fonksiyonunu tetiklemek içindir.
Fakat birkaç yazıda okuduğuma göre alert fonksiyonunun ömrünün sonuna geldiği düşünülüyor ve artık print fonksiyonu öneriliyor.
Bazı payloadlarda da alert fonksiyonu blacklist'e alınabileceği için prompt(alert'in girdi alan hali) fonksiyonunu kullanıyor.
Açıkladığım payloadlar şu şekilde:

javascript%3Aalert%281%29%3B
%3CscrIpt%3Ealert%281%29%3B%3C%2FscRipt%3E
%27%22%3CscrIpt%3Ealert%281%29%3B%3C%2FscRipt%3E
%27%22%00%3CscrIpt%3Ealert%281%29%3B%3C%2FscRipt%3E
%27%3E%3Cimg+src%3Dx+onerror%3Dprompt%28%29%3E
%27+onMouseOver%3D%27alert%281%29%3B

XSS zaafiyet tespitini ise şöyle yaptığını düşünüyorum:

%3CscrIpt%3Ealert%281%29%3B%3C%2FscRipt%3E payloadını inceleyecek olursak URL decode edilmiş hali <scrIpt>alert(1);</scRipt> budur.
Kontrolleri atlatıp alert(1) fonksiyonumuz çalışmayı başarırsa karşımıza '1' uyarısı yazan bir pencere çıkar ve biz tamam'a tıklayana kadar sayfa yüklenmeye devam eder.
Bence program sayfanın yüklenme süresindeki değişimden payloadımızın başarılı olduğunu anlıyor.

Hocama yaptığım analiz dosyasını attım ve cevap alana kadar Open Redirect test case’lerini yapmaya koyuldum. Onun da şimdiki hali şu şekilde:

Artık boş vakitlerimde XSS oyunları çözmeye çalışıyordum. Şu iki xss oyununu bitirdim.

Yeni ödevimi bekliyordum ve beklentimi fazlasıyla karşılayan bir sürü ödevim oldu. Burp Suite ile oluşturduğum case’lere manuel saldırılar yapacağım ve analiz edeceğim, Chrome Debugger nasıl çalışır öğreneceğim, XSS browser gözü ile nasıl görünür, nasıl tespit edilir çok net biliyor olacağım, GitHub’dan seçtiğim 3 XSS tarama tool’u ile case’lerimi tarayacağım ve onların da sonuçlarını analiz edeceğim.

Öncelikle 3 tool seçtim ve case’lerimi tarayarak analizimi bir text dosyasına yazdım.

1)---------------------------------------------------------------------------------------------------
İlk olarak XssPy toolunu analiz edeceğim. "http://127.0.0.1:9090/xss3.php?username=" adresine tarama yapacağım. Programımız öncelikle url üzerindeki tüm subdomainleri tarıyor. Daha sonra urlmizin sonu black listteki uzantılarla bitiyorsa taramaya uygun değil diyor ve diğer url'ye geçiyor. Blacklist şu şekilde:

blacklist = ['.png', '.jpg', '.jpeg', '.mp3', '.mp4', '.avi', '.gif', '.svg', '.pdf']

Eğer blacklist kontrolünü geçtiyse mechanize kütüphanesi ile oluşturduğu browser ile urlmizi açıyor. Daha sonra url üzerindeki formları listeliyor ve hepsine tek tek payloadları uygulamaya başlıyor. Payload listemiz şu şekilde:

payloads = ['<svg "ons>', '" onfocus="alert(1);', 'javascript:alert(1)']

Payloadlarımız herhangi bir encode işlemine veya filtreleme işlemine uğramadan response içinde gözüküyorsa XSS zaafiyetinin varlığı olasıdır. Programımız da bunu kontrol ediyor ve response içinde payloadımızı bulursa "XSS found" mesajını ekrana basıyor.

2)---------------------------------------------------------------------------------------------------
İkinci olarak xssFinder toolunu analiz edeceğim. "http://127.0.0.1:9090/xss3.php?username=" adresine tarama yapacağım. Programımız öncelikle sistemdeki tüm linkleri Crawl ediyor. Crawl ederken dışarıya yönlendiren linkleri de crawl etmesin diye host tabanlı crawling işlemi uyguluyor. Sonra linklerdeki formları buluyor. Bunu yaparken simple_html_dom kütüphanesini kullanıyor.

Bu toolumuz diğerlerinden biraz farklı çalışıyor. Payload aramak yerine XSS saldırılarında kullanılan kritik karakterleri arıyor. Bu kritik karakterler filtrelenmemiş işe yüksek ihtimal XSS zaafiyeti vardır prensibini izliyor. Bu kritik karakterler şu şekilde:

$chars = ["'", '"', "<", ">"];

Bu karakterlerinden sayfa içinde bir sürü bulunabileceği için tararken karakterlere ön ek ekliyor. Böylece response kontrolü yaparken karakteri kendisinin gönderdiğini anlayacak. Daha sonra saldırıya başlıyor ve tüm inputlara payloadını yerleştirerek istekte bulunuyor. Response içerisinde analiz yaparak hangi karakterlerin encode edilip edilmediğine bakıyor. Eğer bizim kritik karakterlerimizden biri veya birileri encode edilmemiş ise XSS vulnerable olduğuna karar veriyor.

3)---------------------------------------------------------------------------------------------------
Üçüncü olarak XssScaner toolunu analiz edeceğim. "http://127.0.0.1:9090/xss3.php?username=" adresine tarama yapacağım. Programımız öncelikle girdiğimiz url'ye crawling ediyor ve 1. incelememizdeki gibi blacklist metodu ile yasaklı uzantılar ile bitip bitmediğini kontrol ediyor. Black list'imiz şöyle:

paichu=['.css','.js?','.gif','.jpg','.png','.swf']

Bu programımızın farkı ise input aramıyor ve tüm saldırıyı URL üzerinden yapıyor. URL kontrolünü tamamladıktan sonra payloadları denemeye başlıyor ve response içinde encode işlemine uğramayan bir payload bulursa url ve işe yarayan payloadı ekrana yazdırıyor. Payloadlar şu şekilde:

xsscases=['"/>"><body onload=alert(1)>','alert(1)','>\'>\"><script>window.a==1?1:alert(a=1)</script>','--></script><script>window.a==1?1:alert(a=1)</script>','\';alert(1);\'','</script><script>alert(1);//']

Ardından Burp ödevini yapmaya karar verdim ve yine bir text dosyasına analizlerimi yazdım. Text dosyası şu şekilde:

Burp ile xss1.php'ye manual saldırı yapacağım.
Öncelikle Burp browserini açıyorum ve xss1.php'ye girip username form'uma bir veri giriyorum.
Daha sonra Burp->Proxy->HTTP history sekmesine giriyorum ve forma veri girdiğim requeste sağ tıklayıp Intruder'a gönderiyorum.
Intruder'ı username'e saldırı yapacak şekilde ayarlıyorum. URL encode ayarını kapatıyorum ve error handling ayarını yapıyorum.
XSS tespiti için ise Grep-Payloads checkbox'ını işaretliyorum.
Grep-Payloads sayesinde xss zaafiyeti olasılığı olan isteklerin yanında True yazacak.

Burp ile open redirect tespitini ise şöyle yaptım.
Test yapacağım site üzerinde burp web browseri ile dolaşıyorum ve daha sonra Target->Site map sekmesine tıklıyorum ve status code'a filtering işlemi uyguluyorum.
3xx olan URL'ler önümde sıralanıyor ve intruder'a gönderiyorum.
Payloadlarımı yerleştiriyorum, encoding'i kapatıyorum ve follow redirections ayarını always yapıyorum.
Response'ları incelediğimde redirect işlemi başarılı olmuş ise open redirection zaafiyeti var tanısını koyuyorum

Bu iki ödevi yaptım. Sıra Chrome Debugger öğrenmekteydi. Bunun için Chrome’un kendi dökümanlarından yararlandım.

Temel düzeyde Chrome Debugger kullanmayı öğrendim. Kullandıkça daha da pekiştirecektim. Breakpoint’ler ekleyerek incelediğimiz kodu daha kolay anlamamızı, payload’ımızın herhangi bir kontrolden geçip geçmediğini anlamamızı ve hangi sink ve source’un kullanıldığını gözlemlememizi sağladığını öğrendim.

Mithat Hocam bir toplantı ayarlayıp Zoom üzerinden görüntülü konuşacağımızı söyledi. Public Firing Range üzerinden örnek bir case çözdü ve nasıl araştırmam gerektiğini bana öğretti. Buradaki bütün caseleri çözmemi istedi. Detaylarını öğrenmem gereken kavramların bir listesini bana verdi ve toplantıyı bitirdik. Kavramlar şu şekilde: Same-Origin Policy, DOM, HTTP Header, Cookie flags, CORS, Sink/Source.

Birkaç gün boyunca ödev verilen kavramlar üzerinde durdum. Hepsinin açıklamasını kendi cümlelerimle yazdığım, localde bir site yaptım. Kodlarını içeren GitHub reposu aşağıdaki linktedir.

Vizelerimin başlamasıyla 1 hafta ara verdim. Ardından caseleri çözemeye devam ettim. Firing Range’de çözdüğüm caseleri de aşağıdaki Repo’ya ekledim.

Read Entire Article