[HN Gopher] Malware abuses Google OAuth endpoint to 'revive' coo...
___________________________________________________________________
Malware abuses Google OAuth endpoint to 'revive' cookies, hijack
accounts
Author : schalkneethling
Score : 73 points
Date : 2023-12-29 16:22 UTC (1 days ago)
(HTM) web link (www.bleepingcomputer.com)
(TXT) w3m dump (www.bleepingcomputer.com)
| rolph wrote:
| zombie session cookies
|
| https://www.infostealers.com/article/lumma-malware-can-alleg...
| ThePowerOfFuet wrote:
| Straight to the source:
|
| https://www.bleepingcomputer.com/news/security/malware-dev-s...
| tyoma wrote:
| Seems 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?
| throwaway892238 wrote:
| It'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 wrote:
| Yea, 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 wrote:
| > So it didn't matter how many times we rotated our secrets
|
| I'm confused, did you rotate your certs or your secrets?
| charcircuit wrote:
| The private key of a cert is a secret that is not reused
| between certs.
| groestl wrote:
| Says who?
| comprambler wrote:
| The private key is definitely reused between certs unless
| you go through a process of rekeying which requires a new
| CSR.
| franga2000 wrote:
| Can you do one without the other? The public key is
| derived from the secret/private key, so changing one
| means also changing the other...
| groestl wrote:
| But a (public key) certificate is not a public key. A
| cert is a public key A (to private key a), signed by
| another key b, of which public key B is known. To rotate
| a cert means resigning the public key A (which is still
| derived from the same private key a).
|
| Edit: relevant, especially flow2k's answer, which
| explains why this is _not_ just security theater
| https://security.stackexchange.com/questions/85963/what-
| is-t...
| franga2000 wrote:
| Ah, so basically just renewing before it's due, that
| makes sense. For some reason it didn't occur to me that
| rotate could mean that too.
|
| 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.
| groestl wrote:
| > If the certs live much longer than the rotation window,
| this really is just security theatre.
|
| 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).
| thaumasiotes wrote:
| > 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.
|
| Huh? You haven't "rotated" your credentials until the old
| ones are invalidated. Adding new credentials isn't a
| rotation.
| hanniabu wrote:
| After you change your password I think there's a setting you
| can use to kick off existing connections
| wannacboatmovie wrote:
| You act as if it's a bug, not an intentional feature - so
| Google can continue to track you in perpetuity.
| kevin_nisbet wrote:
| I 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 wrote:
| loging in serves as giving them authorization to track you
| under jurisdiction where they cannot just track you by any
| means available
| hsbauauvhabzb wrote:
| Why?
|
| 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 wrote:
| It'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.
| elric wrote:
| Given 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 wrote:
| They are already expired. That's the problem.
| fbdab103 wrote:
| I 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 wrote:
| Back 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.
| skybrian wrote:
| Printing out backup codes [1] and keeping them with your
| important papers is probably a good idea too.
|
| [1] https://support.google.com/accounts/answer/1187538
| franga2000 wrote:
| Could they just...stop locking us out of our accounts? For some
| reason, even knowing the password, being on a device+network
| combination I've used a dozen times before and entering a login
| code generated on an already-logged-in device still isn't
| enough to prove my right to use the account these days...
| hsbauauvhabzb wrote:
| I think there's a functional bug with very early (2006)
| accounts due to MFA or something.
|
| Good thing google has a high quality help desk to report bugs
| /s
| rezonant wrote:
| X 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-abuse...
| which is more technical.
| 8organicbits wrote:
| I 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/issue...
___________________________________________________________________
(page generated 2023-12-30 23:00 UTC)