'Exploit maakt overnemen Google-accounts mogelijk, ook na wijzigen wachtwoord'

Beveiligingsbedrijven Hudson Rock en CloudSek waarschuwen voor een zerodaykwetsbaarheid waarmee het mogelijk is om verlopen sessiecookies van Google Chrome-accounts te herstellen. Hierdoor kunnen kwaadwillenden toegang krijgen tot die accounts, zelfs nadat de gebruiker het wachtwoord heeft veranderd.

Er zijn meerdere malwarefamilies in omloop die het autorisatieprotocol OAuth2 kunnen uitbuiten, schrijven Hudson Rock en CloudSek. Hiermee is het mogelijk om continu eerdere, geldige sessiecookies te regenereren. Deze cookies bevatten authenticatie-informatie en dienen om de gebruiker automatisch in te laten loggen op websites en diensten, zonder dat ze telkens hun gegevens hoeven in te vullen. Normaliter is het de bedoeling dat deze cookies slechts tijdelijk toegankelijk zijn, en niet langer werken als gebruikers hun inloggegevens veranderen. Met deze exploit kunnen kwaadwillenden echter, als ze eenmaal toegang hebben gekregen tot een Google Chrome-account, deze ongeautoriseerde toegang blijven behouden, dus ook nadat de gebruiker het wachtwoord verandert, uitlogt of nadat de sessie is verlopen.

De onderzoeksteams hebben de exploit vorige maand gevonden in de Infostealer-malware van Lumma. Daardoor kwamen ze erachter dat de kwetsbaarheid zich bevindt in de Google oAuth-endpoint MultiLogin. Met dat mechanisme worden Google-accounts van meerdere diensten met elkaar gesynchroniseerd middels een vector aan account-ID's en inlogtokens. Als Infostealer op een desktop is geïnstalleerd, kan deze malware de endpoint misbruiken door er de tokens en ID's uit te filtreren. Die kunnen vervolgens ontsleuteld worden door de encryptiesleutel te gebruiken die is opgeslagen in het Local State-bestand van Chrome. Met de account-ID's en tokens is het vervolgens mogelijk om een verzoek te sturen naar de MultiLogin-api waarmee de sessiecookies geregenereerd kunnen worden.

CloudSek heeft de exploit gereverse-engineerd en wist deze zelf te gebruiken om verlopen cookies te herstellen, laat het beveiligingsbedrijf aan Bleeping Computer weten. Het bedrijf stelt wel dat de cookies na het wijzigen van het wachtwoord, slechts eenmalig geregenereerd kunnen worden. De toegang tot het account kan na een wachtwoordwijziging dus niet lang meer worden behouden.

De exploit zou actief worden uitgebuit. Dat gebeurt overigens niet alleen door Lumma, ook andere malwaregroepen zouden de kwetsbaarheid inmiddels in hun voordeel gebruiken. Er zijn tot dusver naar verluidt minstens zes groepen bezig met het regenereren van Chrome-cookies. Google heeft nog niet laten weten op de hoogte te zijn van de zerodaykwetsbaarheid. De exploit is op het moment van schrijven dan ook nog niet gedicht.

Een hacker heeft bovenstaande video waarin de exploit wordt gedemonstreerd, gedeeld met de beveiligingsbedrijven

Reacties (107)

[GNID]

[...] waarmee het mogelijk is om verlopen sessiecookies van Google Chrome-accounts te herstellen.

Wat is dan weer een Google Chrome-account? Geen enkele andere bron noemt dit verder.
(Gebruik zelf geen Google Chrome, dus oprecht geen idee ..)

[R4gnax]

Als je Google Chrome gebruikt en je logt in op een dienst van Google, dan log je ook automatisch mee in op de lokale Chrome browser met dat account en vice versa. Dit is een soort van federated universele login over alle Google diensten heen. Ook je lokale bookmarks etc zijn op dat moment gekoppeld aan je Google account en worden mee gesynchroniseerd over al je apparaten heen waar je met dat account ingelogd bent, als een soort van roaming profiel.

Microsoft doet hetzelfde met MS accounts en Edge.

Als je daar geen trek in hebt (wat heel makkelijk denkbaar is) dan kun je in beide gevallen de browser zo configureren dat het lokale profiel losgekoppeld wordt van de online accounts van de respectievelijke dienstaanbieder. Daarna wordt het lokale profiel opnieuw als een anoniem 'profiel #1' o.i.d. aangegeven.

Let alleen wel even op; als je dat bij Chrome doet dan wordt alle lokale staat v/h profiel; dus browsing historie, bookmarks, form autofill, etc. ook mee gewist. Backup maken voor je ontkoppelt, zodat je het allemaal weer terug kunt zetten, dus.


Geen idee overigens of je nog steeds voor deze exploit / vulnerability ontvankelijk bent als je deze koppeling al ongedaan gemaakt hebt.

[Reactie gewijzigd door R4gnax op 23 juli 2024 02:51]

[Kees]

Veel belangrijker, de autofill neemt ook wachtwoorden mee, dus met dat account kun je weer andere accounts overnemen, zelfs als die niet gekoppeld zijn aan het bijbehorende gmail adres.

[R4gnax]

Klopt. Zeer belangrijke aanvulling.

Dit strekt mogelijk veel, veel verder dan enkel Google accounts.
In principe is iedereen die gebruik maakt van password autofill in Chrome, hiermee waarschijnlijk ook compleet de bok met al die andere accounts waarvoor wachtwoorden opgeslagen liggen. Want als je eenmaal afdoende toegang hebt om de Google account tokens te decrypten, kun je dat waarschijnlijk ook met de wachtwoordkluis flikken.

Helaas is je post een directe reply op de mijne, dus ik kan je geen plus-punten geven middels het moderatiesysteem. Maar je hebt compleet gelijk. Dit zou wel eens een groot risico kunnen zijn.

[Reactie gewijzigd door R4gnax op 23 juli 2024 02:51]

[Llopigat]

Oef, ik ben blij dat ik alleen Firefox gebruik (en een aparte wachtwoord manager).

[telenut]

Omdat de browser ze kan invullen wil dit nog niet zeggen dat je ze ook kan weergeven...

[Jrz]

In chrome kan je ze gewoon bekijken.

In de devtools kan je ze ook gewoon ophalen

[telenut]

ha, eens getest met de devtools, en eens ze ingevuld zijn kan je ze idd wel bekijken

[IHVD]

Gewoon de html broncode aanpassen in het input-fieldje, "type" van "password" naar "text" en je weet zo je eigen wachtwoord weer nadat chrome em AutoFilled voor je

[telenut]

Idd. Zo deed ik het :-)

[anboni]

Als de browser ze kan invullen, zijn ze middels reversible encryption opgeslagen. Dat is dus te kraken en dus ook weer te geven.

[telenut]

