10 ms·
Malware abuses Google OAuth endpoint to 'revive' cookies, hijack accounts
- rolph 3y agozombie session cookies https://www.infostealers.com/article/lumma-malware-can-allegedly-restore-expired-google-auth-cookies/ https://www.infostealers.com/article/lumma-malware-can-alleg...
- ThePowerOfFuet 3y agoStraight to the source: https://www.bleepingcomputer.com/news/security/malware-dev-says-they-can-revive-expired-google-auth-cookies/ https://www.bleepingcomputer.com/news/security/malware-dev-s...
- tyoma 3y agoSeems bad that the cookies are still valid after password rotation. Relatedly, is this another instance of HN serving as de-facto Google tech support/customer service?
- wannacboatmovie 3y agoYou act as if it's a bug, not an intentional feature - so Google can continue to track you in perpetuity.
- kevin_nisbet 3y agoI doubt google needs to use this as a feature for tracking. 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.
- ksjskskskkk 3y agologing in serves as giving them authorization to track you under jurisdiction where they cannot just track you by any means available
- tekla 3y agoGive evidence.
- throwaway892238 3y agoIt's not just bad, it's a fundamental failure of security. The effect is the same as a password that can't be changed. It might still be possible for users to manually delete active sessions in some Google account management page, but nobody in the world would expect they'd need to do that after changing their password.
- kevin_nisbet 3y agoYea, I equate it to part of security theater. 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.
- groestl 3y ago> So it didn't matter how many times we rotated our secrets I'm confused, did you rotate your certs or your secrets?
- charcircuit 3y agoThe private key of a cert is a secret that is not reused between certs.
- groestl 3y agoSays who?
- comprambler 3y ago
- hsbauauvhabzb 3y agoWhy? 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.
- skybrian 3y agoIt's bad because when someone suspects unauthorized access to their account, the first thing anyone recommends is to change your password. If the old cookies keep working, changing your password doesn't help.
- hsbauauvhabzb 3y agoI agree - but it should be an option, rather than permanent.
- Zamicol 3y agoSo that's how they address the state issue. They just ignore the problem! I always wondered how they addressed the state problem of cookie bearer tokens.
- uxp8u61q 3y agoThe easy and widespread solution to this issue is simply to ask the user if they would like to log out their other devices when they change their password.
- newZWhoDis 3y agoLTT found out the hard way, their attacker had a session token for an employee and changing everyone’s passwords didn’t lock the attacker out.
- Adverblessly 3y agoI've hacked into your account and changed your password. Should all your cookies mean nothing for when you try to regain access to your account? Similarly, should knowledge if your old password contribute nothing towards allowing you back into your account? 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?
- LelouBil 3y agoDiscord does this, if you change your password it invalidates your Authentication JWT
- anticensor 3y agoDiscord user tokens are not JWT: https://user-images.githubusercontent.com/34555296/120932740-4ca47480-c6f7-11eb-9270-6fb3fbbd856c.png https://user-images.githubusercontent.com/34555296/120932740... Unless your Discord server is actually a spacebar server, in which case they are JWT: https://github.com/spacebarchat/server/blob/master/src/util/util/Token.ts https://github.com/spacebarchat/server/blob/master/src/util/...
- LelouBil 3y agoOh, I didn't look closely and thought it matched (because of the dots) but yeah it doesn't start with "ey". Thanks for the information, it's good to know that the token contains the user id inside of it.
- agilob 3y ago[flagged]
- deleted 3y ago[deleted]
- elric 3y agoGiven how many times I've heard of people being locked out of their Google accounts, and are only able to regain access because they're still logged in on some rarely used device, I imagine that Google would lose a bunch of users if they suddenly started to expire those cookies.
- kevin_b_er 3y agoThey are already expired. That's the problem.
- fbdab103 3y agoI deliberately keep around an old Android phone in the event disaster strikes there is a teeny chance that logged in device might save me. 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.
- Erratic6576 3y agoBack in the 2000’s, we were dreaming of what would come next from Google. Then, in the 2010’s, we started to wonder what would be discontinued. Now, in 2020’s, we dread being locked out of Google accounts. I closed mine during the lockdown. My school cancelled my huge Cryptomator backup on Google. Now, work provides me with one but I can no longer rely on Google for anything crucial.
- ThatMedicIsASpy 3y agoI moved away a while ago. The only thing I still use would be youtube playlists. But even those are trash since they just say we've removed some because of whatever. Thanks I guess I would like to know which song you threw away! Now I pay 1€ a month for mail.
- sircastor 3y agoI have been slowly migrating/backing up everything related to my Google account. I’m just not confident that the ghost in the machine won’t decide randomly one day I’m not worthy of continued access. In another light, it’s a reminder that Google doesn’t really think of these accounts as ours, but theirs.
- rezonant 3y agoX for Doubt. There's almost no details that are useful in this article, and in this case, the authors indicating Google isn't doing anything about it is likely because this isn't actually true. 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-abuses-google-oauth-endpoint-to-revive-cookies-hijack-accounts/ https://www.bleepingcomputer.com/news/security/malware-abuse... which is more technical.
- deleted 3y ago[deleted]
- 8organicbits 3y agoI generally believe it. Google's security team has been lax on cookie security. I reported an issue earlier this year about non-expiring session cookies; they said it was previously reported in 2019. The bug remains [1]. Sadly other Google projects use this code... 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/issues/63#issuecomment-1684098874 https://github.com/googleapis/nodejs-firestore-session/issue...
- londons_explore 3y agoAm I the only one who wants non-expiring sessions. 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.
- 3y ago
- candiddevmike 3y agoThis is doubly bad for Google Cloud, as you can't use it without Google accounts. I'm not sure if it makes sense to remove Sign in with Google yet, though I'm not sure how much I can trust Google for delegating user auth now...
- motohagiography 3y agoInterpreting that the basic problem is limited to a propriatary OAuth2 extension feature of Chrome designed by google to support google services. 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.
- samarthr1 3y agoIs it not the inverse? (With a refresh token lasting longer than the access token?
- motohagiography 3y agoA possible problem would be the refresh lasting longer than the access and remaining unexpired, instead of expiring at the same time - but tbh it's unclear to me whether it is the problem as described.
- usr1106 3y agoIf this is a propriatary extension, does that mean as a Firefox user I am safe?
- dwaite 3y agoIn Google's sort of environments, access tokens have to be interpreted by the world (e.g. a zillion geographically distributed Google nodes), so it makes sense for them to be self-contained bundles of authorization policy decisions and quick-need attributes, with a time limit. This is the sort of thing that RFC 9068 was made for. 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).
- Sparkyte 3y agoYikes! My life has always told me nothing is secure.
- shadowgovt 3y agoMultilogin continues to be the gift that keeps on giving for Google. 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.
- robocat 3y agoPresumably cookies are "stolen" from Chrome by malware running under Windows. 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).
- DeathArrow 3y agoIt's better to not rely on Google for anything important.
- ademarre 3y agoThis would be a better link; the blog post on which the Bleeping Computer article is primarily based. They refer to it but never link to it: https://www.cloudsek.com/blog/compromising-google-accounts-malwares-exploiting-undocumented-oauth2-functionality-for-session-hijacking https://www.cloudsek.com/blog/compromising-google-accounts-m...
- HackerThemAll 3y agoAt the same time Google requires employees to log in (including touching U2F key) every single day, invalidating all sessions. 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.
- gcr 3y agoI don’t think that’s correct. Workspace admins can set session lengths here[1] for web and here[2] for chrome. 1: https://support.google.com/a/answer/7576830?product_name=UnuFlow&visit_id=638396243259469132-981952257&rd=1&src=supportwidget0#zippy=%2Cmobile-devices%2Cchromeos-specific-settings https://support.google.com/a/answer/7576830?product_name=Unu... 2: https://support.google.com/chrome/a/answer/2657289?sjid=9184403348473680818-NA#session_length_limit&zippy=%2Cmaximum-user-session-length https://support.google.com/chrome/a/answer/2657289?sjid=9184...
- HackerThemAll 3y agoI'm talking about Gmail users, not Workspace users. It is hopeless for them.