Bug in OAuth 2.0 en OpenID geeft hackers toegang tot privacygegevens

Een student uit Singapore heeft een bug ontdekt in OAuth 2.0 en OpenID. Door de bug kunnen hackers gegevens van gebruikers van onder andere Google, Facebook en Microsoft stelen. Dit is mogelijk door het nabootsen van inlogschermen.

De bug, die de student Covert Redirect heeft genoemd, stelt een aanvaller in staat om een gebruiker via een geposte link op bijvoorbeeld Facebook een pop-upscherm te tonen van een app die om autorisatie vraagt. In de adresbalk van de pop-up wordt de url van Facebook weergegeven. Nadat de gebruiker zijn inloggegevens heeft ingevoerd en de app heeft geautoriseerd, stuurt de pop-up deze door naar de aanvaller. Wat de pop-up verder allemaal doorstuurt, is afhankelijk van de toestemmingen die aan de app worden gegeven. Vervolgens wordt de gebruiker doorgestuurd naar een website die de hacker vooraf heeft ingesteld.

Onder de bedrijven die gebruik maken van OAuth 2.0 en OpenID vallen onder andere Facebook, Google, LinkedIn en Microsoft. De student laat aan Cnet weten dat het probleem door Google wordt onderzocht en dat LinkedIn spoedig een blog vrijgeeft over de bug. Microsoft had de bug al onderzocht en gaat geen stappen ondernemen. Het bedrijf kwam erachter dat de bug niet voorkomt op zijn eigen websites maar alleen op die van derde partijen.

Reacties (40)

[BugBoy]

Het feit dat OAuth2 niet secure is werd in juli 2012 al aangehaald door Eran Hammer in zijn blogpost "OAuth2 and the road to hell". Hij was één van de architecten achter OAuth, maar besloot tijdens de ontwikkeling van de OAuth2 standaard dat het zo slecht was, dat hij zijn naam er niet aan wou verbinden.

Quote: "It is the biggest professional disappointment of my career.".

Hij gaf al aan dat de veiligheid van OAuth2 heel erg afhangt van een juiste implementatie van de standaard. Dat is meestal wel zo, maar bij OAuth2 zitten er zoveel valkuilen in dat vrijwel niemand een goede implementatie zal maken. Blijkbaar is zijn angst waarheid geworden.

Een voordeel van OAuth2 t.o.v. OAuth1 is dat je het client-side kunt gebruiken, zonder een eigen server te hoeven hebben. Voor OAuth1 is dat wel noodzakelijk. Je kunt een OAuth1 proxy gebruiken, maar dan moet je je eigen private key uploaden naar een externe site. Niet iets dat je normaal gesproken moet willen.

Dit voordeel is dus ook het probleem geworden. Aangezien in OAuth1 een callback naar een known server verplicht was in het protocol was het een stuk meer secure. In OAuth2 vertrouw je vooral op de redirect URL. Daar gaat het nu dus eigenlijk mis...

[Reactie gewijzigd door BugBoy op 27 juli 2024 02:04]

[Verwijderd]

Dat verhaal van de bedenker van OAuth1 had ik ook gehoord. Eerlijk gezegd heb ik zitten wachten op nieuws dat het onveilig is.... teveel "design by committee"...

[BugBoy]

Probleem was vooral dat uiteindelijk alleen nog mensen van grote enterprises in het commite zaten. Die hebben vooral korte termijnbelangen en een goede integratie met hun eigen platform. Daardoor is de OAuth2 standaard wat vertroebeld geraakt. Jammer, want de gedachte van OAuth is ideaal. Niet overal meer wachtwoorden nodig.

[Morphix]

Hoe is dit een bug? Alles wat ik zie is een (zoveelste) geval van phishing.

edit: Het hele probleem lijkt een beetje lost in translation. Blijkbaar wordt een OAuth token gekaapt waarmee inderdaad alle gegevens waar dat token toe gerechtigd is toegankelijk zijn. Of het dan alleen gaat om apps die specifiek daarvoor gemaakt zijn of ook om 'veilige' apps is me nog steeds niet duidelijk.