vandaar het niet slecht is Windows Hello bijvoorbeeld hier ook op te activeren. Dan vult hij het pas in na verificatie.

[Bor]

Dan zijn ze alsnog met reversible encryption opgeslagen. Dat is ook de enige manier hoe auto fill van onveilige authenticatie methoden als username / password combinaties kan werken.

[telenut]

in een TPM chip, die zijn zover ik weet nog niet gekraakt toch...

[Bor]

De wachtwoorden worden niet opgeslagen in de TPM chip hoor. Zo lang je auto fill wilt gebruiken zal je de wachtwoorden ofwel leesbaar (zeer onveilig) of met reversible encryption moeten opslaan. De encryption key kan je met Windows Hello vrijgeven maar dan nog blijft het reversible. Je kan immers anders geen leesbare tekst terughalen uit de ciphertext.

[telenut]

Als je het goed doet moet je nog 2fa gebruiken om deze functie te starten. Is bij mij alvast zo.

[laptopleon]

Dit is waarom het een goed idee is om een wachtwoordmanager te gebruiken en verder nooit wachtwoorden automatisch in te laten vullen (dus te laten onthouden) door browsers, plugins en andere 'handige' functies van je OS. Niet dat ww-managers onfeilbaar zijn, maar dan heb je tenminste maar één zwakke plek in plaats van meerdere.

[beerse]

In het algemeen is het goed om in ieder geval bewust voor een bepaalde wachtwoordmanager te kiezen. Of zoals ik dat doe met meer dan 1:
De 'eenvoudige' accounts van losse websites gaan bij mij gewoon in de wachtwoord manager van de browser. In de regel zowel in firefox als ook in Chrome/Android/Google. Vooral voor het gemak. In de regel doe ik mijn best om die ook in BitWarden te zetten.
De wat meer serieuze accounts, bijvoorbeeld als er een financieel belang bij zit (webwinkels en zo) gaan in BitWarden.
Mijn echt belangrijke accounts gaan in SafeInCloud.

[laptopleon]

Maak je me toch nieuwsgierig. Als je toch al een of twee aparte / dedicated ww-manager(s) geïnstalleerd hebt, waarom dan toch nog een (of eigenlijk meerdere) browser-ww-managers gebruiken? Wat is daar het voordeel van, alleen dat je dan bij het aanmaken die niet in je ww-manager hoeft te zetten? Maar dat gaat toch vaak al zo goed als automatisch / met een keyboard shortcut?

En is dit niet juist tijdrovender omdat je vroeg of laat waarschijnlijk een ww wil of moet aanpassen en je het dan in Firefos / Chrome / Bitwarden / oftewel meerdere plaatsen moet aanpassen?

En wat is het voordeel van het werken met twee verschillende, aparte ww-managers? Vertrouw je de ene meer dan de andere?

[beerse]

Het gebruik van de browser-geïntegreerde ww managers is dat ze er altijd en op elk apparaat zijn zodra ik daar de sync aan zet. En ze werkt ook betrekkelijk snel. Daarbij toegegeven dat chrome, chromium, android en chromebook allemaal de zelfde zijn: DrGoogle.

En dat van die 2 aparte ww managers is dat ik ooit begonnen ben met Safe-In-Cloud. Die kwam toen best goed uit de verf. Daarmee staan daar 'alle' wachtwoorden in. Maar de integratie in de browsers is daar niet naar mijn idee en ook de beschikbaarheid op andere platformen is voor mij te beperkt.

Daarmee ben ik ooit begonnen om over te stappen naar BitWarden. Maar ondertussen durf ik niet meer te zeggen dat ik aan het overstappen ben, dat loopt nu al ruim een jaar.

Over het aanpassen: De geïntegreerde managers zien zelf heel snel dat ze veranderd zijn. Het is vooral opletten of ze het over een nieuwe entry hebben of over een bestaande. En andersom: als inloggen even niet lukt, dan de andere integratie gebruiken: de add-ons verschijnen rechts boven, de browsers bij het login veld.

En nu ik er aan denk: zakelijk gebruik ik KeepAss. De autotype mogelijkheden daar heb ik elders nog niet aangetroffen.

[Reactie gewijzigd door beerse op 23 juli 2024 02:51]

[laptopleon]

Je kunt de data dumpen in een .cvs bestand en weer importeren in een andere ww-manager.

Eventueel kun je de volgorde veranderen met een tekst-editor met regex. Het is even puzzelen als je dat voor het eerst doet maar ook wel weer leuk omdat het zo krachtig is.

Ik heb 1Password een paar jaar gebruikt, overgestapt op LastPass en nu alweer jaren Enpass. Allemaal kunnen ze – of konden ze toen ik ze gebruikte – werken op alle populaire platforms en browsers én lokaal.

Ik ben overgestapt omdat ik het toen te duur vond worden en je het gebruiksrecht niet eenmalig kon afkopen. Bij Enpass kan dat wel. Maar intussen is de € 3 die je voor de goedkoopste 1PW licentie kwijt bent, aanzienlijk minder waard. Cijfers van 2023 liggen nog niet vast maar minimaal 28% minder, eerder 35%.

[Fermion]

maar is dit hetzelfde als het hebben van een gmail account ?

[R4gnax]

Nee. Het is niet hezelfde.

Er wordt misbruik gemaakt van een persistent token dat alleen bestaat als je Chrome gebruikt en in de Chrome browser zelf ingelogd bent met je Google account, waardoor je automatisch ook ingelogd bent in alle Google services. Het is specifiek het speciaal voor die functionaliteit opgerichte endpoint met de naam 'Multi-login' dat uitgebuit wordt.

Jammer genoeg is dat universeel inloggen iets wat Google standaard twee zijden op werkend heeft.

Als je een Gmail account hebt en er ooit ergens op een Chrome browser mee ingelogd bent waar die universele-login functionaliteit voor Google diensten niet expliciet uitgezet is (voor zover dat kon - want die mogelijkheid is pas een paar versies na deze initieel opgedwongen functionaliteit toegevoegd, onder protest van gebruikers); of waar je er niet zeker van bent dat deze uit stond, dan mag je je account als compromiteerbaar beschouwen.

Als je dit ooit gedaan hebt op een gedeeld apparaat wat niet meer direct onder je eigen beheer valt, zou het wijs zijn om je account ook maar direct als daadwerkelijk gecompromiteerd te beschouwen. Dwz. wachtwoord wijzigen en alle diensten waarover ooit communicatie inzake inlog of recovery van in je mail beland is, en waar geen gescheiden 2FA op zit, ook als gecompromiteerd te beschouwen en - wederom - wachtwoord te wijzigen.


