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 .

GET/fcgi-bin/attempt? Application_id = d139545f-c5e4-45cd-93d1-d67ff8045c08 & code = 1234 & code_source = USER_INPUT & id = cd7feddbfbaa12eabecfc7434bfe255a & internal = verify & language = en_US & phone = 919999 e473e0ead308d0537204XXXXXXXX Conexiune HTTP/1.1: Închidere

User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.4.4; Telefon personalizat - 4.4.4 - API 19–768x1280 Build/KTU84P).

Rețineți semnătura parametrului = „“ .

Analizând parametrul Semnătură, prefer să încep prin a face rapid o len (semnătură) pe un prompt python care îmi dă 32. Nu, nu este MD5, așa cum ne putem gândi chiar la început, dar ce se întâmplă dacă folosesc o sare simplă cu MD5 ?

După ce am analizat în continuare documentația API, am constatat că parametrul de semnătură pentru majoritatea cererilor de pe API-urile VK sunt generate de o procedură standard care este un MD5 (param 1 + param 2 + - - param (n-1) + param n + client_secret), unde client_secret poate fi văzut în text simplu în multe apeluri API.

Dar, interesant, această cerere nu a generat semnătura în același mod, totuși a fost încă un hash MD5.

O limită a ratei laterale a serverului lipsă (care este un răspuns 429) nu a fost pusă în aplicare în jurul acestei cereri. Redând cererea cu un număr diferit de valori de cod, cererea care conține cod corect returnează access_token pentru utilizator .

Răspuns (care conține access_token):

HTTP/1.1 200 OK Server: nginx/1.9.2 Data: Joi, 02 Feb 2017 00:12:09 GMT Content-Type: application/json; charset = utf-8 Content-Length: 367 Conexiune: închisă, "modified_phone_number": "919999xxxx", "token": "3eeA28mbA-yyDC-11xx-B7D9-B9C3968CA444", "token_expiration_time": 3600, "app_check_id": "hdwWPQ8QXXXX + rs + w6 + 2J + 7C57rRAxxxxxephrtBVk ="

Raport rezolvat și recompensă de 400 USD acordat. (ma asteptam mai mare).