Utilizarea limitelor de rată mal configurate pentru a genera access_token pentru utilizatori, BugBounty 2017 de Mandeep Singh

Mandeep Singh Kapoor

19 aprilie 2017 · 3 min de citire

Deși am avut o experiență destul de grozavă în programele de recompensare a vulnerabilității (sau programele Bug Bounty) în anul 2016, mă așteptam să-mi dezvolt constant cunoștințele.

configurate

Anul 2017 a început cu descoperirea pe care o împărtășesc astăzi. Oricine este interesat de InfoSec cunoaște platforme precum Hackerone și BugCrowd.

Vk.com este unul dintre programele publice de pe hackerone, care mi-a atras atenția în trimestrul al patrulea al anului 2016 și începând cu anul 2017. Așadar, am început să lucrez la aplicațiile lor, VM-urile încărcate, proxy-ul burp cu toate aplicațiile din domeniul său de aplicare de știut toate aplicațiile și punctele finale API din exterior. La petrecerea timpului pentru unele fructe cu agățare redusă și bug-uri convenționale nu s-au dovedit a fi bune în faza inițială pentru aplicațiile vk.

Setup-ul meu: Android pe genymotion cu proxy Burp, iPad Air 2 pentru iOS

După ce am petrecut ceva timp pe webApps, am trecut la Android și iOS. Interesant, am observat că nu toate punctele finale care permit opțiuni pentru „Resetare parolă” sunt mapate la un loc comun.

Ceea ce vreau să spun este că diferitele aplicații VK (Android/iOS/domeniu mobil), toate aveau câteva puncte finale diferite pentru același scop. În general, acest lucru nu este cazul pentru majoritatea aplicațiilor. Punctul final al aplicației Android pentru resetarea parolei indică în mod interesant un api al mail.ru, ca cerere vulnerabilă de mai jos.

La această solicitare specială lipsea o limitare a ratei serverului, dar totuși exista un parametru de semnătură în cerere, care este generat dinamic pentru a preveni modificarea cererii în toate Api, dacă cineva merge să exploreze toate API-urile VK. Cu toate acestea, am decis să trec la o analiză a parametrului semnăturii .