Overigens; het zou zomaar kunnen dat zelfs als je Google account met 2FA beveiligd is, deze exploit alsnog toegang biedt. Het lijkt er namelijk op dat met het speciale refresh token in bezit, je gewoon een compleet werkend access token terug krijgt, zonder dat 2FA opnieuw gecheckt wordt. Er is in de nieuwsartikelen vziw ook geen melding van gemaakt dat 2FA prompts e.e.a. nog af zouden schermen.

[Reactie gewijzigd door R4gnax op 23 juli 2024 02:51]

[Fermion]

Maar dan zou expliciet overall uitlogen de eerdere uitgeven cookies tijden het inloggen op een vreemd apparaat toch onbruikbaar moeten maken?

[R4gnax]

Zou, inderdaad. Maar dat lijkt dus niet zo te zijn.
De cookies die de sessie tokens bevatten worden misschien onklaar gemaakt en/of verwijderd, maar er blijkt binnen Chrome ergens nog een token opgeslagen te blijven liggen wat gebruikt kan worden om nieuwe tokens te maken voor die sessie en vrolijk verder te gaan.

[Reactie gewijzigd door R4gnax op 23 juli 2024 02:51]

[The Zep Man]

Dit beantwoordt de vraag van @GNID niet.

Wat is dan weer een Google Chrome-account?

Een Google Chrome-account is een term verzonnen door T.net, wat staat voor een Google-account dat gebruikt wordt om in Chrome in te loggen. Hoe dat werkt wordt omschreven door @R4gnax.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 02:51]

[Vuurvleugelhart]

Enkel als aanvulling: Google heeft het ook zo gemaakt, dat de meeste mensen nog niet eens doorhebben dat zij ingelogd zijn tijdens het gebruik van Chrome.
Ook dat lees je hier nooit terug.

[Frame164]

Met de desktop browser is dat prima te zien in de rechterbovenhoek.

[tom.cx]

Het zal je verbazen hoeveel mensen dit over het hoofd zien. Zelfs in het oranje of rood 'update' rechtsboven in de hoek zien ze over het hoofd. Dan vallen twee letters al helemaal niet op :-).

[PdeBie]

Veel mensen valt dat niet eens op.

[ronaldvr]

Als je daar geen trek in hebt (wat heel makkelijk denkbaar is) dan kun je in beide gevallen de browser zo configureren

Of gewoon Firefox gebruiken ...

[R4gnax]

Niet iedereen zal misschien bereid zijn om compleet van browser te switchen; en dan is het makkelijk om een laagdrempelig en gelimiteerd alternatief te hebben. Niet?

[ronaldvr]

Nou er zijn uiteraard ook méér redenen om geen Chrome te gebruiken:

Google is protecting your privacy like a wolf would protect sheep - Google Chrome will limit ad blockers starting June 2024

Not as private as you thought - Google agrees to settle Chrome incognito mode class action lawsuit 2020 lawsuit accused Google of tracking incognito activity, tying it to users' profiles.

Om er maar zo snel even 2 te pakken uit de legio redenen

[pepsiblik]

Tegenwoordig kun je op je browser inloggen. Niet alleen bij Chrome. Dan kun je settings, favorieten etc, synchroniseren.

[Jaatoo]

Voor zover ik weet heeft Google-Chrome helemaal geen accounts. Ik denk dat er bedoeld wordt dat iemand met een Google account op de Chrome browser is ingelogd (dus op de browser zelf bijvoorbeeld om bookmarks te delen, niet een webpagina die in de browser is geopend).

Deze doet waarschijnlijk eens in de zoveel tijd een request naar Google met de genoemde ID en Token om de authenticatie/gebruikersgegevens up to date te houden. Deze kunnen dan uit dat specifieke request (niet uit elke request naar elke willekeurige website?) gehaald worden en met een specifieke encryptie sleutel die lokaal staat opgeslagen ontsleuteld worden.

Daarmee is het voor zover ik begrijp een issue specifiek gerelateerd aan Google Chrome, en niet aan Google accounts in het algemeen, of oAuth. Maar wel een waarmee volledige toegang tot een Google account verkregen kan worden.

Ik vindt het artikel wat verwarrend beschreven, maar dit is wat ik er van heb begrepen.

[Reactie gewijzigd door Jaatoo op 23 juli 2024 02:51]

[klonic]

Met accounts kan dit bijvoorbeeld over Outlook online gaan? Maar ik neem aan dat je met een 2-FA veilig bent, zolang die sessie beëindigd is natuurlijk. Gelukkig, of in dit geval helaas, heb ik voor de meeste diensten geen 2FA.

Echter gebruik ik ook geen Chrome.

[Reactie gewijzigd door klonic op 23 juli 2024 02:51]

[REDSD]

Bij Oauth krijg je een token na de 2fa, die token zou beperkt geldig moeten zijn, bijvoorbeeld een dag of korter. Vaak zit er dan nog een overlap in waarin de gebruiker nog actief is er een nieuwe token opgehaald kan worden zonder opnieuw in te loggen.

Je zou dus in principe met zo een gekaapte sessie best lang iemand zijn account kunnen gebruiken ongeacht je veiligheidsmaatregelen.

[GertMenkel]

Zolang je het token maar blijft vernieuwen zou je tot in de oneindigheid toegang kunnen krijgen. Ik kan me niet heugen ooit opnieuw te hebben moeten inloggen op. Google Chrome zelf, hooguit de diensten binnen Chrome.

[bazzi]

Theoretisch kan je met oauth2.0 een limiet op de refresh token zetten EN op de sessie. Kortom je kan zeggen elke dag een refresh en dat voor max 30 dagen.

[winos]

Doel je hiermee op een TTL cookie bij een (s)sso flow?

Wat mij extreem verbaasd is dat er waneer je toegang hebt, nooit re-auth plaatsvind wanneer je in een SAAS applicatie komt waarbij je gevoelige info wilt zien/aanpassen.

Azure ondersteund dit gewoon maar het is momenteel volledig afhankelijk van de SAAS leverancier of ze deze functie hebben. Een simpele pin, Windows Hello ID, of vingerafdruk zou voldoende kunnen zijn zodat de eindgebruiker een minieme handeling moet verrichten.

Wat mij verder opvalt is dat leveranciers er nooit over nagedacht hebben en wanneer je ze dit verteld ze je met grote ogen aankijken.

[hoi1234]

Heb er geen verstand van hoor. Maar in principe zou 2FA toch niet nodig zijn dan?

Je kunt jouw device als "veilig" markeren. Dan hoef je bijvoorbeeld 30 dagen geen 2FA meer te gebruiken. Lijkt mij dat dat in een vergelijkbare cookie als in dit artikel wordt bijgehouden en daarmee ook misbruikt kan worden?

[sammyke007]

Is dat vandaag de dag niet een beetje een minimum aan veiligheid dat je 2FA gebruikt?
Toch zeker met je mailbox zou ik zeer voorzichtig zijn. Als je in iemands mailbox zit vandaag de dag kan je gevaarlijk veel info vergaren over iemand...