[Reactie gewijzigd door Morphix op 27 juli 2024 02:04]

[MrMonkE]

Omdat Facebook het toestaat een popup te laten genereren door een gebruiker zijn link zodat het lijkt als of facebook erom vraagt?

[BasieP]

Dan zit de bug dus in de facebook implementatie, en niet in OAuth..

[Armin]

Volgens mij gaat het verder, en is het een structurele fout.

In het voorbeeld dat gegeven wordt, lijkt het erop dat Facebook geheel niets controleert. Ofwel zowel de afzender als redirect URL worden niet gecontroleert.

Ofwel, ik als misbruiker, kan een willekeurige URL fabriceren en beweren dat ik bedrijf X ben, en na inloggen, wil redirecten naar website Y. Facebook doet hier nihil controle op. Nog of de authenticatie request inderdaad voor X is, maar ook niet of Y wel een website is die hoort bij X.

Ik weet niet of dat een implementatie-kwestie is, of een fundamenteel onderdeel van OAuth. Ik bedoel dat laatste, als OAuth inherent geen methode heeft om authenticatie te doen (= controleren of de request inderdaad van X komt) en inderdaad cross-site/domain redirects officieel toelaat, is het protocol zélf gebroken.

Facebook zelf mompelt in haar reactie iets van whitelisten, maar dat is ekel een lapmiddel en zoals ze zelf zegt weinig praktisch. Zelf vrees ik dat cross-domain redirects bij OpenID en OAuth waarschijnlijk heel voorkomend zijn, ook in legitieme gevallen. Als dat inderdaad zo is, kan het inderdaad niet makkelijk gefixt worden door cross-domain redirects te blokkeren.

Toch lijkt me dat de beste oplossing. Als website X om OAuth autenticatie vraagt, moet de redirect ook naar domain X zijn. Domain X moet dan maar redirecten naar Y indien gewenst. Dat stop aanvallen zoals deze.
Alternatief zouden zijn om domain X te authenticeren, om zo te zorgen dat de request ook van X komt, maar dat is implementatie-technisch waarschijnlijk veel moeilijker.

Hoe dan ook, zoals het nu staat is OpenID en OAuth totaal onveilig en moet gebruik volledig afgeraden worden tenzij je de maker van de URL vertrouwt. Echter dat is wellicht risicovol omdat de meeste websites tegenwoordig cross-domain content bevatten.

[MrFax]

Maar dan is de implementatie van Microsoft en Google dus hetzelfde, anders klopt dit hele verhaal niet.

[Armin]

Dat is dus de vraag die ik stel. Is de bug enkel een specifiek gebrek van de Facebook implementatie, of niet laat de spec het ook zelf open. Het lijkt erop dat het dat laatste is aangezien de 2.0 spec van OAuth bijvoorbeeld enkel adviseert om het te doen. Dan is het aan de implementators om de zaak veilig te maken.

Overigens gebruikt Microsoft beide systemen niet, maar het schijnt dat een 3rd party het gebruikt in relatie met enkele Microsoft diensten. Vandaar dat de naam Microsoft in het rijtje genoemd werd. Hun eigen MSA systeem echter werkt geheel anders en is niet vatbaar voor dit soort redirects.

Google weet ik niet, maar de voorbeelden die gegeven worden zijn allemaal met Facebook, dus het kan zijn dat zij beperkingen in hun systeem ingebouwd hebben die dit lek dichten.

Maar hoe dan ook, ik zie dit als een groot gebrek in de standaard. OAuth en OpenID hadden dit gewoon dicht moeten gooien in de spec zelf. Net zoals bijvoorbeeld bij cookies ook geen cross-domein acties toegestaan zijn. Door het open te laten, laat je expliciet ruimte voor dit soort problemen ...

[ssmt]

