Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 44, views: 39.258 •

Kwaadwillenden konden accounts kraken als ingelogd kon worden via Google en Facebook. De implementatie van die 'single sign on'-logins bleek vaak gebrekkig, waardoor het token dat Google en Facebook sturen onderschept kon worden.

Ook kon de accountinformatie van de gebruiker worden bewerkt als die naar servers van Google en Facebook wordt verstuurd, schrijft Ars Technica op basis van onderzoek van enkele wetenschappers van de Amerikaanse University van Indiana en Microsoft Research.

De kwetsbaarheden die de onderzoekers hebben gevonden, zijn allemaal gerepareerd, zo schrijven de onderzoekers in hun paper. Dat betekent niet dat deze Single Sign On-loginprocedures nu veilig zijn, waarschuwen de onderzoekers. "Wij geloven dat gezien onze onderzoeksresultaten andere webdiensten met Single Sign On-procedures ook kwetsbaar kunnen zijn." De kwetsbaarheden werden niet alleen gevonden bij diensten, waarop gebruikers kunnen inloggen via Google of Facebook, maar ook bij OpenID.

Vanwege die gebrekkige implementatie, konden kwaadwillenden het token onderscheppen waaruit de dienst kan opmaken dat de gebruiker de juiste gebruikersnaam met wachtwoord heeft ingevoerd voor Google of Facebook. Daardoor had een kwaadwillende toegang tot het account van een gebruiker zonder een gebruikersnaam of wachtwoord in te hoeven vullen.

De kwetsbaarheden zaten zowel bij de implementatie van de logins op websites van derden als bij Google, Facebook en OpenID. Ook bleken bepaalde browsertechnieken de kwetsbaarheid te verhogen. Goede implementaties van Single Sign On bleken bijvoorbeeld onveilig te worden als ze werden uitgevoerd in Adobe Flash, aldus de onderzoekers.

Single Sign On stelt gebruikers in staat bij een dienst in te loggen met de gebruikersnaam en het wachtwoord van een andere dienst, bijvoorbeeld Gmail of Facebook. Dat verloopt via een api, die regelt dat de dienst aan Google of Facebook vraagt of de 'credentials' juist zijn, waarna de gebruiker een token ontvangt dat wordt gebruikt om in te loggen. Veel sites werken met deze Single Sign On-procedure.

Single Sign On-knoppen op websites

Reacties (44)

Log ook altijd in d.m.v. een (gratis) SMS te laten sturen met een login-code op dit soort sites!
Dat ga je natuurlijk niet doen voor iets 'onbelangrijks' (met alle respect :9 ) als Tweakers.
Maar voor je emailaccount is het toch wel enorm handig, inderdaad heb je veel sites waar het niet echt nodig is, maar ik heb veel belangrijke emails op mijn mail staan, dus die houd ik graag veilig!
Same here. Daarom gebruik ik 2-step verification. Ik vraag me af of deze dienst er ook last van had?
Klopt, zeer zeker. Maar wanneer je die single sign-on dienst gebruikt om in te loggen op een forum of random service is dat natuurlijk niet nodig. Je moet namelijk altijd met de request meesturen waar je toegang tot wilt hebben. Op mijn websites biedt ik ook aan om via Google en Facebook in te loggen. Dit doe ik alleen om bijvoorbeeld een naam en een identificatie te krijgen, puur om de inschrijfdrempel te verlagen.

Nu kun je natuurlijk stellen dat NAW gegevens net zo belangrijk zouden kunnen zijn als bijvoorbeeld e-mailberichten. Toch denk ik dat het gebruik van een SMS code voor het inloggen met SSO over het algemeen vrij overbodig is.

Overigens gebruik ik zelf ook 2-way verification voor mijn Google account. Maar om in te loggen op, ik noem maar wat, IMDB, vind ik dat niet echt nodig.
Dat is niet de strekking van deze aanvalsvector.

Overigens is niet nieuw.

Single Sign On aanvallen door credentials/token te onderscheppen is al zou oud als Kerbedos aanvallen en soort gevallen (replay attacks, cookies hijack etc..).