[R4gnax]

Het is maar de vraag of 2FA hier zou helpen.
De exploit komt er op neer dat je een reeds bestaande en geauthenticeerde sessie die eigenlijk beeindigd had moeten zijn, nieuw leven in kunt roepen en kunt hijacken.

Vermoedelijk komt er helemaal geen 2FA prompt meer bij kijken omdat je op dat moment gewoon al een gevalideerde login hebt die geauthenticeerd en geauthoriseerd is.

[sygys]

Maar als ik het goed begrijp moet je wel als hacker fysiek bij de cookies kunnen van het slachtoffer neem ik aan?

[R4gnax]

Malware moet met lokale gebruikersrechten kunnen uitvoeren. De bestanden waar de malware aan moet kunnen, staan gewoon in AppData. Dus de malware zal geen administratorrechten hoeven te verkrijgen.

[tedades]

Beveiliging hangt vaak ook af van de zwakste schakel. Als je 2FA gebruikt met SMS kan het soms makkelijker zijn om een account over te nemen. Als een hacker toegang heeft tot SS7 (Signaling System 7) kunnen ze de 2FA SMS bekijken.
https://en.wikipedia.org/wiki/Signalling_System_No._7
https://www.firstpoint-mg.com/blog/ss7-attack-guide/

Wat ik merk is dat 2FA, ook al is het via SMS, het ook weer makkelijk maakt om een aanval te ontdekken en je account terug te krijgen. Want tegenwoordig is het praktisch onmogelijk om met een grote club (zoals outlook, gmail) contact te krijgen voor hulp in dit soort gevallen.

[CAPSLOCK2000]

Maar ik neem aan dat je met een 2-FA veilig bent, zolang die sessie beëindigd is natuurlijk.

Nee. 2FA helpt niet. De fout grijpt in op een punt dat je al voorbij de (2F)Authenticatie controle bent. De exploit weet zo'n sessie open te houden.

Strict genomen heb je gelijk dat je veilig bent áls de sessie is beëindigd maar dat lukt nou net niet. De exploit houdt zo'n sessie open. Er moet wel eerst een sessie zijn. Als je nooit inlogt bij Google dan kan je ook niet onderschept worden, maar dan heb je ook niet veel aan je account (ik ga even heel kort door de bocht).

Echter gebruik ik ook geen Chrome.

Ik heb geen idee wat een "google chrome account" is en of/hoe dat verschilt van een "normale" Google account. Als ik het zo lees zit de bug in de servers van Google, niet in de browser Chrome. Het gaat om een dienst die gebruikt wordt door Chrome maar er volgens mij geen onderdeel van is. Ik denk dat de bug in praktijk alleen voorkomt bij Chrome maar daar niet van afhankelijk is.

[Guru Evi]

Technisch gezien is dit geen exploit maar gewoon een deel van het protocol. OAuth2 providers weten niet van je wachtwoord (het is ontworpen om geen wachtwoorden te moeten delen met een cliënt noch een provider, enkel met de authorization server) noch dat je wachtwoord veranderd is.

In principe moet er dus iets toegevoegd worden waardoor een OAuth2 server met zowel een provider als cliënt kan delen dat alle sessies verworpen moeten worden los van elkaar. Daar zit dus een hoop haken en ogen aan ivm privacy, beveiliging etc (wie initieert er, wanneer, hoeveel berichten, authenticatie etc), net zoals het terugtrekken van een TLS certificaat grotendeels niet gedeeld wordt voor dezelfde redenen.

Aan de andere kant zouden session cookies niet mogen loshangen zonder ofwel netwerk of apparaat attestatie (netwerk = IPv4/IPv6 adres voor publieke systemen, DNS of MAC adres voor interne systemen of apparaat = TPM2, YubiKey, TouchID etc) alhoewel dit niet verplicht wordt door het protocol is het tegenwoordig wel nagenoeg nodig dat je kunt cryptografisch bewijzen welke apparaten je wilt gebruiken naast je eigen identiteit.

Maar praktisch gezien is dit nog steeds moeilijk, Windows 11 en macOS sinds versie 10.12 hebben dit al, maar Android, Windows 7/10 nog niet en Linux kan het al heel lang, maar weinig mensen die weten hoe dit moet, distros zoals Red Hat 9 zijn er maar net mee begonnen terwijl Ubuntu de tpm2-tools nog steeds niet ‘standaard’ installeert en GUIs, browser integraties etc zijn ook niet of moeilijk te vinden.

[Reactie gewijzigd door Guru Evi op 23 juli 2024 02:51]

[R4gnax]

Hier wordt omheen gewerkt doordat je een access token hebt en een refresh token.

Beiden hebben een vaste time to live en zodra het access token verloopt maar het refresh token nog niet verlopen is, kan dat laatste gebruikt worden om een nieuw access token en een nieuw refresh token aan te vragen bij de authorization server.

De authorization server is de enige die het refresh token hoeft te kunnen valideren. Voor alle andere partijen is dat token gewoon een black box. Sterker nog: zij zullen dat refresh token wss niet eens te zien krijgen. Zij hebben in principe aan alleen het access token genoeg, en gebruiken dat aan hun kant om bijv. van de authorization server claims over de account boven te krijgen of weg te schrijven.

De authorization server is dus ook de enige partij die openstaande nog niet verlopen refresh tokens bij hoeft te houden. En die refresh tokens kan schrappen zodra de gebruiker expliciet een sessie eindigt door uit te loggen, of zodra ze hun time-to-live overschreden hebben.

In het slechtste geval betekent dit dat criminelen die een refresh token weten te jatten waar een gebruiker niet uitlogt, een kleine window of opportunity hebben waarmee ze nog heel even toegang kunnen krijgen tot een account - in de periode tijd totdat het refresh token verloopt.

Dat is dan ook waarom je als applicatieontwikkelaar voorafgaand aan gevoelige operaties zoals wijzigen wachtwoord; wijzigen 2FA gegevens; toegang tot bijzondere persoonsgegevens; etc. eigenlijk altijd om herauthenticatie moet vragen, zodat er niet van een gestolen access token of een gestolen refresh token en valselijk gegenereerd access token gebruik gemaakt kan zijn.

En waarom je als authorization server altijd een strakke termijn voor de geldigheid van refresh tokens moet hanteren.

Het is dat laatste dat Google schijnbaar niet gedaan heeft.
Dat; of via hun 'multi-login' endpoint kun je de check voor het verlopen zijn omzeilen.

[Reactie gewijzigd door R4gnax op 23 juli 2024 02:51]

[Guru Evi]

