İlk Bug Bounty Mükafatımı Microsoft-da Necə Qazandım? (One-Click Account Takeover)

Bug bounty ilə məşğul olmağa başlayanda çox yerdə gördüyüm cümlələrdən biri belə idi: > "Open Redirect kritik deyil." Bir müddət sonra Microsoft Create Portalında araşdırma apararkən bunun hər zaman doğru olmadığını göstərən bir boşluqla rastlaşdım. Normalda Open Redirect istifadəçini başqa bir sayta yönləndirməyə imkan verən zəiflikdir və əksər hallarda aşağı riskli hesab olunur. Ancaq təhlükəsizlikdə hər şey zəifliyin adından yox, onun real təsirindən (impact) asılıdır. Bu halda problem sadəcə redirect deyildi. Araşdırma zamanı fallbackUrl parametrinin lazımi şəkildə yoxlanılmadığını gördüm. İstifadəçi aşağıdakı kimi hazırlanmış bir linkə daxil olduqda: ```text https://create.microsoft.com/en-us/launch-app?fallbackUrl=https://zeynalxan.com ``` sistem istifadəçini avtomatik olaraq mənim nəzarətimdə olan domenə yönləndirirdi. İlk baxışda bu, adi bir Open Redirect kimi görünürdü. Lakin request-ləri analiz etdikcə daha ciddi bir problem ortaya çıxdı. Yönləndirmə prosesi zamanı istifadəçiyə aid autentifikasiya məlumatları (auth token) də mənim serverimə ötürülürdü. Nəticədə serverə gələn request konseptual olaraq belə görünürdü: ```text GET /?authToken=******** HTTP/1.1 Host: zeynalxan.com ``` və ya ```text https://zeynalxan.com/?authToken=******** ``` Bu isə o demək idi ki, hücumçu sadəcə istifadəçini hazırlanmış bir linkə klik etməyə inandırmaqla həmin tokeni əldə edə bilərdi. Token etibarlı olduğu müddətdə isə istifadəçinin sessiyasından istifadə etmək və nəticədə hesabı ələ keçirmək mümkün idi. Yəni zəiflik texniki olaraq Open Redirect olsa da, onun real təsiri One-Click Account Takeover idi. Bu hadisə mənə bir daha göstərdi ki, bug bounty-də zəifliyin adı yox, onun real təsiri qiymətləndirilir. Eyni zəiflik bir tətbiqdə yalnız "Informational" hesab oluna bilər, başqa bir tətbiqdə isə "High" və ya hətta "Critical" təsir yarada bilər. Məhz buna görə hər tapdığınız boşluğu yalnız CVSS və ya adına görə deyil, yaratdığı real risk baxımından analiz etmək vacibdir. Boşluğu Microsoft-a report etdim. Timeline * Report edildi: 2 iyul 2024 * Eyni gün Microsoft tərəfindən təsdiqləndi * Patch hazırlanmağa başladı: 16 iyul 2024 * Tam düzəldildi: 27 iyul 2024 * Bounty: $$$$ Nəticədə report P2 (High) olaraq qiymətləndirildi. Bu hadisədən çıxardığım nəticə Bug bounty-də bəzən ən böyük fərqi mürəkkəb exploitlər yox, sadə görünən funksiyaların arxasında gizlənən məntiq yaradır. Bug axtararkən zəifliyin adına fokuslanmaq əvəzinə özünüzə belə suallar verin: * Bu boşluqdan real hücum ssenarisində necə istifadə oluna bilər? * İstifadəçiyə və ya sistemə hansı təsiri var? * Başqa hansı zəifliklə birlikdə zəncir (chain) yaratmaq mümkündür? Çox vaxt ən dəyərli reportlar da məhz bu sualların cavabından yaranır. Sonda kiçik bir qeyd: Bu report mənim bug bounty sahəsində qazandığım ilk pul mükafatı idi. Ondan əvvəl VDP proqramlarında bir neçə qəbul olunmuş reportum olsa da, mükafat aldığım ilk report məhz bu oldu. Bug bounty-də bəzən ən böyük fərqi mürəkkəb exploitlər yox, sadə görünən funksiyaların arxasındakı məntiq yaradır. Bug axtararkən zəifliyin adına fokuslanmaq əvəzinə onun real təsirini anlamağa çalışın. Bəzən ən maraqlı buglar da məhz belə tapılır. Əgər bu paylaşım faydalı olarsa, gələcəkdə digər Bug Bounty təcrübələrimi, maraqlı zəiflikləri və reportların arxasında duran düşüncə prosesini də paylaşmağı planlaşdırıram. Ümid edirəm ki, xüsusilə bu sahəyə yeni başlayanlar üçün faydalı olar.