Het is gebleken dat het geen bug in OAuth2 of OpenID Connect is maar dat Facebook gewoon niet de betrokken RFC's gevolgd heeft bij het implementeren van hun speciale profiel van OAuth2.

In de standaarden wordt namelijk meer dan eens gemeld dat bij 'insecure clients' de gegeven redirect link één op één hetzelfde moet zijn als de bij registratie opgegeven redirect link. Zie voor meer info hier.

[Armin]

Bedankt voor de correctie, al moet wel opgemerkt worden dat 'de standaarden' niet echt bestaat bij OAth 2.0. het is een aaneenschakeling van drafts. De door jou aangehaalde specificatie ontbrak bijvoorbeeld zeer lange tijd in de spec. De versie van de spec die facebookgebriukte, heeft die bealing bijvoorbeeld ook niet.

Maar je hebt gelijk dat het vooral Facebook is geweest die hier faalde. Immers een bedrijf als Facebook wordt niet ontslagen van zelf elementaire security checks bij het implementeren.

Het feit dat de OATuth 2.0 een zeer lang en rommelig verloop had (waardoor o.a. de oprichter van OAuth 1.0 opgestapt is) heeft dit wel uitgelokt ...

[MrFax]

Of de manier hoe OAuth de authorizaties handelt.

Voortaan de artikel beter lezen:

"Door de bug kunnen hackers gegevens van gebruikers van onder andere Google, Facebook en Microsoft stelen."

edit: grammatica

[Reactie gewijzigd door MrFax op 27 juli 2024 02:04]

[Blinkin]

Een heel goed punt. Vraag me ook af of het nou in alle apps zit of alleen in de apps die er specifiek voor gemaakt zijn. In dat laatste geval is het gewoon het oude truukje zover ik kan inschatten.

[ocwil]

Wat opvallend is dat er in de url gewoon dus https://www.facebook.com/...
Dit is dus wel wat anders dan phising

[--Andre--]

OAuth stuurt je naar de site van bijvoorbeeld facebook, daar log je in en geef je toestemming, en dan stuurt hij je terug naar de site van de app. Dus dat het inlogscherm op facebook.com staat is gewoon de werking van OAuth. Als ik een malafide app toegang geef tot mijn profiel.... tsja, dat valt facebook of OAuth niet te verwijten.

[Armin]

Je mist het kern punt.

Jij krijgt een popup die zegt wil jij X toestemming geven voor gegevens ABC, waarbij X een betrouwbare organsiatie/app is. X is hierbij niet de malafide app! Echter Facebook stuurt daarna wel vrolijk jouw ABC gegevens naar die malafide app.

[Sthomkop]

Volgens mij is het niet mogelijk om een app met dezelfde naam te registreren bij een site die OAuth autorisatie gebruiken in hun API, precies om deze reden. Het is ook niet zomaar mogelijk om een verzoek te doen op naam van een bestaande app, want je moet daarvoor voor zover ik weet een app key meegeven, die je als app ontwikkelaar absoluut geheim dient te houden.

Ik begrijp niet helemaal wat nou het probleem is. Het verhaal van die Wang Jing komt ook niet echt betrouwbaar op me over: hij legt totaal niet uit wat het lek nou precies is, of ik heb zijn uitleg compleet over het hoofd gezien...

[Armin]

Het is ook niet zomaar mogelijk om een verzoek te doen op naam van een bestaande app, want je moet daarvoor voor zover ik weet een app key meegeven, die je als app ontwikkelaar absoluut geheim dient te houden.


Dat is dus niet zo. En dat is de kern hier.

Het blijkt dus kinderlijk eenvoudig je voor te doen als een andere app. Dus ik kan als malafide app/website mij voordoen als een officiele app/website, en redirecten naar een willekeurig adres.

ik heb zijn uitleg compleet over het hoofd gezien...

Ik vrees van wel

Let wel, ik moest ook zoeken, want het kwam op mij ook warrig over en de meeste sites rapportereden geen details, maar er is o.a. een Youtube video die het stap voor stap demonstreert, waarbij de ESPN key/url gebruikt wordt als voorbeeld.