Ik ben inderdaad bekend met OAuth, echter als je de tokens kunt achterhalen kun je overal authenticeren. Zowat alle providers doen dit, Dropbox, Google, Microsoft. Kun je best tewerkgesteld zien in oa. RClone authenticatie, de tokens worden opgeslaan in een JSON en zolang je binnen 30 dagen refreshed krijg je een nieuw token, in een browser zitten die tokens vaak in cookies of localStorage. Je kunt dezelfde JSON gewoon kopiëren op een andere server en zelfs in gedeelde bestandssystemen zetten, het werkt (rclone headless) zolang geen 2 cliënten dezelfde refresh token gebruiken op hetzelfde moment. Zelfs als je paswoord verandert, in geen enkele van de bovenstaande diensten vervallen de refresh of authenticatie tokens.

Daarmee dat ik zeg dat het OAuth protocol op zichzelf daar geen bescherming op biedt want er zijn geen authenticatie tokens die zich afleiden van vb de hardware van de cliënt zelf, enkel de tokens tussen de applicaties en als je die kunt stelen kun je de refresh token blijven gebruiken om een nieuwe te krijgen. Je moet ideaal een twee-wegen authenticatie hebben, cliënt naar server en server naar cliënt.

[Reactie gewijzigd door Guru Evi op 23 juli 2024 02:51]

[Boender]

Nee, je bent niet veilig met 2fa. De sessie staat dat je geautomatiseerd bent. Dit is een exploit dat veel wordt gebruikt bij het overnemen van youtube kanalen. Hier een uitleg van die hack: https://youtu.be/yGXaAWbzl5A?feature=shared

[Yellow]

Het feit dat kwaadwillenden toegang kunnen krijgen tot Google-accounts, zelfs na het wijzigen van het wachtwoord, is eng. Hopelijk volgt er snel een update van Google.

[naaitsab]

Wat ik enger vind is dat sessie tokens nog steeds zo kinderlijk eenvoudig hergebruikt kunnen worden bij onwijs veel diensten/bedrijven. Minimaal een verbintenis aan je WAN-IP (lastig te spoofen zonder extra malware op de PC van het slachtoffer) en bepaalde info die je sessie uniek maakt. Uiteraard is alles te spoofen met maar het maakt het al een heel stuk lastiger en dus minder interessant om informatie an masse te verkopen op het darkweb. Zeker als sessie lifetime drastisch teruggeschroefd wordt.

Lijkt me hoog tijd dat hier een bepaalde security baseline voor verplicht gaat worden, zoiets als men heeft gedaan met SSL. Nu hoop je maar dat een bedrijf de tokens goed checked. Waarbij we bij Google weten dat ze dat dus niet doen. Denk aan de LTT Youtube hack.

Aan de andere kant vraag ik me ook nog steeds af waarom anno 2023 een derde überhaupt zo eenvoudig toegang kan krijgen tot deze tokens op je machine. Dit zou iets zijn wat volledig afgeschermd/encrypted/sandboxed moet draaien en niet zomaar losjes huist in je appdata mapje waar elke applicatie of malafide browser plugin bij kan. Daardoor kan je nu zonder admin rechten/popup alle tokens van een PC halen met een simpel script.

[bzzzt]

Minimaal een verbintenis aan je WAN-IP (lastig te spoofen zonder extra malware op de PC van het slachtoffer)

Leuk voor je glasvezel verbinding in Nederland waar je vaak nog een soort van vast IP hebt, maar mobiele netwerken en grote delen van de wereld met IP tekorten zitten meestal achter CNAT waardoor je beveiliging onwerkbaar wordt als je iedere IP wissel opnieuw moet authenticeren.

Het probleem met toegang tot tokens is ook niet zo eenvoudig op te lossen. Browsers moeten er bij kunnen om de token te kunnen doorgeven. Je zou iets met de TPM kunnen bedenken maar ik vraag me af of je niet vertrouwde websites daar toegang toe wil geven.

[naaitsab]

Klopt maar het grote voordeel van mobiel is dat je vrij eenvoudig opnieuw zou kunnen inloggen met biometrie. Helemaal voor diensten als mail en banken lijkt me dat een prima afweging om elke keer bij het openen verplicht in te loggen. Of diensten die zoals dit artikel omvat een 'spiderweb' login systeem toelaten. 1 Google login en je komt bij een heel scala aan diensten binnen. Handig maar security technisch redelijk kansloos.

Voor de tokens zou een website hier wel toegang toe kunnen krijgen, je browser 'bind' de token al aan een bepaalde site/actie. Het gaat er meer om dat buiten je browser op je lokale device er nu kinderlijk eenvoudig misbruik van gemaakt kan worden. Waarbij een hele dump van alles tokens plaats vindt. Je zou kunnen denken aan een soort sandbox waarbij alleen een gesignde exe (de browser) bij de data kan. Immers heeft verder niks anders daar iets te zoeken. Browserextenties die ook tokens delen, denk aan een VPN app die gaan dan wel stuk of die moeten afgedwongen worden dat ze alleen relevantie sessie tokens (dus voor enkel voor de benodigde site of 2-3). Dan kan er ook geen hele dump meer gemaakt worden. Net als het WAN-ip verhaal zal eenvoud wel het slachtoffer (moeten) worden voor security. Zoals het systeem nu is, dat lijkt me niet houdbaar.

[bzzzt]

Klopt maar het grote voordeel van mobiel is dat je vrij eenvoudig opnieuw zou kunnen inloggen met biometrie. Helemaal voor diensten als mail en banken lijkt me dat een prima afweging om elke keer bij het openen verplicht in te loggen.

Voor banken: sure. Voor mail: hangt er van af. Bovendien leun je op mobiel sowieso ook al op de platform beveiliging, heeft niet zoveel zin om naast de face scan om je mobiel te ontgrendelen dan ook nog een face scan per app in te voeren.

Of diensten die zoals dit artikel omvat een 'spiderweb' login systeem toelaten. 1 Google login en je komt bij een heel scala aan diensten binnen. Handig maar security technisch redelijk kansloos.

Security technisch kan je beter een 'single sign on' account hebben wat goed beveiligd is dan een scala aan accounts die dat niet zijn. Bovendien kent OAuth het concept van 'scopes' waarbij je voor specifieke diensten opnieuw of met aangescherpte policy moet inloggen - het wordt alleen weinig gebruikt vanwege technische complexiteit.

Je zou kunnen denken aan een soort sandbox waarbij alleen een gesignde exe (de browser) bij de data kan. Immers heeft verder niks anders daar iets te zoeken.

Wat je nou omschrijft is precies wat een TPM doet. Als je aanvalsscenario uitgaat van een gecompromitteerd OS is het enige wat je kan doen het vertrouwen naar een andere machine (of subprocessor) te verplaatsen.

[System]

Is simpel op te lossen.
Een oauth bestaat uit een bearer token en een refresh token.
Als de bearer vervalt heb je de refresh nodig om die te hernieuwen.
Als een nieuwe login gebeurt, dus nieuwe refresh, zou de oude moeten vervallen.
Bovendien zou je bij WW wijziging of zo altijd de 2fa moeten vragen wat ook niet altijd gebeurt.

