hos Synack nyder vi virkelig store sårbarheder, hvad enten det er på nettet, mobil, vært eller endda i helt uhyrlige enheder og systemer (satellit hacking nogen?). Men vi holder altid de store resultater, som vi og SRT har gjort for vores kunder fortrolige. Så selvom dette ikke vil være et indlæg om en stor vuln hos en Synack-kunde, dækker det den nøjagtige type ting, vi ser ugentligt eller undertiden dagligt: en sårbarhed i et system med millioner af brugere, der fører til et komplet kompromis med systemsikkerhed.

jeg har for nylig fundet en sårbarhed i Microsofts Live.com godkendelsessystem, som, hvis du har en konto med en Microsoft-tjeneste, sandsynligvis ville have påvirket dig. Dette indlæg beskriver de fulde detaljer om sårbarheden nu, at Microsoft har lappet problemet.

introduktion

den gennemsnitlige persons forståelse af computersikkerhed har altid været ret begrænset. Tilbage på dagen, hvis nogen hørte, at du var involveret i computersikkerhed, ville standardspørgsmålet være “kan du hacke min Hotmail”, eller oftere, “kan du hacke min vens Hotmail”. Jeg formoder, at folk stadig brugte Yahoo mail, og Microsoft havde endnu ikke erhvervet Hotmail, men det er lidt for langt tilbage! Uundgåeligt vil du enten foreslå, at personen bare gætter personens spørgsmål om nulstilling af adgangskode, eller installer Sub7. Faktisk hacking Hotmail var bundet til at være for svært, for ikke at nævne helt ulovligt.

informationssikkerhedsverdenen har ændret sig meget i de sidste par år, og i modsætning til tidligere år opfordrer Microsoft nu fuldt ud sikkerhedsforskere til at forsøge at “hacke Hotmail”. Selvfølgelig er Hotmail blevet omdannet til Outlook.med, og i disse dage vil alle vide, om du kan hacke deres Facebook, men det er ved siden af punktet.

Microsoft Online Services bounty-programmet blev for nylig opdateret til at omfatte” Microsoft-konto ” som et mål, som dybest set er login-systemerne hostet på hvert af disse domæner:
– login.windows.net
– login.microsoftonline.com
– login.live.com

i ovenstående liste, login.live.com er godkendelsessystemet, som du vil gå igennem, hvis du forsøger at godkende til Outlook.com og et stort antal andre Microsoft-tjenester. Jeg besluttede at undersøge det først for at se, om jeg kunne opdage nogen problemer. Som forventet syntes de forskellige API ‘ er, der blev brugt til at behandle et login, at være godt hærdet. Yderligere beskyttelseslag eksisterede mange steder; for eksempel krypteres adgangskoder nogle steder med en offentlig nøgle før transmission på trods af al kommunikation, der finder sted via HTTPS.

efter at have testet i et par timer opdagede jeg et par mindre problemer, som jeg rapporterede, men intet virkelig at bemærke. Når jeg tester internetapplikationer, finder jeg ofte, at den mest almindelige arbejdsgang også er den mest sikre, så jeg forgrenede mig til at undersøge andre måder, som en bruger kunne godkende til live.com system. For næsten et år siden havde jeg fundet flere OAuth-sårbarheder i Yammer, som også var et Microsoft Online Services bounty-mål, så det var her, jeg kiggede næste efter live.com. det er her de interessante fund starter!

Sårbarhedsbaggrund

før jeg kommer lige ind i den opdagede sårbarhed, er et hurtigt overblik over det vildledte sikkerhedssystem kendt som OAuth nødvendigt:”OAuth giver klientapplikationer en’ sikker delegeret adgang ’til serverressourcer på vegne af en ressourceejer”. Vi har også nogle skarpe kommentarer til dens udvikling og sikkerhed, som er værd at læse for en god latter. Realistisk set er alt, hvad OAuth gør, at tillade en bruger at give adgang til nogle eller hele deres kontos adgang til en tredjepart. Jeg lavede en MS Paint tegning for at illustrere dette, fordi jeg ikke kunne finde en stor en på .

som det kan ses i ovenstående billede, har du en Server, som brugeren har tilladelse til at give adgang til deres konto til en klientapp. Mekanismen, der håndterer dette bag kulisserne, kan bygges på flere forskellige måder, som er defineret i OAuth RFC. En måde at opbygge det på er at en “implicit” godkendelsesstrøm, som involverer godkendelsesserveren, der giver en adgangsnøgle direkte til klienten. En anden populær måde er at bruge en “autorisationskode” – procedure, hvor autentificeringsserveren giver en autorisationskode, som klientsystemet tager, og derefter bytter til en adgangsnøgle ved hjælp af dens klienthemmelige værdi. Microsoft har en god beskrivelse af deres brug af, hvordan de har implementeret disse mekanismer til live.com her:
https://msdn.microsoft.com/en-us/library/hh243647.aspx