Er is geen key-beveiliging nodig, want géén verplichte authenticatie. Dat is cynisch genoeg ook één van de expliciete redenen waarom de OAth 1.0 auteur opgestapt is bij OAth 2.0, omdat men weigerde verplichte authenticatie in te voeren. Dat had immers dit probleem ook voorkomen...

[SWINX]

Phising 2.0 dan maar. Niet via een kopie website, maar via de echte site, wat in principe nog vertrouwd overkomt...

[tedades]

Beetje combi van XSS en phising, je plaatst code op facebook en facebook doet de phising voor je.

[Cartman!]

Dit is toch simpelweg op te lossen door te werken met een whitelist van redirect-urls? Sowieso best practise en veel netwerken ondersteunen dit al. Facebook ondersteunt dit ook maar dwingt het nog niet af.

[--Andre--]

Precies, op de app instellingen pagina staat:
"Valid OAuth redirect URI. If not set, your app is open to redirect attacks."
Ik heb deze bij mijn development app uit staan, maar er zijn inderdaad OAuth providers die dit forceren. In mijn ervaring forceren de meeste dit wel.

Voor development doeleinden is met misschien handig geen controle te hebben, maar voor een productieomgeving is het aan te raden.

[Armin]

Probleem hiermee is dat:
- zo'n whitelist al snel honderduizenden request per dag krijgt om toevoegingen en wijzigingen, en dat controle daarop dus potentieel een wassen neus wordt.
- jij als gebruiker niet weet of Facebook/website ABC zo'n whitelist hanteert, of blind elke redirect toestaat zoals nu het geval lijkt te zijn.

Volgens mij is een cross-domein redirect gewoon iets wat je hier niet moet willen. Dan wordt het heel simpel. Popup vraagt om bedrijf X, dan is de redirect ook naar bedrijf X. Zo werken cookies bijvoorbeeld ook betreft data-access.

[Verwijderd]

Dit is precies de oplossing. Het verifiëren van redirects uit een parameter (bij OAuth 2.0 het geval) moet je altijd controleren tegen een whitelist. Dit is zelfs nr 10 van de OWASP Top 10 meest kritieke veiligheidsrisico's op het internet:
https://www.owasp.org/ind...ed_Redirects_and_Forwards

"For each use, identify if the target URL is included in any parameter values. If so, if the target URL isn’t validated against a whitelist, you are vulnerable."

[Kain_niaK]

Sofware (en software in het algemeen) op het internet is zo complex aan het worden dan het steeds lastiger word om het veilig te houden.
Als je denkt aan hoe veel van deze bugs en beveiligingslekken er gevonden worden dan moet je ook denken aan alle gaten die niet gemeld worden. Omdat ze gevonden worden door iemand met andere ethische principes en die informatie misschien liever verkoopt aan criminelen. Of dat ze gevonden worden door diensten zoals de NSA. Die hebben waarschijnlijk teams en geautomatiseerde software die de hele dag de meest gebruikte websites onderzoeken op dit soort mogelijkheden, zodat ze die informatie in hun database met bugs en leaks kunnen stoppen. Voor het geval ze het ooit nodig hebben als ze achter een target aan zitten.

In de toekomst gaan dit soort gaten alleen maar grotere gevolgen hebben voor de veiligheid en comfort van internet gebruikers. Het internet 2 moet echt radicaal anders ontworpen worden. Wat ik bijvoorbeeld niet snap is dat 99% van alle emails op het internet gewoon in plain text verstuurd worden waar elke internet hop alles van de email kan zien. En ook gewoon de inhoud van de mail kan veranderen voor het verder gestuurd word. En dat je emails kun sturen onder een afzender adres dat je zelf kiest. Er zijn authenticatie systemen hiervoor zodat je weet dat je effectief met de juiste persoon aan het mailen bent ... maar die worden nauwelijks gebruikt. Ook PGP word nauwelijks gebruikt.