[Reactie gewijzigd door System op 23 juli 2024 02:51]

[bzzzt]

Zo simpel is het dus niet.
Ik neem overigens aan dat je "bearer token" bedoelt.

De kracht van OAuth tokens is dat ze cryptografisch zijn ondertekend zodat je verzoeken kan authenticeren zonder steeds aan een centraal systeem te vragen of iemand iets mag. Dat heeft grote voordelen voor de beschikbaarheid omdat een service die er niet is ook geen point of failure kan zijn.
Een token laten vervallen betekent dat je alsnog een centrale dienst moet gaan bevragen of een token niet vervallen is en het voordeel verliest. De "oplossing" uit de OAuth community is: gebruik een korte looptijd voor tokens. En dat is nou net het probleem met die Google tokens.

[System]

oeps, bearer idd, stomme auto correct
Wij passen de refresh token idd toe via een centraal systeem.
Zodra dat centraal systeem jouw refresh laat vervallen is het opnieuw inloggen.
Op die manier kan je ook vanop afstand apparaten laten uitloggen.
En idd, wij laten de bearers elke 5min vervallen.

[Reactie gewijzigd door System op 23 juli 2024 02:51]

[bzzzt]

Puur uit interesse: waarom gebruik je dan überhaupt OAuth?

[System]

Omdat het moet.

[R4gnax]

Het probleem met toegang tot tokens is ook niet zo eenvoudig op te lossen. Browsers moeten er bij kunnen om de token te kunnen doorgeven. Je zou iets met de TPM kunnen bedenken maar ik vraag me af of je niet vertrouwde websites daar toegang toe wil geven.

FIDO U2F, FIDO passkeys, en de WebAuthn APIs in browsers doen dit al.
Windows 10 en Windows 11 hebben beide vziw een proxying FIDO-compatible authenticator aan boord waar één van de keuzes voor de afhandeling een virtuele authenticator is die binnen een secure desktop sessie draait (zoals UAC prompts) en die de TPM als backing storage gebruikt.

[Reactie gewijzigd door R4gnax op 23 juli 2024 02:51]

[bzzzt]

Het kan vast allemaal maar het is ontzettend ingewikkeld en 99% van de typische eindgebruikers snapt er gewoon helemaal niets van.

[R4gnax]

Voor eindgebruikers is de ervaring eigenlijk net zo simpel als gebruikersnaam/wachtwoord invoeren.

[R4gnax]

Aan de andere kant vraag ik me ook nog steeds af waarom anno 2023 een derde überhaupt zo eenvoudig toegang kan krijgen tot deze tokens op je machine. Dit zou iets zijn wat volledig afgeschermd/encrypted/sandboxed moet draaien en niet zomaar losjes huist in je appdata mapje waar elke applicatie of malafide browser plugin bij kan. Daardoor kan je nu zonder admin rechten/popup alle tokens van een PC halen met een simpel script.

Omdat Google de installatie van Chrome zo laagdrempelig mogelijk wilde maken om marktaandeel te winnen.

Als het in AppData gedumpt wordt, heb je geen admin rechten nodig om het te installeren. Wat betekent dat er geen UAC prompts op komen zetten die de niet-technisch gebruiker doen wegschrikken. En wat betekent dat ook zakelijk mensen op eigen houtje Chrome op werk PCs konden installeren, tenzij sysadmins specifiek policies opgezet hadden om zaken verder te blokkeren dan medewerkers simpelweg geen adminrechten geven, waar het in die tijd vaak eigenlijk wel bij bleef mbt dichttimmeren.

[Cegax]

Dit wordt als nieuws gebracht maar is al oud..... In 2022 heeft Google al een schrijven uitgebracht waarin het probleem wordt benoemd en wat de beste workaround is. Bron. https://cloud.google.com/...ating-gcloud-oauth-tokens

[R4gnax]

Dit gaat over Google Cloud CLI en mitigations en best practices om schade te voorkomen mocht een developer machine overgenomen worden en op die manier access tokens gestolen kunnen worden.

Heeft niets van doen met het feit dat Google long-lived access tot Google accounts mogelijk heeft gemaakt in Google Chrome, zelfs nadat sessies al beeindigd zijn. Dat is gewoon een security bug.

[Cegax]

Staat duidelijk omschreven dat de de Api's 60 minuten actief blijven, ook na het wijzigen van het wachtwoord of uitloggen. Dat is precies waar ze het hier over hebben.

[kodak]

Zoals @R4gnax al opmerkte, de omschrijving gaat niet zomaar om deze situatie omdat het cloud computing platform een aparte dienstverlening is.

Natuurlijk is het mogelijk dat google er zelf ook gebruik van maakt om hun klanten van chrome-accounts toegang te geven. Maar ten eerste blijkt dat niet, zodat klanten niet van het risico weten. En google geeft ook geen mogelijkheid dat klanten de oplossingen, die google bij hun clouddienst op de klanten af schuift, kunnen toepassen.

[ShadLink]

Dit lijkt me meer een inherent probleem van altijd ingelogd blijven, niet zozeer een fout van Google (9 van de 10 websites/applicaties hebben dergelijke functies) Natuurlijk moeten oude sessies wel verlopen zodra je daadwerkelijk uitlogt of je wachtwoord wijzigt.

[JanRekenaar]

Google doet anders zijn stinkende best om je altijd - zonder dat je hier actief op gewezen bent - ingelogd te houden. Lijkt me minimaal geen privacy en security by design.

[Frame164]

Als het in de requirements staat dat het zo moet werken is het wel by design. Moeten uitloggen voor privacy en security is kuust niet security/privacy by design. Dat is een workaround.

[JanRekenaar]

Sessies uitloggen na een time-out is absoluut security by design. Het - standaard - niet hebben van een time-out betekent dat Google bewust gekozen heeft voor commerciële voordelen en de security van de gebruiker in dit opzicht minacht.