Het enige wat je er tegen kunt doen om risico te verminderen is active sessie bij houden op basis van IP adres, zodra er vanaf een ander IP met zelfde credentials/token worden gebruikt dien je opnieuw (deels) validatie te doen. O.a. bij deze website is dat zo.

Er zijn alleen drie problemen hiermee:

1) Als je achter nat zit (of aanvaller kan ook je IP overnemen of zit ook in het netwerk) zal het lastig worden.

2) Bij sommige ISPs en in sommige landen heb je om de paar uur een andere IP adres

3) o.a. Mobile gebruikers (o.a. Vodafone) verlopen sessies soms via transparante proxies en heb je soms wel bij elk HTTP request een ander IP adres. (erg irritant overigens)

Google gaat binnenkort over op HTTPS dan is elk individuele computer identificeerbaar, naast dat "credentials/token" niet (zeer lastig) af te tappen zijn, kunnen ze met behulp van andere unieke elementen en met name dankzij HTTPS altijd je computer identificeren.

Het is dan makkelijker om gewoon je wachtwoord te onderscheppen door trojaanspaard b.v. (iets wat nog steeds laagdrempeliger is dan een SSO sessie te hijacken)

Niet dat dat wenselijk is omdat dan je privacy van gebruikers van jouw computer voorbij is. (CPU-ID uitlezen leverde Microsoft veel kritiek op, maar HTTPS gebruik door Google hoor je niemand over, terwijl resultaat hetzelfde is.)

Overigens het grootste probleem is nog altijd onwetendheid. Mensen die over WIFI sites bezoeken (wat normaal is met een tablet, laptop of GSM) zijn zich totaal niets bewust:

Leuke item daarover:
http://www.youtube.com/watch?v=V4SBW4SNcz4

[Reactie gewijzigd door totaalgeenhard op 26 maart 2012 12:42]

Verbaast me eigenlijk weer bar weinig. Gelukkig maar één keer gebruik van gemaakt in het verleden. Toch maar even wachtwoord gewijzigd...
Men krijgt geen toegang tot je wachtwoord. Wat gebeurd is dat men het token wat je terugkrijgt kan vervangen door een token wat aangeeft dat de login is geslaagd waardoor een hacker ingelogd wordt terwijl die geen correct wachtwoord heeft ingevoerd.

De tokens zijn dus voorspelbaar.
Op basis van de informatie die we nu hebben. Ik ben nu eenmaal extreem paranoide wanneer het het internet aangaat. Maar toch bedankt voor de geruststelling, ik las het bericht in eerste instantie verkeerd :)
De tokens zijn niet voorspeelbaar, maar makkelijk te onderscheppen.
Geen toegang tot je wachtwoord?? Als ik jou FB-token heb heb ik toegang tot je account, nee ok het wachtwoord zelf niet maar je account is wel toegankelijk en er vallen dingen aan te passen!

Verder moet je bekijken welk niveau van beveiliging op jezelf van toepassing is maar ken nog niemand die enkel HTTPS gebruikt, alle add-on's blokkeert en enkel toegang heeft tot eigen white-list (default block) via modem.

Wel een aandachtspuntje voor SSO in algemeen, blijft kwetsbaar maar ja wat niet ... :+
Je hebt alleen toegang tot waar de app die bij de bijbehorende API key hoort toegang heeft gekregen. Over het algemeen is dat vrij beperkt en omvat het al helemaal niet het aanpassen van bijvoorbeeld een wachtwoord.
Deze inlogprocedure is sowieso gevaarlijk. Je voert je inlog-gegevens van Google of Facebook in op een andere site. Dan moet je die andere site wel goed kunnen vertrouwen!
Je voert je inloggegevens in op twitter of facebook zelf. Middels de oAuth API wordt een terugkoppeling verzorgd naar de desbetreffende website.
Zo werken die API's inderdaad, maar dat neemt niet weg dat sites zelf een login systeem kunnen ontwerpen dat zich voordoet als een Google/Facebook API, maar vervolgens jouw inlogdata verzamelt voor misbruik. Het is niet zo moeilijk om erachter te komen of je daadwerkelijk met Facebook/Google te maken hebt, maar veel mensen letten er niet op of weten toch niet precies hoe ze erachter komen.
Sterker nog, ik denk dat 98% van de mensen het niet weet.

