Hiç unutmam, bug bounty işlerine ilk merak saldığım dönemlerde kendimi dünyanın en zeki hacker'ı falan sanıyordum. Bir gün büyük bir e-ticaret platformunda (hadi ona testCompany diyelim) gezinirken, URL'de ?id=123 gibi bir parametre gördüm. "Tamam" dedim, "Sedat, işte o an geldi." Hemen oraya bir tırnak işareti attım, sayfa hata verdi. Gözlerim parladı. Sabaha kadar uğraştım, SQLMap'i arkadan çalıştırdım, tonla payload denedim. En sonunda admin panelinin verilerini çekeceğimden o kadar emindim ki, raporu kafamda yazmaya başlamıştım bile. Meğerse o hata mesajı, veritabanından değil, sistemin kendi özel hata yakalayıcısından geliyormuş ve aslında ortada hiçbir açık yokmuş. O gece hem boşuna uykusuz kalmıştım hem de platformun WAF'ına (Web Application Firewall) yakalanıp IP adresimi banlatmıştım. O gün anladım ki; bug bounty sadece açık bulmak değil, sistemi gerçekten anlamak ve sabırlı olmakmış.
Recon: Samanlıkta İğne Aramak mı, Samanlığı Yakmak mı?
Bug bounty dünyasına girdiğinde herkesin dilinde bir "Recon" (keşif) kelimesi dolanır. Çoğu kişi bunu sadece bir subdomain listesi çıkarmak sanıyor ama işin aslı çok daha derin. Eğer herkesin baktığı yere bakarsan, herkesin bulduğu (ve muhtemelen çoktan raporladığı) 'Duplicate' raporlarla karşılaşırsın. Bizim amacımız, unutulmuş, tozlanmış, geliştiricilerin "Bunu kimse bulamaz" dediği köşelere girmek.
Mesela, sadece subfinder çalıştırıp bırakmak yerine, bulduğun subdomain'lerin üzerinde HTTP probing yapman lazım. Benim favori başlangıç komutlarımdan biri şöyledir:
subfinder -d testCompany.com -silent | httpx -title -tech-detect -status-code
Bu komut sana sadece hangi domainlerin yaşadığını değil, üzerinde ne çalıştığını da söyler. Eğer bir yerde PHP 5.4 veya Jira 7.x gibi bir şeyler görüyorsan, işte orası senin oyun alanındır. Ama asıl hazine, JavaScript dosyalarının içinde saklıdır. Geliştiriciler bazen o JS dosyalarının içine öyle API endpoint'leri veya test credential'ları bırakıyorlar ki, "Bunu gerçekten buraya mı koymuşlar?" diye ekrana bakakalıyorsun.
LinkFinder veya benzeri araçlarla bu dosyaları taramak hayat kurtarır. Bir keresinde bir JS dosyasının içindeki yorum satırından, firmanın dahili staging ortamına giden bir yolu bulmuştum. Unutma, en büyük açıklar genelde en çok göz önünde olan ama kimsenin dikkatlice bakmadığı yerlerdedir.
Payloadların Gizli Dünyası ve WAF Dansı
Bir açık bulduğunu hissettiğinde (diyelim ki bir XSS veya SQLi şüphesi var), hemen alert(1) veya union select diye dalarsan geçmiş olsun, WAF seni kapının önüne koyar. Modern sistemler artık çok akıllı. Artık daha 'zarif' payloadlar kullanmamız gerekiyor.
Örneğin, bir input alanında script etiketlerinin engellendiğini gördün. Hemen pes etmek yok. HTML5'in nimetlerinden faydalanmak lazım. Şöyle bir şey denediğini düşün:
<details open ontoggle="confirm(document.domain)">
Veya daha karmaşık bir yapı gerekiyorsa, SVG dosyaları içine gömülü payloadlar her zaman favorimdir. Bir görsel yükleme alanına şu içeriğe sahip bir .svg dosyası yüklemeyi dene:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
<rect width="300" height="100" style="fill:rgb(0,0,255);stroke-width:3;stroke:rgb(0,0,0)" />
<script type="text/javascript">
alert('Sedat was here: ' + document.cookie);
</script>
</svg>
Eğer sistem bu SVG'yi render ediyorsa ve içerideki script'i temizlemiyorsa (sanitization), tebrikler, artık bir Stored XSS'in var. Tabii bunu yaparken testCompany çalışanlarının çerezlerini (cookie) çalmaya çalışma, sadece kendi session'ında kanıtla. Etik kurallar, bizim bu piyasadaki imzamızdır.
IDOR: Mantık Hatalarının Kralı
Teknik açıklar (XSS, SQLi, SSRF) çok havalı duruyor, kabul ediyorum. Ama bug bounty listelerinde en çok parayı ve "P1" dediğimiz kritik seviyeyi genelde IDOR (Insecure Direct Object Reference) açıklıarı getirir. Çünkü bunlar otomatize araçların bulması en zor olan açıklar. Bir aracın "Bu kullanıcı, şu kullanıcının faturasını görmemeli" mantığını anlaması zordur.
Diyelim ki bir profil düzenleme sayfasındasın. URL veya Request Body şöyle görünüyor:
POST /api/v1/updateUserProfile HTTP/1.1
Host: testCompany.com
Content-Type: application/json
Authorization: Bearer <your_token>
{
"user_id": "1005",
"email": "[email protected]",
"bio": "Bug hunter"
}
Buradaki user_id değerini 1004 yaptığında, eğer sistem 1004 numaralı kullanıcının bilgilerini senin verdiğin verilerle güncelliyorsa, bingo! Bu bir IDOR'dur.
Bunu test ederken her zaman iki farklı hesap kullan. Birinci hesapla (Attacker) ikinci hesabın (Victim) verilerine erişmeye veya onları değiştirmeye çalış. Burp Suite'in "Authorize" eklentisi bu iş için biçilmiş kaftandır. Sen gezersin, o arkada "Acaba bu isteği düşük yetkili kullanıcıyla atsam ne olur?" diye dener.
Rapor Yazma Sanatı: Hacker mı Olmak İstiyorsun Yoksa Yazar mı?
Bak dostum, istersen dünyanın en büyük açığını bul, eğer onu düzgün raporlayamazsan o açık "Informative" veya "N/A" damgasını yer, sen de sinir krizleri geçirirsin. Şirketteki triage ekibi (raporu ilk karşılayanlar) günde yüzlerce saçma sapan rapor okuyor. Senin raporun net, anlaşılır ve tekrar edilebilir (reproducible) olmalı.
Raporunda şu adımları asla atlama:
- Description: Açık nedir, neden tehlikelidir? (Kısa ve öz).
- Impact: Bu açıkla bir saldırgan ne yapabilir? "Şirketin tüm kullanıcı verilerini sızdırabilirim" demekle "XSS var" demek arasında dağlar kadar fark var.
- Steps to Reproduce: Adım adım, bir çocuğa anlatır gibi anlat.
testCompany.com/loginadresine git.
- Şu payload'u şu alana yapıştır.
- 'Kaydet' butonuna bas ve çıkan alert'i gör.
- Remediation: Şirkete bu açığı nasıl kapatacaklarını söyle. Onlara iş yükü değil, çözüm üret.
Mental Sağlık: "Duplicate" Alınca Masayı Dağıtmamak
Bug bounty dünyasının en karanlık yüzü o meşhur "Duplicate" (Mükerrer) cevabıdır. Haftalarca uğraşırsın, tam "Hah, buldum!" dersin, raporu gönderirsin ve 5 dakika sonra bir bildirim gelir: "Bu açık zaten başka bir araştırmacı tarafından bildirildi."
O an insanın içinden her şeyi bırakıp balıkçı kasabasına yerleşmek geliyor, biliyorum. Ama bu işin kuralı bu. İlk bulan kazanır. Bunu aşmanın yolu, daha az kişinin baktığı, daha karmaşık iş mantığı (business logic) gerektiren yerlere odaklanmak. Otomatize scriptlerin ulaşamadığı, 5-6 adımlık işlem akışlarının arasına saklanmış hataları ara.
Son Düzlükte Birkaç Tavsiye
Yolun başındaysan veya bir süredir yerinde sayıyorsan şu birkaç şeyi unutma:
- Scope Dışına Çıkma: Programın belirlediği sınırlar dışına çıkarsan ödül almayı bırak, başın belaya bile girebilir.
- Not Tut: Hangi domainde ne denedin, hangi parametre garip davrandı? Hepsini not al. CherryTree veya Notion bu iş için harikadır.
- Topluluğu Takip Et: Twitter (X) üzerinde #bugbountytips tag'ini takip et. İnanılmaz yaratıcı payloadlar ve teknikler paylaşılıyor.
- Sabırlı Ol: İlk ödülün 1 ay sonra da gelebilir, 6 ay sonra da. Önemli olan o süreçte öğrendiğin teknik detaylar.
Bug bounty bir sprint değil, bir maraton. Kondisyonunu iyi ayarla. Bir sonraki sızma denemende görüşmek üzere, proxy'n açık, latency'n düşük olsun!