grafikken, de lavede til” autorisationskode ” – strømmen, ser sådan ud:

et billede som det er fantastisk til at forstå processen, men for mig som pen-tester viser også mange muligheder og steder for ting at gå galt. Så med det som baggrund, videre til hvad der blev opdaget!

Hvad Kunne Gå Galt?

som nævnt i ovenstående afsnit er der mange steder, at noget kan gå galt. Et af de grundlæggende trin i OAuth-godkendelsesproceduren er, at en bruger vælger at give en applikationsadgang. Dette opnås normalt gennem en prompt som denne:

generelt behøver en bruger kun acceptere denne prompt en gang, men indtil de accepterer det, har den app ikke adgang til deres konto (hvorvidt den gennemsnitlige bruger tillader, at vi ‘ s onde App får adgang, er måske et andet spørgsmål!).

tænker som en angriber, ville det helt sikkert være godt, hvis vi kunne acceptere anmodningen på vegne af brugeren. Desværre for mig blev overskriften “header” sat til” deny ” (indstillinger for indstillinger for header var også uden for denne bounty). Så mens clickjacking er ude, jeg besluttede at få en bedre forståelse af, hvordan selve anmodningen fungerede. Hvis en bruger klikker på “Ja”, sendes følgende anmodning til serveren (plus nogle kedelige overskrifter):

mens URL-stien ovenfor indeholder nogle genererede tokens, viste test, at de var unødvendige for anmodningen om at lykkes. Et indlæg til følgende URL ville fungere lige så godt:

https://account.live.com/Consent/Update?ru=https://login.live.com/oauth20_authorize.srf%3flc%3d1033%26client_id%3d000000004C15E107% 26scope%3DV.grundlæggende%26response_type%3dcode % 26redirect_uri%3Dhttp:// exfiltrated.com& client_id=000000004c15e107&rd=eksfiltreret.kom& anvendelsesområde=VL.basic

den cookie, der sendes med anmodningen, er nødvendig for at indeholde et gyldigt sessionstoken i “IPT”. Denne cookie-værdi udfyldes afhttps:/ / login.live.com / oauth20_autorisere.srf, før den side, der beder brugeren om tilladelse, vises. Dette sker uanset om en bruger i sidste ende klikker på “Ja”, selvom den er indstillet af en Javascript-kode, så hvis vi angriber denne proces, bliver vi nødt til at tvinge brugeren til at indlæse den side på et tidspunkt.

hvis du følger med, forhåbentlig spørger du nu: “OK, så hvad med selve POSTANMODNINGEN og den kanariske værdi?”. Jeg havde først undersøgt alle de andre parametre og kommunikationsstrømme, da det at se en værdi mærket “canary”, der sendes med en POSTANMODNING, næsten helt sikkert betyder, at den bruges som et token for at forhindre CSRF-angreb. Pointen med sikkerhedstest er imidlertid at kontrollere, at antagelserne faktisk er korrekte. Så jeg ændrede POSTANMODNINGEN og ændrede kanarieværdien til”hacks_go_here”. I stedet for at omdirigere til en 500-fejl, sendte serveren et positivt svar tilbage!

CSRF til PoC

da CSRF-token var den sidste ting, jeg havde forsøgt at manipulere med, vidste jeg med sikkerhed, at dette skulle skabe en gyldig CSRF-sårbarhed. Som med næsten alle CSRF-angreb var den eneste forudsætning, at offeret var logget ind og havde et gyldigt sessionstoken i deres cookie. I modsætning til mange andre sårbarheder på nettet er virkningen af en CSRF-sårbarhed helt afhængig af den berørte API-funktion. Denne CSRF lader mig omgå brugerinteraktionstrinnet i OAuth-godkendelsessystemet, men en PoC er tusind ord værd, så det næste trin var at opbygge en kode for korrekt at demonstrere virkningen af denne sårbarhed.

i den normale OAuth-godkendelsesstrøm, efter at brugeren har givet adgang, skal serveren returnere en adgangskode til brugeren. Brugeren videregiver det til klientapplikationen, som derefter kan bruge de tildelte tilladelser. A live.com klientapplikation kan anmode om en bred vifte af mulige tilladelser. Jeg overvejede bare at dumpe brugerens kontakter eller sådan noget, men hvorfor ofre på målet om hacking Hotmail nu? De tilladelser, som min PoC havde brug for dengang, var:

VL.offline_access + VL.imap

Offline var ikke alt det nødvendige, men jeg kastede det ind for at vise, at det ville blive givet.

med de nødvendige tilladelser valgt er der 4 trin for at få adgang til en brugers e-mail-konto:

1) Vi er nødt til at foretage en godkendelsesanmodning for vores klientapp ved hjælp af ovenstående tilladelser. Serveren vil bede brugeren om at acceptere eller afvise.
2) Når en bruger accepterer vores anmodning om disse tilladelser, tilføjer serveren en “#access_token=<token>” parameter til den omdirigering, som vi instruerer den om at tage.
3) da vores server side scripts skal have adgang til denne værdi, er vi nødt til at lave en simpel side for at tage token fra URL-feltet og sende det til vores server.
4) Endelig har vi brug for nogle scripts server side for at tage det token, og bruge det til at logge ind på IMAP. Microsoft har en noget indviklet proces til at bruge OAuth-token til at logge ind direkte via IMAP. Der findes et par eksempler på biblioteker til dette, og hele processen er beskrevet på denne side:
https://msdn.microsoft.com/en-us/library/dn440163.aspx

denne arbejdsgang ville fungere fint, forudsat at brugeren vælger at give os tilladelse. Jeg skal nu bare ændre arbejdsgangen for i stedet at inkludere CSRF. Som tidligere nævnt er live.com autentificeringsserver forventer et sessionstoken i IPT-cookien. Vi kan sikre, at der er befolket ved først at sende brugeren til en validhttps://login.live.com/oauth20_autorisere.srf side. Umiddelbart efter kan vi udføre CSRF-anmodningen, som vil gøre brug af den nyligt udfyldte cookie-værdi. Dette kan nu erstatte trin 1 og tvinge serveren til straks at hoppe til trin 2.

Demo and Impact

Microsoft har nu løst dette problem, men her er en hurtig video, der viser det i aktion.

som det kan ses i videoen, er alt, hvad der virkelig er nødvendigt, at få offeret til at besøge din ondsindede hjemmeside. Demoen var ikke designet til at være luskede og køre i baggrunden af en hjemmeside, eller som en del af nogle ondsindede bannerreklame, men det helt sikkert kunne have været gjort på den måde.

brug af dette som et målrettet angreb har bestemt stor indflydelse, men dette er også den perfekte type sårbarhed til at blive til en orm. Med IMAP og kontakt bog adgang, en orm kunne nemt e-maile alle en brugers kontakter (eller i det mindste dem, der bruger Hotmail, Outlook.com, etc), med noget lokkende, “ILOVEYOU” virus stil, og spredes til alle brugere, der klikker på linket.

Endelige tanker og tidslinje

jagt efter denne sårbarhed og at lave en fungerende PoC involverede en hel del indsats for at grave gennem de forskellige live.com API ‘ er. Ser tilbage på det hele dog, dette er virkelig bare en klassisk CSRF-sårbarhed. Det eneste der er overraskende ved det er, at det er i et kritisk godkendelsessystem, som i sidste ende kan bruges til at overtage enhver brugers konto.

som ekstern tester aner jeg ikke, hvor længe denne sårbarhed kan have eksisteret, eller hvis nogen nogensinde har forsøgt at udnytte den. Samtidig er det resultater som dette, der helt sikkert viser værdien af at lade eksterne testere indsende sårbarheder til din virksomhed, før angribere udnytter dem mod dig. Microsoft er langt foran de fleste virksomheder, når det kommer til sikkerhed, og alligevel er de stadig suceptible til problemer som denne. Synacks erfaring har været, at sårbarheder afdækkes selv i tilsyneladende godt sikrede systemer, når en stor gruppe eksterne forskere tester dette system. Det er i det væsentlige den forudsætning, at Synack opererer på, og derfor tilbyder flere og flere virksomheder deres egne bounty-programmer (jeg vil selvfølgelig anbefale Synacks program over at køre dit eget!).

som det kan ses på tidslinjen nedenfor, var Microsoft lydhør over for at få en løsning på dette problem, hvilket var dejligt at se.

tidslinje:
23. August 2015: sårbarhed opdaget
25. August 2015: sårbarhed rapporteret til Microsoft
31. August 2015: Microsoft udsteder sagsnummer for sårbarhed
15. September 2015: Microsoft frigiver rettelse til problem, udsteder $24.000 bounty (double bounties promo)