Naarmate dit SOO-gebeuren zich meer verspreidt, zal hiervan meer misbruik gemaakt gaan worden, met alle gevolgen van dien. De meeste mensen gebruiken nu eenmaal slechts 1 wachtwoord voor hun Facebook, e-mail, Paypal etc.
Je krijgt altijd een popup met URL van Google of Facebook zelf waar je je gegevens moet invoeren. De website krijgt dus niet je usr/ww, dat wordt juist voorkomen met zulke oplossingen
Dan heb je Single Sign-On niet begrepen, je wordt doorgestuurd naar bijv. Google en daar log je in (niet op de website zelf) en zij sturen een token (stukje tekst zegmaar) terug naar de site die dan jouw identiteit kunnen uitlezen (jouw e-mailadres in het geval van Google) maar daarmee hebben ze niet jouw wachtwoord. In dat mechanisme zit dus blijkbaar een fout waardoor iemand zich als een ander kan voordoen. Kortom: iemand kan toegang krijgen tot site X met die methode maar niet tot jouw Google account zelf. Niet minder erg maar jouw opmerking klopt ieder geval niet.
Ik mis de technische details in het artikel. Wat ging er dan fout, wat werd er onderschept, hoe werd het onderschept en hoe werd met die gegevens opnieuw de authenticatie aangevraagd?
Als ik het goed begrijp gaat het niet om 1 fout, maar om meerdere, en wordt in het artikel het onderscheppen van een token beschreven als voorbeeld. Een token is kortweg een bewijs van identificatie met mogelijk nog authorisation-assertions en manieren om de token te valideren. Deze onderschepte token werd vervolgens aangepast door de aanvallers en doordat het protocol niet afdoende werd geïmplementeerd door de relying parties, werd onrechtmatige toegang verkregen. De authenticatie wordt dus slechts 1 maal aangevraagd.

Normaal gezien dient de relying party te verifiëren of het token onveranderd is (kan bvb. door middel van digitale signatures), of de issuer is wie hij zegt te zijn, of de authenticatie correct gebeurd is, etc.
Als de relying party enkel de statement "dit is persoon X" eruit haalt en verder geen controles uitvoert, en dat is mogelijk, dan is de beveiliging zo lek als een mandje.

[Reactie gewijzigd door MatthiasDS op 26 maart 2012 12:59]

Ik heb nog niet naar de oAuth API gekeken maar daar zit toch wel een server-server check in?

Want ik had eigenlijk wel verwacht dat die jongens dit goed in elkaar hadden zitten.
Het lijkt vooral te zitten in de implementatie van de sites die het gebruiken begrijp ik uit het artikel bij Google. In Attribute Exchange (AX) in OpenID heb je de mogelijkheid om bepaalde gegevens mee te sturen bij het inloggen (bijv. je e-mailadres). Deze gegevens dienen door de ontvangende partij (Website X) gecontroleerd te worden maar dat gebeurde veelal niet waardoor een kwaadwillend persoon die gegevens kon manipuleren.
Oauth2 (wat door Google en Facebook gebruikt wordt) gebruikt geen signing op de berichten die uitgewisseld worden, maar steunt hoofdzakelijk op SSL. Verder wordt volgens de spec verwacht dat confidential clients (bvb een gewone website) zich authenticeren met hun vooraf geregistreerde geheime credentials, via bvb http authentication. Voor public clients (clients die geen 'geheim' kunnen houden, zoals mobile apps, sites die volledig in de browser draaien met javascript) wordt verwacht dat ze hun 'redirection URI' (de URI waarop je terechtkomt eens je ingelogd bent via Google, FB,...) vooraf registreren, en die ter verificatie meegeven bij ieder request. Als je de spec volgt, krijgen dit soort applicaties typisch ook minder rechten: authorizatie van de gebruiker moet dan in feite altijd beperkt zijn in tijd.

Er zijn dus wel een aantal dingen waar een ontwikkelaar moet op letten om de veiligheid te garanderen. Zo is de de redirection URI best enkel bereikbaar via SSL, en mag dit geen 'open redirector' zijn.

Edit: typos

[Reactie gewijzigd door BlueArchon op 26 maart 2012 11:30]