Dit vraagt om betere ontwikkelde systemen waar encryptie en authenticatie in de kern is ingebouwd en makkelijk te gebruiken is voor zelfs de meeste simpele computer gebruikers.

Gelukkig zijn er initiatieven zoals TOR en bitcoin. Dit soort onderliggende technologie word hopelijk ooit in de toekomst gebruikt voor een internet 2 waar een heleboel spoofing niet meer zo makkelijk is (bv IP spoofing, email adres spoofing, dns spoofing, etc etc) en standaard elke data pakketje dat je computer verlaat ondertekend is en versleuteld.

Ook spam kan volledig opgelost worden als er een standaard voor email komt die gebruikt van de technologie achter hashcash bijvoorbeeld. Waar ook bitcoin gebruik van maakt. Het idee is dat elke mailtje je computer een beetje rekenkracht kost en het sturen van 10 000 emails dus opeens niet meer gratis is. De ontvanger heeft maar een fractie van die kracht nodig om te controleren of er inderdaad "werk is verzet" ... zo niet dan word de email geweigerd. Als elk mailprogramma dit ondersteunt en 80% van de mensen op het internet op deze manier gaan emaillen dan levert spam criminelen niks meer op en stopt het vanzelf.


Het probleem met al deze technologie is dat het momenteel niet gebruiksvriendelijk genoeg is en dus niet geïmplementeerd word door de grote jongens van het internet (apple, microsoft, google)

Hopelijk komt daar ooit verandering in want we zijn zo'n beetje in het tijdperk waar een goede hacker bijna God almachtig is die overal binnenkomt en alles ziet. En vermits elk apparaat , ook al is het de koelunit in een kerncentrale, aan het internet word gehangen ... belooft dat wat voor de toekomst.

Die scene in hackers waar ze alle verkeerslichten op groen zetten? Da's tegenwoordig in sommige gevallen nog mogelijk ook .... wanneer de gewichtsdetectie draadloos met de stoplichten communiceert ... onversleuteld en zonder authenticatie.

Wanneer je dan al die informatie video's van defcon bekijkt over hoe je met een goede antenne en een deftige wite noise generator en een 100 WATT versterker het GSM verkeer in een radius van 50km (of meer) kunt verstoren ..... of hoe de database van opgevangen wifi signalen door die google street autootjes ook de MAC adressen bevat. En dat men dus wanneer men toegang heeft tot je router nu ook precies kunt zien waar die router zich in de wereld bevind .... omdat het mac adres in die database staat en nu gelinkt is aan gps coördinaten

[Reactie gewijzigd door Kain_niaK op 27 juli 2024 02:04]

[Dreamvoid]

Ook spam kan volledig opgelost worden als er een standaard voor email komt die gebruikt van de technologie achter hashcash bijvoorbeeld.

Spam wordt dan via botnets met distributed computing verstuurd (wat toch al gebeurt).

[Armin]

Plus dat het sturen van spam-email nu ook al niet gratis is. Het is echter zeer rendabel.

Het hashcash mechanisme zou alleen werken indien de kosten van sturen van spam structureel en significant groter zijn dan de baten. Gezien de extreem lage kosten van rekenkracht, en het feit dat de spam/malware industrie een miljoenenbusiness is lijkt me dat een illusie.

[Verwijderd]

Als je niet wilt dat draadloze communicatie verstoord wordt door een ruisgenerator moet je het niet gebruiken. Ik weet dat dat niet handig is, maar het is wel de realiteit.

Dat pgp amper wordt gebruikt snap ik ook wel, dat is voor een n00b niet te installeren, en voor mijn oma niet te lezen.

Gaten zullen wel blijven, ik zie dat nooit opgelost worden. Maar iedere patch is er weer één die gaat bijdragen aan een veiliger internet.

In dit OpenID geval is het gekozen model gewoon fout, maar dat schreef ik hieronder al.

[johnkeates]

