Can the undocumented OAuth MultiLogin Extension be turned off for our WorkPlace domains?

[Robert ECEO Townley]

Google has not done anything about their “Google OAuth MultiLogin” _October_ zero day vulnerability.  Malware exploited weaknesses in Chromium to get credentials and possibly all passwords.  I hope that has truly been fixed.  But the OAuth server side is still being exploited.

Now, over three months later, no less than five threat actor groups are actively exploiting OAuth to resurrect expired cookies and stay logged-on.  

Is there anyway to mitigate?

Can we disable OAuth MultiLogin Extensions for our own organization?   

Limit the ip address subnets our users can try to authenticate from?

Forcing  password changes does nothing  when the hacker has already generated a passkey on their “device” whether a fake iPhone or fake “Windows” or some other instance using the services of  websites such as undetectable.io, MoreLogin.com, or  the hopefully unrelated MultiLogin.com.

Instead of telling each user to goto  accounts.google.com, check devices using each of their google accounts and force logout, can that be scripted?  A script to force password changes, disconnect all devices for all users (except SuperAdmins one at a time) and then force password changes again.   Repeat for each user individually when there are unaccounted for logon successes.  

Robert Townley

Eye Consultants, PC

402-391-1100

[Brian Kim]

OAuth 2.0 tokens are supposed to be revoked upon password change, which you can do with GAM or CSV upload in admin console.

https://support.google.com/a/answer/6328616?hl=en

I have seen Drive for Desktop continue to work after an account password was reset, and sign-in cookies were reset, in which case you can use GAM to manually delete the tokens from the users' accounts.

# Get all users' tokens

gam config auto_batch_min 1 redirect csv ./tokens.csv multiprocess all users print tokens

# Delete all the tokens in the CSV 

gam csv ./tokens.csv gam user "~user" del tokens clientid "~clientId"  

If you are not enforcing 2SV, you should. If you have allowed passwordless sign-in and attackers set up passkeys, you should disable passkeys for now. If you are worried that the attacker may have registered their security key/authenticator apps, you can also use GAM to turn off 2SV as well.

https://github.com/taers232c/GAMADV-XTD3/wiki/Users-Signout-Turnoff2SV#turn-off-2-step-verification

[Robert ECEO Townley]

Thank you.  

Due to a little malware on GitHub, threatPrevention is blocking  raw.githubusercontent.com  in general.  

Slowed down to find out how to place 

https://raw.githubusercontent.com/jay0lee/GAM/master/src/gam-install.sh

on the passList and _actually_ let it through.

--
You received this message because you are subscribed to the Google Groups "GAM for Google Workspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-man...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-manager/6932e7b8-fa64-433a-9b32-417ff58bec32n%40googlegroups.com.