Exploiting Undocumented API to Regenerate Google Service Cookies
cloudsek.comI believe this is the same thing that was discussed 12 days ago: https://news.ycombinator.com/item?id=38806650
Thanks! Macroexpanded:
Malware abuses Google OAuth endpoint to 'revive' cookies, hijack accounts - https://news.ycombinator.com/item?id=38806650 - Dec 2023 (102 comments)
I've had a hard time with this one, not having time to dig in:
1. Why does the article describe the technique as persisting through password changes, and then ends by recommending a password change?
(answer: "Changing the password alone may not be sufficient. The exploit allows the regeneration of authentication cookies even after a password reset, but only once. To fully secure the account, users should log out of all sessions and revoke any suspicious connections.")
2. Was this a flub on Google's end? How does this even happen? Was the multilogin API not checking revocation like all other Google APIs or what?
3. Is it conspiratorial to say maybe this was intentional, or intentionally not fixed here?
I'd seen speculation that this was used as part of some sort of account recovery flow, where those invalid sessions/tokens might be a useful signal. But I can't imagine why such a feature would re-validate those tokens.
As the linked article says it is used by Chrome's login feature to sync cookie state (which expires faster?) and browser state (which people expect to be permanently logged in - even through password resets?).
>Changing the password alone may not be sufficient. The exploit allows the regeneration of authentication cookies even after a password reset, but only once. To fully secure the account, users should log out of all sessions and revoke any suspicious connections.
TL/DR: Change password and log out of all sessions.
> The feature started Booming
What is “Booming”? Is the capitalisation intended?
Does anyone know of other attacks of undocumented APIs or commands?