Malware abuses Google OAuth endpoint to 'revive' cookies, hijack accounts
bleepingcomputer.com
bleepingcomputer.com
If the Google machine decides to cull me, probably nothing I can do, but it costs me nothing to keep it sitting in a drawer.
Now I pay 1€ a month for mail.
In another light, it’s a reminder that Google doesn’t really think of these accounts as ours, but theirs.
Edit:also, how do you replicate access to email/calendars across devices? (smartphones/PC)
If I wanted to host my own I wouldn't ask about providers...
Email these days is about much more than just email. Calendar integration and sync between devices that lets you access email on said devices as well as resiliency one would want for an essential service mean just "hosting your own" is definitely not trivial.
Then there is antispam etc.
Email is just so sticky, it is really hard to make the switch, but I know that it just takes some butterfly wings to upset the blackbox.
For a number of close family members Google has variously refused to accept valid recovery emails, valid recovery codes, and valid backup phone numbers in order to regain account access.
Despite how ridiculous it is from a consistency and security perspective, your MFA- or backup contact- enrolled phone number with SMS is still essentially Google’s gold standard for determining rightful access to an account.
Their auth and password reset processes are constantly changing and they have several steps that are automatically adaptive.
The only foolproof ways I’m aware of to always retain access to your Google account is to enroll in Advanced Protection, and/or to use a paid Google Workspace account.
Advanced protection is a good pointer. Seems like losing the hardware token device can be a disaster?
On the other hand giving a service money is dangerous. They would be making money from you which means stricter checks. I'm still semi banned on Github because they had my card with Russian billing address (for sponsoring) when Putler attacked Ukraine. Good I didn't pay for anything Google.
If you only have one, yes. But I'd recommend:
* Get three tokens
* Keep one on you, one at home, and one somewhere else
* Maintain a list of every site you've registered your tokens with.
* If you lose a token, or one breaks, unenroll it from all those sites, get a new token, and enroll the new token. Do this urgently.
This is with 2FA and a passkey, and multiple logged in devices. There’s a lot of idiocy going on there, I wouldn’t trust them with a single thing for any reason whatsoever.
- buy a domain name to never have the same issue
- select a new service
- setup forward from gmail to the new service.
- start using new mail
- wait multiple years and Tadaa ^^
Bonus: if you loose access the forward will continue :).
I was screwed as all of my PCs/laptops, Servers, tablets, etc...burned up or were flooded by fire dept. I found my phone 8 hours later on the basement floor where it had been submerged in 8" of water from the fire dept. Miraculously it was dead and just wanted to be charged. (Samsung s22, fwiw). I'm typing on that now and still have access to everything! Phew.... take your personal DR seriously.
Good thing google has a high quality help desk to report bugs /s
Makes sense really.
Anecdotally, my Google account's password has never been in any dump (password manager, very long random alphanumeric, changes every 6 months) and I too deal with these annoying prompts.
Despite having access to the password, the recovery email account and an active session, I could not activate a new session.
It didn’t make sense, not that it matters when google refused to have a help desk or meaningful way to report bugs.
(Curious how easy it was for me to forget that it's something I can turn off, once I turned it on.)
I have a client who tries to share one Google / Gmail Inbox account between users internationally and Google does not like that at all!
Google constantly requires verification for logins!
May be you/your client needs a proper workflow. May be you need to run some security company/email service at the level of Google to see.
It's a weird problem. Can't log in to my account from unknown mobile but works just fine on an unknown PC.
So frustrating.
And the answer should never be just "sorry, we can't confirm your identity right now". If I pass every challenge Google throws at me, I should be let into the account, period. If they have more, sure, whatever, let's play the game, but if I did everything right and still can't get in, that's a broken authentication system.
If that is your argument then it is their service. They can decide how to offer it. Services like this are designed for majority - and a majority are happy. If you don't prefer then you can find alternate services. Market is wide open.
lol
Relatedly, is this another instance of HN serving as de-facto Google tech support/customer service?
I worked on a product that rotated the TLS certificate frequently. And it actually showed up a number of times in questions from customers or vendor security questionnaires about whether we rotated the certificates and how that happened.
But what we were never asked was whether old certificates were cancelled... which in that system they were not. So it didn't matter how many times we rotated our secrets, any old or leaked secret in a backup or elsewhere was still completely valid. But we had met the security theater that those rotations happened.
So I expect what you do, is that changing a password would cancel all sessions using that credential. But that's kind of hard to do, so we'll just leave that side buggy and untested, because we did the important part of the theater that said we can change passwords.
I'm confused, did you rotate your certs or your secrets?
Edit: relevant, especially flow2k's answer, which explains why this is _not_ just security theater https://security.stackexchange.com/questions/85963/what-is-t...
This does still leave the problem of the old certs being valid though. This only makes sense as a security practice if the certs are short-lived, which theirs apparently weren't. If the certs live much longer than the rotation window, this really is just security theatre.
I do think thaumasiotes has a point and GP's company probably misinterpreted the rotation requirements and short lifespans were implied in the requirement.
That's very true.
> and GP's company probably misinterpreted the rotation requirements and short lifespans were implied in the requirement.
Or GP didn't know that the company was indeed using short expiration times, and somehow confused it with certificate revocation (called "cancelled" in the post).
Huh? You haven't "rotated" your credentials until the old ones are invalidated. Adding new credentials isn't a rotation.
Even if we argued that this was for tracking purposes, google could keep the cookie for tracking and just deny access to the services until a login flow was completed.
Im all for terminating sessions if the user wants it, but there are valid reasons to change passwords without knowledge of a breach.
Fwiw, terminating old sessions can be pretty hard in SSO systems and similar, though.
I always wondered how they addressed the state problem of cookie bearer tokens.
Which is more trustworthy, the same device/cookie I've seen logged into the account for the last <duration of retention period>, or some new one that just reset the password?
I won't pretend to understand Google's mechanisms or intentions, nor the workings of this exploit, but surely it is more complicated then simply invalidating all prior info upon password rotation?
Unless your Discord server is actually a spacebar server, in which case they are JWT: https://github.com/spacebarchat/server/blob/master/src/util/...
Thanks for the information, it's good to know that the token contains the user id inside of it.
https://www.cloudsek.com/blog/compromising-google-accounts-m...
Google engineers weren't keen to implement the feature in the first place, and it's been kind of an unlimited well of headaches, confusion, and user issues ever since.
https://www.infostealers.com/article/lumma-malware-can-alleg...
https://www.bleepingcomputer.com/news/security/malware-dev-s...
It sounds related to an OAuth2 footgun around applying the expiry to refresh_tokens in addition to the access_token, which has an explicit expiry. Whereas the refresh_token expiry is only implied as something less than the access_token - if any.
Exchanging an access token for a new one using a refresh token is a seldomly done operation (in comparison), with whatever amount of business logic that the company needs, evaluated in a more centralized environment belonging to a single business unit (e.g. the auth team).
So you'd expect access tokens to have some shorter-lived (6-60 minute) fixed lifetime to an expiry instant and to be non-revocable on their own, while refresh tokens are opaque to any software other than the central OAuth service. They might be good for a day or year, or each refresh may be a risk calculation based on signals received from elsewhere (such as a password change event).
In the case of a password rotation or signal from other parties that the password has been compromised, you would expect that the current access token would continue to work for some short period of time, after which the refresh would result in a failure (typically sending the user back to a login page in their browser).
That leaves threads to pull like the ones implied in the exploit. I've seen refresh tokens set to 6mo to a year in enterprise environments where they were reducing the number of 2FA logins required.
We're all speculating on the actual exploit still, I can see how something like this happened. Federating logins federates risk and aggregates it into something users can't reason about and is difficult to unwind. It's just the cost of progress.
What is a service here? A bearer token is meant solely for the AS. Revocation of a bearer token only means something in the context of the AS.
Now if one wants to build some AS feature to go tell every protected resource "there's an access token good for another 15 minutes - I revoked its bearer token so don't honor that access token" one can build such a thing, but it is going to be some particular custom aspect of the implementation shared between the AS and resource servers.
Since OAuth only really profiled two patterns for interoperability between the two (stateless sharing via JWT, stateful endpoint via introspection service), the only real interoperable approach is to make a introspection call each time you evaluate the access token.
At a massive distributed scale like with someone like Google, such introspection decisions would have to be pushed closer to the nodes as a distributed system itself, which means it becomes eventually consistent. You have to decide whether a complex stateful system is worth it considering natural access token expiry on its own also essentially makes revocation eventually consistent.
So this is schizophrenia - corporation is protected, but casual Gmail users are left to be hacked with no option to set the session expiration anywhere in the account settings.
1: https://support.google.com/a/answer/7576830?product_name=Unu...
2: https://support.google.com/chrome/a/answer/2657289?sjid=9184...
I guess Mac and Android users are potential victims too. As much as I despise post-Wozniak Apple, at least an iPhone is reasonably secure (except from governments).
Of course maybe I'm wrong but short of some more compelling technical details (reply a link if there's a better source), I'm inclined to doubt the characterization of this article.
EDIT: Sibling linked https://www.bleepingcomputer.com/news/security/malware-abuse... which is more technical.
Historically they've been quick to patch things I've reported, so it feels like a decline.
[1] https://github.com/googleapis/nodejs-firestore-session/issue...
My browser cookie store ought to be a good place to store secrets. On Linux it is protected by the user keyring. I believe on windows it is protected by the system secret store which is eventually secured by the user logon password and the TPM.
So why not just let my cookies survive until I explicitly invalidate them by clearing my cookie store, hitting logout, or by changing my account password?
From a security perspective, someone who breaks into my cookie store has access to pretty much any website I use, whether the validity is 1 week or 1 century. Any prepared attacker can take full control of the account in a matter of minutes, so the validity doesn't make much of a difference.
Poorly written backends only check if a user is active during login. So a lingering session remains usable. Imagine an employee is fired, they are angry, their accounts is disabled, but they still have access. In some rare cases sessions for deleted users still work.
You'll see this most often with apps that rely on client side cookie expiration as sessions appear to expire, but they don't.
Personally, I want short sessions on things like my bank account. For stuff like HN, long is great.
Sessions shouldn't live longer on the server than on the client, that's just silly.
The cookie associated with a session should be updated with moderate frequency, and old cookies should be invalidated.
If a particular client doesn't connect for long enough, it should probably have its session revoked.
My life has always told me nothing is secure.