Mij verbaasd het ook niet, al mag de beveiliging wel beter vanuit de software. Het is echter nog steeds de gebruiker die hoort op te letten en niet op elke site dit te vertrouwen.
Altijd zelf opletten. Helaas gaat het bij dit punt ook al vaak mis.
Het gaat hier niet om zelf opletten. Mensen kunnen door een token te onderscheppen een succesvolle login faken, waardoor ze dus kunnen inloggen op een andere dienst/site. Dit is dus door de implementatie mogelijk, en heeft dus niets met opletten te maken.
De kwetsbaarheden die de onderzoekers hebben gevonden, zijn allemaal gerepareerd, zo schrijven de onderzoekers in hun paper. Dat betekent niet dat deze Single Sign On-loginprocedures nu veilig zijn, waarschuwen de onderzoekers.
Beetje tegenstrijdig dit, de betreffende kwetsbaarheden zijn gerepareerd, maar nog steeds is inloggen via Single Sign-On nog niet helemaal veilig. Kan iemand dat uitleggen?
Dat Facebook en Google dit nu gefixt hebben wil natuurlijk niet zeggen dat alle Single on logins nu veilig zijn.
Volgens mij impliceert dit dat de wetenschappers er zeker van zijn dat er nog aardig wat lekken in deze manier van inloggen zitten.
De methode is op een x aantal sites getest en het bleek op verschillende sites niet echt veilig te zijn. De conclusie is dan dat de gevonden problemen wel gerepareerd zijn maar het algemene beeld van matige implementaties niet verholpen is. Een willekeurige site kan dus nog steeds problemen in de SSO implementatie hebben aangezien niet alleen de SSO leverancier (Google/Facebook) fouten kan maken bij de implementatie maar juist de partij die gebruik maakt van de SSO service
OpenID v2 gebruikt speciale tokens om mee te communiceren. Als je een ssl verbinding hebt en er wordt gebruik gemaakt van v2 (niet v1 dus) dan is een man-in-the-middle nog steeds mogelijk, hoe veilig het dan ook is.
Natuurlijk is het risico dan minimaal.
Het onderzoek is (mede) gedaan door Microsoft Research.

Als ze ergens een gaatje zien (al is het een zwakheid in IIS, Apache, ... ) dan is het beter om nogmaals te zeggen dat Google & Facebook toch echt niet veilig zijn, terwijl het eigenlijk veel generieker is dan dat.

Jammer dat er zovaak FUD het internet op wordt gepushed. De conclusie kan ook zijn:
Google, Facebook en OpenID zijn weer een stap veiliger gemaakt.

Dat dingen niet onkraakbaar zijn is ondertussen geen geheim, het gaat er vooral om hoe bedrijven/leveranciers hier mee omgaan...
Maak DigiD niet ook gebruik van een dergelijk mechanisme?

Je logt in op digid.nl maar krijgt credentials voor (bijv. belastingdienst.nl)

En hoe veilig is dat dan nog?
Het principe is gewoon veilig, alleen had blijkbaar deze specifieke implementatie last van een beveiligingslek.
en last van een "slappe" certificaat verstrekker.
DigID is op zich niet verkeerd (het kan altijd beter...maar het moest toegankelijk blijven voor iedereen) ....op papier is het een prima methode , maar als je certificaat verstrekker nooit van firewall en antivirus heeft gehoord heb je alsnog een probleem.
Ik heb die manier van inloggen nooit echt vertrouwd en maak het liefst een losse account aan. Behalve bijvoorbeeld bij Spotify, maar daar kon het niet anders!

---
Ars Technica heeft vaak leuke artikelen maar ik vind de indeling om te janken en kom er dus altijd alleen op via tweakers of andere websites.
Volgend artikel: "2012 wederom is alles te kraken" :P
Ik hou er ook niet van, ik heb een mailaccount om mee te mailen en een facebook account om mee te facebooken, dat mag van mij prima gescheiden blijven. Sterker nog, liever gescheiden dan alles maar aan elkaar knopen. Als iemand dan toegang krijgt tot je account ben je ook meteen alles kwijt, zeg maar.

Op dit item kan niet meer gereageerd worden.



Populair: Vliegtuig Luchtvaart Crash Smartphones Laptops Google Apple Games Politiek en recht Rusland

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013