Het is wel op te lossen maar dan moet je gebruikers de rechten ontnemen te veel aan hun eigen systeem te kunnen veranderen. Kijk naar iOS en WP, die systemen zijn redelijk waterdicht i.t.t. Android als je naar recent nieuws over malware, phishing en degelijke kijkt.

[Verwijderd]

Ik heb een iPad en een iPhone, en daar baal ik stevig van, als tweaker ;-) (door het werk beschikbaar gesteld, geen vrije keuze)
Volgens mij is een dichtgeplakt systeem niet per definitie veiliger, maar los daarvan heeft dat niet veel met OpenID te maken. Dat kan ik op mijn iShit nl ook gewoon gebruiken, net als op Android, Windows, Linux en Osx.

[johnkeates]

Dat is natuurlijk zo, maar het hangt ook van je apparatuur af en wat je er mee doet. Als het apparaat of OS zelf je doel is (om dat je het wil hebben, mee wil spelen, tweaken ofzo), dan is het natuurlijk een heel ander punt dan als het apparaat of OS een stuk gereedschap is voor een proces (bijvoorbeeld als je een ding nodig hebt dat gewoon altijd op dezelfde manier belt, altijd verschillende soorten berichten kan versturen of ontvangen, altijd kan internetten en altijd werk-specifieke apps kan gebruiken).

Ik zou voor werk bijvoorbeeld nooit een "open" systeem willen hebben. Niet als werkgever, niet als werknemer, en niet als beheerder. Dat is gewoon niet te doen, en ook met opties zoals KNOX of virtuele containers is daar gewoon geen beginnen aan. Dan liever iOS, WP of BBOS10.

Dat soort systemen zijn niet veiliger op dat ze iets meer gesloten zijn, maar minder onveilig om dat de gebruiker er niet mee kan rommelen. En dat laatste is nou eenmaal iets wat gebruikers doen.

[Netrunner]

Truuk uit de oude doos, klassieke phishing.

[StGermain]

Inderdaad, iets wat we in 1985 al deden op de schermen van een UNIVAC 1100 van de hogeschool, iets laten draaien dat er uitzag als een standaard inlogscherm, de gegevens opvangen en bewaren en dan doorgeven aan een echte login...

[WhatsappHack]

Nee bij klassieke phising doe je je voor als iemand anders, bijvoorbeeld facebooks.com ipv facebook.com, en daar jat je gegevens via een nep formulier. Nu gebeurt de authenticatie gewoon op de originele en valide URL...

[Verwijderd]

Ik begin zo langzamerhand het idee te krijgen dat het internet heel erg stuk is, of langzaam uit elkaar valt. Als het niet zo ernstig was zou je er bijna om moeten lachen.

Ik ben nooit voorstander geweest van OpenID achtige oplossingen. Het maakt het leven makkelijker, voor de gebruiker maar helaas ook voor dat van de kwaadwillende internetterrorist. Daar waar het in mijn vak standaard is om "single point of failures" zo veel mogelijk te voorkomen verzinnen ze er op het internet, ten dienste van het grote gemak, er zo veel mogelijk bij.

[BugBoy]

Ik denk dat je de stelregel moet hanteren om OpenID of OAuth logins alleen te gebruiken bij niet kritische websites. Voor een forum vind ik het prima om dat via OAuth te doen, maar voor wat kritischere zaken moet je het niet doen. Overigens kun je ook bij geen enkele bank, verzekering of overheidsinstelling inloggen met OpenID/OAuth.

Als het een kritische applicatie is (financiën, email, ...) dan moet je gewoon per site een ander (veilig) wachtwoord hebben of het liefst een two-factor authentication gebruiken.

[ClaimItToYou]

Zo is Open ID wel heel erg open

[johnkeates]

Wat zijn de 'privacygegevens' dan? Gegevens over privacy? Of bedoelen ze misschien: "privé gegevens" of "privacy-gevoelige gegevens"?

En wat voor bug is dit dan? Een implementatie bug? Een design bug? Er mist weer een hele hoop...