Google Whistles While OAuth Burns — ‘MultiLogin’ 0-Day is 70+ Days Old – Source: securityboulevard.com

Infostealer scrotes having a field day with unpatched vulnerability.

A zero-day vulnerability, publicly revealed in October, is still unpatched. Google’s implementation of OAuth 2.0 has an undocumented extension that allows malware to steal and reuse account-auth cookies—even if they’ve expired.

And changing your password won’t help. In today’s SB Blogwatch, we wish you a happy new year.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Steamboat copypasta.

What a Mickey Mouse Operation

What’s the craic? Bill Toulas reports—“Malware abuses Google OAuth endpoint to ‘revive’ cookies, hijack accounts”:

“Never received a response”

Multiple information-stealing malware families are abusing an undocumented Google OAuth endpoint named “MultiLogin” to restore expired authentication cookies and log into users’ accounts. … The exploit was first revealed by a threat actor named PRISMA on October 20, 2023, [saying] they discovered a way to restore expired Google authentication cookies.

…

In late November 2023, … two information-stealers, namely Lumma and Rhadamanthys, … claimed they could restore expired Google authentication cookies stolen in attacks. These cookies would allow the cybercriminals to gain unauthorized access to Google accounts. … Since then, numerous other information stealers have adopted the exploit, including Stealc … Medusa … RisePro … and Whitesnake.

…

[We] contacted Google multiple times over a month … but we never received a response. … since Google hasn’t confirmed the abuse of the MultiLogin endpoint, the status of the exploitation and its mitigation efforts remain unclear at this time.

TL;DR? Alon Gal told you so—“The Google 0-day all Infostealer groups are exploiting”:

“Why aren’t Google doing anything?”

Google cookies that don’t expire and work even when the account’s password is changed: Huge advantage for cybercriminals, nothing done by Google.

…

A month ago … we warned that this will cause a shift in cybercrime, and that hackers will be able to infiltrate accounts with ease. … We expect to see this feature implemented by all Infostealer groups until some action is taken by Google. Why aren’t Google doing anything about it?

Horse’s mouth? Pavan Karthick M, Anirudh Batra, Sparsh Kulshrestha and Anirudh Batra—“Malware Exploiting Undocumented OAuth2 Functionality for session hijacking”:

“Even more alarming”

This undocumented MultiLogin endpoint is a critical part of Google’s OAuth system, accepting vectors of account IDs and auth-login tokens. [It] presents an exploitable avenue if mishandled.

…

By reversing the Malware variant, we understood they target Chrome’s token_service table of WebData to extract tokens and account IDs of chrome profiles logged in. This table contains two crucial columns: service (GAIA ID) and encrypted_token. The encrypted tokens are decrypted using an encryption key stored in Chrome’s Local State within the UserData directory.

…

By manipulating the token:GAIA ID pair, [malware] can continuously regenerate cookies for Google services. Even more alarming is the fact that this exploit remains effective even after users have reset their passwords. This persistence in access allows for prolonged and potentially unnoticed exploitation of user accounts and data.

Wait. Pause. Changing your password doesn’t invalidate session cookies? That’s bad. Worse than bad, thinks throwaway892238:

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.

But is this another one of those “theoretical” vulnerabilities? Nope, it happened to u/Adolist already:

Happened to me already, 7 sessions on cloned iPhone, 4 sessions on macOS computers (I don’t own a Mac). All with Google remote desktop installed on main Windows computers version 97+ (never installed it). … All passwords and accounts hijacked.

…

Only thing that stopped it is by logging out on all the sessions individually by going to Google account and seeing everywhere you logged in at, change your password, remove texting cellphone numbers from recovery as 2 factor, … only use 6 digit authentication, then log out of all sessions again that pop up again, … change password again then watch for any new sessions. … Any infiltrated accounts will have “Skip Passwords when Possible” immediately turned on: … Turn it off.

…

At this point, I have begun unplugging my ethernet jack from my computer when not in use. … Stay safe and good luck, it’s a total nightmare.

Sounds complicated. motohagiography illustrates how deep the rabbit hole goes:

The basic problem is limited to a proprietary OAuth2 extension … 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.

…

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. … Federating logins federates risk and aggregates it into something users can’t reason about and is difficult to unwind.

Are you pondering what u/KiTaMiMe’s pondering?

I wonder how many more threat actors will adopt and modify this exploit before Google finally mitigates this issue or patches it?

What have we learned? DeathArrow draws their own conclusion:

It’s better to not rely on Google for anything important.

Meanwhile, u/TheAspiringFarmer considers OAuth harmful:

Just another reminder: SSO is very convenient but also a nightmare waiting to happen.

And Finally:

Since yesterday, this is legal (but arguably it was already fair use)

Previously in And Finally

You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi, @richij or [email protected]. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.

Image sauce: The Walt Disney Company, née Disney Brothers Cartoon Studio (public domain—so suck it, Disney lawyers)