Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security

Google Password Resets Not Enough To Stop These Info-Stealing Malware Strains (theregister.com) 13

Security researchers say info-stealing malware can still access victims' compromised Google accounts even after passwords have been changed. From a report: A zero-day exploit of Google account security was first teased by a cybercriminal known as "PRISMA" in October 2023, boasting that the technique could be used to log back into a victim's account even after the password is changed. It can also be used to generate new session tokens to regain access to victims' emails, cloud storage, and more as necessary. Since then, developers of infostealer malware -- primarily targeting Windows, it seems -- have steadily implemented the exploit in their code. The total number of known malware families that abuse the vulnerability stands at six, including Lumma and Rhadamanthys, while Eternity Stealer is also working on an update to release in the near future.

Eggheads at CloudSEK say they found the root of the exploit to be in the undocumented Google OAuth endpoint "MultiLogin." The exploit revolves around stealing victims' session tokens. That is to say, malware first infects a person's PC -- typically via a malicious spam or a dodgy download, etc -- and then scours the machine for, among other things, web browser session cookies that can be used to log into accounts.

This discussion has been archived. No new comments can be posted.

Google Password Resets Not Enough To Stop These Info-Stealing Malware Strains

Comments Filter:
  • by Forty Two Tenfold ( 1134125 ) on Tuesday January 02, 2024 @04:00PM (#64125657)
    It doesn't even conform to RFC 822 e.g. regarding the multiple FROM headers. It needs to die finally.
  • by NotEmmanuelGoldstein ( 6423622 ) on Tuesday January 02, 2024 @04:35PM (#64125775)

    ... used to generate new session tokens ...

    That sounds like a obvious flaw: Using an old session token to demand a new session token. A bit like using a photo of Donald Trump to demand a new passport.

    ... scours the machine for ...

    That sounds like 2 problems: 1) The always logged-in philosophy means there's always a valid session cookie to steal; 2) The session cookie is not stored in an encrypted form.

    • by Talchas ( 954795 )
      In general, the ability to maintain access (at least up to some expiration date longer than would otherwise be available) is the entire point of a session cookie - you don't need to log in repeatedly so long as you are still "there", similar to a screen saver password / lock on idle. And there is no possible way for anything to be stored in a relevantly encrypted form barring a setup where you do not actually control your computer (like iOS) combined with the web browser not being the compromised component
    • That sounds like a obvious flaw: Using an old session token to demand a new session token.

      This seems fine to me. It's like using the old password in order to set a new password. But the new session token should invalidate all other session tokens. And therefore the server should check every request for an invalidated token.

      2) The session cookie is not stored in an encrypted form.

      One of the reasons I do not use Chromium is that it does not have a master password.

  • by GoGoGadgetWhiskey ( 4556297 ) on Tuesday January 02, 2024 @05:22PM (#64125943)
    Whatever happened to the advice we used to get: Change your password AND revoke all active sessions. This (e.g. Gmail): https://support.google.com/mai... [google.com]
    • Our corporate masters decided that having "sessions" - logging out when we had no reason to be logged in, didn't give them enough control, so made it impossible for as many people as they could.

If all else fails, lower your standards.

Working...