[HN Gopher] Malware abuses Google OAuth endpoint to 'revive' coo...
___________________________________________________________________
Malware abuses Google OAuth endpoint to 'revive' cookies, hijack
accounts
Author : schalkneethling
Score : 217 points
Date : 2023-12-29 16:22 UTC (2 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.
| charcircuit wrote:
| It's technically possible to reuse it, but letsencrypt /
| certbot do not reuse it by default. You have to go out of
| your way and do extra work to reuse a CSR when renewing a
| cert.
| woodruffw wrote:
| The original poster didn't mention LE or anything else
| that uses ACME. It's pretty easy to reuse a key in a
| bespoke PKI setup; the X.509 builder APIs that I've used
| make it trivial. Which doesn't make it a good idea, of
| course.
| 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).
| kevin_nisbet wrote:
| Sorry about the imprecise language, this system rotated
| both together.
| 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
| patmorgan23 wrote:
| You can go into the Google account security portal and expire
| all sessions individually. T
| omnifischer wrote:
| If you change password - all other logins are signed OUT.
| 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
| tekla wrote:
| Give evidence.
| 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.
| hsbauauvhabzb wrote:
| I agree - but it should be an option, rather than
| permanent.
| Zamicol wrote:
| So 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 wrote:
| The 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 wrote:
| LTT 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 wrote:
| I'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 wrote:
| Discord does this, if you change your password it invalidates
| your Authentication JWT
| anticensor wrote:
| Discord user tokens are not JWT: 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/se
| rver/blob/master/src/util/...
| 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.
| ThatMedicIsASpy wrote:
| I 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 1EUR a month for mail.
| sircastor wrote:
| I 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.
| eastbound wrote:
| What spreadsheet tool do you use at work? I put my
| company on a competitor for Gmail, but then we still had
| to open Google accounts for Google Ads and Youtube and
| GDrive. Now I wonder whether I should officially
| subscribe, just for consistency.
| taneq wrote:
| A few years ago I started getting increasingly worried
| about my Gmail account being a single point of failure for
| basically my entire life. Along with Google's evolution
| into an evil empire this prompted me to completely excise
| them from my life. It took a couple of years to transition
| all my less-used accounts to my new email but the peace of
| mind is worth it.
| Roark66 wrote:
| So which email provider would you say is more reliable?
| Self hosting on AWS etc?
|
| Edit:also, how do you replicate access to email/calendars
| across devices? (smartphones/PC)
| idontwantthis wrote:
| If you own the domain then you should still be able to
| use the account even if you get kicked off of a provider.
| swixmix wrote:
| And receiving email at your own server is trivial.
| Erratic6576 wrote:
| For me, it's cheaper and easier to pay someone else
| never_inline wrote:
| I am just following the High Availability principle and
| using both Microsoft and Google equivalents, with most data
| having a local copy anyway.
| 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
| fbdab103 wrote:
| I do have the backup codes, though I read an anecdote from
| someone where Google refused to accept the backup code.
| Because of course they can do that.
|
| 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.
| maccard wrote:
| Can you share that anecdote? That seems absolutely wild
| to me and I've never even heard it suggested before your
| post
| TheNewsIsHere wrote:
| I am not the poster you replied to, but I've dealt with
| this in various forms.
|
| 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.
| throwaway290 wrote:
| Recovery codes saved my ass a few times though.
|
| 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.
| jefftk wrote:
| _> Seems like losing the hardware token device can be a
| disaster?_
|
| 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.
| karlshea wrote:
| I have a paid Workspace account and I can't view my
| payment information on the non-Workspace accounts site
| because they can't "verify it's me".
|
| 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.
| numpad0 wrote:
| ref: https://news.ycombinator.com/item?id=34441697
| Timshel wrote:
| For email best process:
|
| - 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 :).
| idontwantthis wrote:
| Google refused all of mine the time I dropped my phone
| away from home.
| gorlilla wrote:
| I use a pw manager with a key and key file. We just had a
| house fire on xmas eve, and my DR plan of having a laptop in
| the garage with the important bits failed as I had just
| brought the laptop in to look over everything because it was
| so cold outside.
|
| 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.
| 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
| londons_explore wrote:
| I think if they have ever seen your account password in any
| password dump/leak (ie. if you reused the password
| elsewhere), then they effectively prevent password login.
| You have to have another already-active session.
|
| Makes sense really.
| sodality2 wrote:
| It would make more sense to inform the user this, then
| enforce these checks until the user changes it.
|
| 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.
| hsbauauvhabzb wrote:
| In my case, the workflow requires a recovery token which
| was sent to an email account I have access to,
| authenticating with the token results in a security
| error.
|
| 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.
| _zoltan_ wrote:
| With Google One, you get support. And if you use storage
| from them you have google One.
| akkartik wrote:
| Just turn off MFA for Google. I did this during 2023 and
| started sleeping so much better at night.
|
| (Curious how easy it was for me to forget that it's something
| I can turn off, once I turned it on.)
| franga2000 wrote:
| 2FA wasn't turned on for that particular account, Google
| just decided to "double check" one day.
| akkartik wrote:
| Oh interesting. I think I haven't noticed this because
| I'm trying to disconnect from Google lately. These days I
| login on an incognito tab and log out when I'm done. But
| just with a password.
| firecall wrote:
| Yep - even with 2FA off they still like to check.
|
| 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!
| a_dabbler wrote:
| Sounds like they should be doing automatic email
| forwarding or something instead
| jalk wrote:
| That only works for reading emails, not sending/replying
| using the shared account.
| toomuchtodo wrote:
| What happens if passkeys are created for the account on
| everyone's workstation?
| omnifischer wrote:
| This is stupid. You need to do some sort of delegation.
| If some one logins now in USA and 10 min later a login is
| detected from Singapore. And again if US login is
| detected - this will throw any security to bonkers.
|
| 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.
| firebot wrote:
| Uhm. You can't disable this shit.
|
| 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.
| jefftk wrote:
| The issue is account hijacking, and it's a matter of
| tradeoffs: the more relaxed your login process is the more
| unhappy ex-users you'll have losing their accounts to hackers
| (mostly reused passwords getting leaked), while the stricter
| you make it the more unhappy ex-users you'll have losing
| their accounts to lockouts (mostly stale recovery methods).
| franga2000 wrote:
| It's my account that's at risk of hijacking, so I should be
| able to decide. If I opted for no 2FA despite Google
| begging me to turn it on every login, that's my decision.
|
| 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.
| omnifischer wrote:
| > It's my account that's at risk of hijacking, so I
| should be able to decide. If I opted for no 2FA despite
| Google begging me to turn it on every login, that's my
| decision.
|
| 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.
| JeffSnazz wrote:
| > I imagine that Google would lose a bunch of users if they
| suddenly started to expire those cookies
|
| lol
| omnifischer wrote:
| If you have some form of 2FA (like QR code or SMS or U2F-key)
| this will never happen. Some like you are misinformed.
| 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...
| londons_explore wrote:
| Am 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.
| lightedman wrote:
| Are you checking every token and cookie yourself to make
| sure they haven't been hijacked?
| 8organicbits wrote:
| I worry about a couple things. Many apps don't end _other_
| sessions when you log out or change passwords. My example
| above doesn 't handle that.
|
| 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.
| SpaghettiCthulu wrote:
| The problem here is that the cookies don't expire even
| after changing the account password. The account owner must
| manually end each session from the accounts.google.com
| page.
| Dylan16807 wrote:
| Keeping sessions alive is useful, but there are lots of
| ways to improve security without losing much convenience.
|
| 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.
| candiddevmike wrote:
| This 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 wrote:
| Interpreting 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 wrote:
| Is it not the inverse? (With a refresh token lasting longer
| than the access token?
| motohagiography wrote:
| A 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 wrote:
| If this is a propriatary extension, does that mean as a Firefox
| user I am safe?
| dwaite wrote:
| In 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).
| motohagiography wrote:
| Revoking a bearer token for multiple services is an open loop
| problem, where you can't know if all services have revoked it
| unless each service builds in some kind of guarantee signal,
| which would remove a lot of the integration efficiency of
| using bearer tokens in the first place.
|
| 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.
| Sparkyte wrote:
| Yikes!
|
| My life has always told me nothing is secure.
| shadowgovt wrote:
| Multilogin 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 wrote:
| Presumably 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 wrote:
| It's better to not rely on Google for anything important.
| ademarre wrote:
| This 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-m...
| HackerThemAll wrote:
| At 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 wrote:
| I 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=Unu...
|
| 2:
| https://support.google.com/chrome/a/answer/2657289?sjid=9184...
___________________________________________________________________
(page generated 2023-12-31 23:03 UTC)