Dit gaat dus over de risico’s die het niet hebben van session-time-outs met zich meebrengen en is by default niet de beste security keuze en voldoet niet aan security by design principes, zoals benoemd in OWASP (https://cheatsheetseries....nagement_Cheat_Sheet.html)

[Reactie gewijzigd door JanRekenaar op 23 juli 2024 02:51]

[OLED]

Google wijst constant naar andere bedrijven, betalen zelfs mensen om fouten van anderen op te sporen, en publiceren het dan met veel bombarie..

Jammer dat ze niemand betalen om hun eigen fouten op te sporen, dan had dit makkelijk voorkomen kunnen worden

[svennd]

bron ?

Je zult er geen hebben, want ik vermoed dat je over het project van google praat waar ze "alle" populaire software onderzoeken. (https://security.googleblog.com/)

Uiteraard heeft google ook z'n security team voor inhouse, alsook een publiek vulnerability programma https://hackerone.com/google?type=team

Dit lijkt trouwens op een OAuth2 security probleem, dus vermoedelijk niet specifiek voor Google (alleen).

[Loller1]

Het is een verwijzing naar hoe Google nogal vast en los speelt met de regels over beveiligingslekken en hoe die gepubliceerd worden afhankelijk van of het over andere bedrijven gaat of over Google's eigen producten via Project Zero.

Er is een vereiste voor fabrikanten om binnen de 90 dagen (geheel arbitrair uiteraard) een fix te voorzien. Dit is Google's eigen interpretatie van de principes van "coordinated vulnerability disclosure", en zou puur moeten worden gebruikt om te forceren dat andere bedrijven het probleem aandacht geven en oplossen, maar van zodra Google die bevestiging heeft dat er serieus naar gekeken wordt zouden ze gewoon moeten wachten tot het is opgelost. Google gooit echter alles op straat ook al weten ze dat een fix in ontwikkeling of testing is en dus onnodig de veiligheid van gebruikers in gedrang heeft gebracht.

Daar hebben ze een jaar of 2 geleden een overloop periode van 2 weken voor ingevoerd om die kritiek eindelijk aan te spreken voor het geval een oplossing kan uitrollen na die 90 dagen binnen de 2 weken na - en ik quote - "good feedback from other vendors". Die "good feedback" is van verschillende bedrijven die absoluut pist waren met Google's manier van werken over de voorgaande 7 jaar. Ondanks een intern project te zijn (en je dus zou denken dat Google het meeste reports zou krijgen van zichzelf) gaat Project Zero disproportioneel vaak achter Microsoft, Appel en Adobe aan. Sinds 2021 laten ze ook pas een periode van 30 dagen na het releasen van een patch waarin ze de details niet publiceren (maar de 2 weken gaan daar wel vanaf indien gebruikt).

Als het PZ team de nood voelde om een blog te schrijven, is dat vaak over iOS (26) of Windows (24), terwijl Android (11) veel minder geraakt wordt, terwijl ze opnieuw daar juist intern veel meer kennis van zaken van zouden moeten hebben. Het feit dat Google er ook nogal graag een marketing stunt van maakt als het over hun competitie gaat zegt ook al meer dan genoeg.

Tot 2021 zijn er 6 uitzonderingen geweest op de deadline. 4 daarvan waren voor problemen die (onder andere) Google zelf ook aangingen (conflict of intrest, much?). De andere waren een bug in XNU waar Apple 55 dagen extra voor kreeg bovenop de 90 dagen, en een bug in Windows waar Google in eerste instantie een deadline van 7 dagen voor gaf, maar dat later verlengde naar 23 dagen.

[The Zep Man]

Er is een vereiste voor fabrikanten om binnen de 90 dagen (geheel arbitrair uiteraard) een fix te voorzien. Dit is Google's eigen interpretatie van de principes van "coordinated vulnerability disclosure", en zou puur moeten worden gebruikt om te forceren dat andere bedrijven het probleem aandacht geven en oplossen, maar van zodra Google die bevestiging heeft dat er serieus naar gekeken wordt zouden ze gewoon moeten wachten tot het is opgelost. Google gooit echter alles op straat ook al weten ze dat een fix in ontwikkeling of testing is en dus onnodig de veiligheid van gebruikers in gedrang heeft gebracht.

Als Google het lek niet vindt, dan kan een ander het vinden en direct of niet publiceren. Als je als fabrikant een kwetsbaarheid niet binnen 90 dagen kan oplossen, dan heb je twee kwetsbaarheden: een beveiligingsprobleem in je product of dienst, en een fout (in ontwerp of proces) waardoor je kwetsbaarheden niet op tijd op kan lossen.

Let op dat Google (net als andere partijen) ook een kwetsbaarheid direct zou kunnen (en mogen) publiceren.

Ondanks een intern project te zijn (en je dus zou denken dat Google het meeste reports zou krijgen van zichzelf) gaat Project Zero disproportioneel vaak achter Microsoft, Appel en Adobe aan.

Let op dat Google (net als andere partijen) vrij is om te bepalen voor welke producten kwetsbaarheden gezocht worden. Andere partijen zijn ook vrij om kwetsbaarheden in de producten van Google te vinden.

Als het PZ team de nood voelde om een blog te schrijven, is dat vaak over iOS (26) of Windows (24), terwijl Android (11) veel minder geraakt wordt, terwijl ze opnieuw daar juist intern veel meer kennis van zaken van zouden moeten hebben. Het feit dat Google er ook nogal graag een marketing stunt van maakt als het over hun competitie gaat zegt ook al meer dan genoeg.

Als dat zo is, waarom onderzoeken Apple en Microsoft dan niet Android en publiceren ze dat op eenzelfde manier?

Er is hier een stukje DARVO gaande. Google vindt vrijwillig fouten in de producten van derde partijen waar ze afhankelijk van zijn. Het is aan derde partijen om adequaat daarop te reageren.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 02:51]

[Aldy]

Let op dat Google (net als andere partijen) ook een kwetsbaarheid direct zou kunnen (en mogen) publiceren.

Zelf vind ik het netter om een bedrijf de kans te geven om binnen 90 dagen het lek te dichten en pas na 90 dagen te publiceren. Is het lek dicht, dan niets aan de hand, staat het lek nog wagenwijd open, dan weet iedereen dat het bedrijf niet in staat is om het lek te dichten.
Naar mijn mening gaan bij direct publiceren een heleboel kwaadwillende over tot het proberen om misbruik te maken van zo'n lek.

[Argantonis]

Nee dit is geen algemeen OAuth2 probleem, dit gaat om de implementatie van Google zelf. Anders zou nu ook echt het halve internet stuk zijn.

[djwice]

Er is een consultant, met veel GWT ervaring, die bij verschillende bedrijven in Nederland een vergelijkbare sessie vernieuwingssysteem heeft geïmplementeerd.

Mocht je bij een bedrijf werken waar de OAuth laag deels door een GWT specialist is geïmplementeerd, check dan ff je code.

[Reactie gewijzigd door djwice op 23 juli 2024 02:51]

[Argantonis]

Nope, ik heb de OAuth2 laag zelf geïmplementeerd, nouja het is geen homebrew maar op basis van Spring libraries.

[kwetterpletter]

Wordt GWT nog gebruikt? Of hebben we het over legacy spul?

[djwice]

Legacy, de meeste zijn zelfs van Java naar .net gewisseld om een goed argument te hebben om van de legacy en de afhankelijkheid van de bestaande consultantsrelatie af te komen.

[kwetterpletter]

Interessant, ik heb in een grijs verleden ook veel met GWT gedaan.
Er is wel iets fout met management als je zulke argumenten moet fabriceren.

[Vaevictis_]

Klopt er is ook exploit voor Microsoft account werkt ook met sessiecookie. Op yt staat een how to. Best wel eenvoudig.

[djwice]

Werkt dat ook als je na 24h 2FA vereist en de token ouder dan 24h is?

[Reactie gewijzigd door djwice op 23 juli 2024 02:51]

[jerisson]

Dat zijn dan issues waar Google de ontwikkelaar 90 dagen de tijd geeft om ze te fixen. Pas als die 90 dagen om zijn worden de details gepubliceerd. Dat in de hoop de ontwikkelaar ertoe aan te zetten de bug effectief te fixen. Dit alles valt onder het Google Zero Project.

Ik vind het nogal redelijk kortzichtig om hier nu aan te nemen dat ze niemand zouden betalen om hun eigen fouten op te sporen. Mensen foutopsporing laten doen geeft geen garantie dat alle bugs er uit zijn. Daarbij is het vaak net goed dat een extern iemand ernaar kijkt, zoals onder andere bij Zero gebeurt en hier nu ook gebeurd is, omdat er dan vanuit perspectief naar de software gekeken wordt (andere aanpak, insteek, ...)

[kodak]

Het is op zijn minst opvallend dat Google nog niets merkbaars opgelost of bekend gemaakt heeft. Hun houding naar andere bedrijven is dat ze een deadline van 7 dagen toepassen als ze een ernstig beveiligingsprobleem vinden die al door malware in gebruik is. Met mogelijk 3 dagen extra.

Dagen voor 21 november lijkt Google al vragen te hebben gekregen. Alleen geeft het nieuws niet aan wat precies de reacties waren, terwijl er kennelijk wel contact was.

De houding van google kan zijn dat ze het prima vinden dat researchers en media dit probleem bekend maken terwijl ze zelf nog geen duidelijke patch hebben uitgebracht. Dat is namelijk ook wat ze accpteren bij andere bedrijven: geen patch, dan na een aantal dagen het risico bekend maken. Als klant heb je dan in ieder geval de 'keuze' of je dit nog acceptabel lijkt.

Het grootste probleem is niet slechts dat klanten risico lopen maar ook zwaar afhankelijk van google zijn. Google hoeft niets op te lossen en de klanten 'accepteren' dat. Ik weet niet hoeveel scholen of bedrijven hier gebruik van maken, maar de vorige keer dat bleek dat google niet aan de eisen voldeed om persoonsgegevens te beschermen werd er flink de tijd genomen om zichzelf en google gelegenheid te geven risico met andermans persoonlijke gegevens en dus leven te nemen.

[achondar]

Toch wel en serieus issue. Vraag me dan af of dit browser onafhankelijk is en het in de browser gefixed worden. Of dit aan de googles backend zit.

[Xsion]

ook wel ironisch omdat Google token binding zo'n beetje de nek om heeft gedraait door browser support te stoppen.

[SvenHe]

Speelt dit niet als je een andere browser op chromium basis gebruikt?

[m4ikel]

Dat is gewoon een feature by design, Google heeft namelijk de mogelijkheid om ingelogde sessies handmatig te beëindigen (dit gebeurd bij een password reset niet automatisch). Idem voor Netflix, Videoland, etc. (logged in devices, support linkje: https://support.google.com/accounts/answer/3067630), anders zou je op 10 devices opnieuw moeten inloggen als je je wachtwoord bent vergeten.

Edit: Steker nog, dan zou je als gebruiker geen invloed meer hebben als een hacker toegang krijgt tot je account, je bent dan namelijk direct de volledige toegang kwijt. Zoals benoemd: feature by design, not a bug.

Het staat gewoon letterlijk uitgelegd:

What is a session?

In some cases, you might see sessions instead of individual devices. A session is a period of time during which you’re signed in to our Google Account from a browser, app, or service on the device. It’s normal to have multiple sessions on the same device.

----

For your security, the page will display each session, to allow you to review its details and sign out of it if you’re not sure it’s yours.

Kortom: Een wachtwoord reset bij een compromised account is niet voldoende. Je moet écht alle logged in sessies killen (dat zou iets duidelijker benoemd moeten worden) (en die mogelijkheid is er gewoon, en zal vast door de support afdeling van Google worden aangeraden (zeker bij high profile gebruikers)).

[Reactie gewijzigd door m4ikel op 23 juli 2024 02:51]

[closefuture]

Dat is gewoon een feature by design,

Een token kunnen heractiveren die expired is lijkt mij niet "by design".

[R4gnax]

Nee. Dit is niet een 'feature by design.'

Het gaat hier om reeds verlopen sessies incl. sessies die expliciet beëindigd waren, bijv. door handmatig uit te loggen, die alsnog terug leven ingeblazen kunnen worden en gestolen kunnen worden door de wijze waarop Google de sign-in in de Chrome browser gekoppeld heeft aan de sign-in in hun web-based services.

Hierbij is, als ik alles zo lees, wss. sprake van een refresh token dat niet mee opgeruimd wordt als een gebruiker expliciet uitlogt; en waar geen verlooptijd op zit. Deze kan dan dus altijd gebruikt worden om nieuwe access tokens te krijgen. zolang het refresh token geldig blijft.

OAuth schrijft vziw voor dat refresh tokens single-use horen te zijn. Zodra je deze gebruikt om een nieuw access token te verkrijgen, hoor je daarbij ook een nieuw refresh token te krijgen en moet het oude verlopen.

Maar dat lijkt hier dus niet het geval te zijn. Zodra een malafide partij het betreffende token eenmaal gestolen heeft kan deze datzelfde token keer, over keer, over keer gebruiken om middels Google's 'MultiLogin' endpoint nieuwe access token credentials op te lepelen. Behalve waar een legitieme gebruiker het wachtwoord op de account wijzigt. Dan kan het gestolen refresh token nog maar één maal gebruikt worden.

Dit geeft eigenlijk aan dat Google wss. een systeem gebouwd heeft dat deterministisch stabiele refresh tokens genereert. Tokens die als je ze hergenereert hetzelfde blijven, zolang de onderliggende data waarop de tokens gebaseerd zijn niet wijzigt. (Bijv. dus de bij Google bekende hash v/h account wachtwoord.)

Hopelijk hoef ik niet uit te leggen waarom dat een erg slecht idee is?
(Nou ja-- deze security vulnerability en exploit demonstreren dat eigenlijk al perfect...)

En de kers op de taart is dus dat als een gebruiker expliciet uit logt, het token gewoon geldig blijft en niet mee opgeruimd wordt. Je bent dus uitgelogd, maar eigenlijk via een achterdeur nog gewoon ingelogd.


...
Als dit allemaal zo klopt, dan gaan er een paar mensen hun baan verliezen, gok ik zo...

[Reactie gewijzigd door R4gnax op 23 juli 2024 02:51]