search

microg / GmsCore

Free implementation of Play Services
https://microg.org
Apache License 2.0
8.51k stars 1.71k forks source link

GmsCore leaking Google account password on login #1567

Closed ghost closed 3 years ago

ghost commented 3 years ago

Describe the bug On login, there are logs with D tag from GmsAuthLoginBrowser shows my Google account mail address and password. It even shows up when adb is run without root, which is not good for security.

Steps to reproduce the behavior:

  1. Open MicroG Settings
  2. Add a Google account
  3. Login with your Google account
  4. Check logcat with adb logcat | grep GmsAuthLoginBrowser

Expected behavior No passwords should be shown in logcat.

System Android Version: R Custom ROM: CAOS v313

Additional context If you have 2FA enabled (SMS code, call, etc) it will show the code too. 09-19 07:55:44.497 6278 6464 D GmsAuthLoginBrowser: JSBridge: getDroidGuardResult: ["nullnull4null9nullnullnullnullnullnullnullnull239405null2"] The login code was 239405

ghost commented 3 years ago

Can confirm , it does this for me as well.

binary-glitch00103011 commented 3 years ago

Can confirm, research is being done to exploit.

AnierinBliss commented 3 years ago

Pretty sus

Razuuu commented 3 years ago

amogus sus

akc3n commented 3 years ago

Thanks @flawedworld for pointing out that this has been around for 7 years.

https://github.com/microg/GmsCore/blob/96cfe2bd9b1798511ea6eb31434049c08b47584a/play-services-core/src/main/java/org/microg/gms/auth/login/LoginActivity.java#L445

Terminator-J commented 3 years ago

... as they said at Chernobyl: "Whoopski."

Dark-Matter7232 commented 3 years ago

NSA connection confirmed.

DraconicNEO commented 3 years ago

Just confirmed this for myself. This is a pretty serious bug, might want to get on this soon.

binary-glitch00103011 commented 3 years ago

I have ethics most could appropriate. However in 3 days, I've worked it out, without a CEH or any formal training. It's trivial so no need to release a white paper, or a whack-a-mole proof-of-concept, I've made my point; but who else, that isn't so forthcoming? My research makes no noteworthy revelations and wouldn't aid in the development of better security, thus I'll refrain.

dimaryaz commented 3 years ago

Hey guys, I have a workaround for everyone: don't give adb access to anyone you don't trust! adb lets you do all kinds of bad things.

Also, if you think leaking the password to adb log is bad, I have even worse news for you. MicroG also sends your password over the internet, to a company known for making money off of users' data: Google!

But seriously: yes, it's a bug, but it's not the end of the world.

binary-glitch00103011 commented 3 years ago

My method requires native exicution but requires no permission hence it would require creative deployment, many methods of which are well known. Your right dimaryaz, remote console is another angle, which could be mitigated with simple settings discipline. Sorry, the word choice is to obfuscate, I fear I spell out the obvious too much as is. Agreed, this is an important bug, and a seurity concern, but far from the end of the world. PCAP logs show that plain passwords aren't exposed so it seems it's local logs only. This without even peeling at code, but now I'm curious, thought I'll likely be quickly out of my depth.

Terminator-J commented 3 years ago

So... just to confirm, does it only post the account credentials to the log during the activity of actually adding a new google account to the device? That's the only time I saw it doing that. It doesn't just repeatedly print it even if you're not modifying/adding more Google accounts, correct? In which case, until microG is updated with the logging removed, the practical security measure for most folks is "format userdata, flash your rom & preferred (minimal!) microG package, factory reset, make sure you're not plugged into the computer, reboot to system for first boot setup, connect to wifi/mobile data and log in to any/all Google accounts you plan to have on the device, reboot so the logcat buffer gets cleared, and THEN you can go about installing things like magisk for root if desired or any 3rd party apps... and then don't add any more Google accounts so it never invokes the microG gmscore account authentication activity again, unless you factory reset and wipe userdata first." ... right?

ghost commented 3 years ago

Hey guys, I have a workaround for everyone: don't give adb access to anyone you don't trust! adb lets you do all kinds of bad things.

Also, if you think leaking the password to adb log is bad, I have even worse news for you. MicroG also sends your password over the internet, to a company known for making money off of users' data: Google!

But seriously: yes, it's a bug, but it's not the end of the world. @dimaryaz

This is a highly nonsensical and unproductive comment. You're comparing something all protected by TLS to a password being stored and logged in plain text, not hashed or anything. ADB is not required to get logs from logcat either. Selecting the bug report option in Developer Options will dump logs.

Edit: There is also a READ_LOGS permission for apps to read logs. This is not strictly an ADB issue.

binary-glitch00103011 commented 3 years ago

Zanthed, you just broke my exploit, I hadn't tested without bug report turned on. It seems without adb, root, bug reports, or extremely old systems (Android 4.1 or older) I can't get logs from another app. So unless someone has something more cleaver than I, it seems being mindful of your settings is sufficient to protect non rooted users. For rooted users; I'm not sure, I don't have a device I'm willing to wipe to test Terminator-J's method, however I'm investigating the viability of it.

[EDIT: I just triggered a permissions dialogue. Selecting 'Allow' fixes my exploit but it's very blantant that wack-a-mole is accessing logs from other apps so...]

TommyTran732 commented 3 years ago

Hey guys, I have a workaround for everyone: don't give adb access to anyone you don't trust! adb lets you do all kinds of bad things.

Also, if you think leaking the password to adb log is bad, I have even worse news for you. MicroG also sends your password over the internet, to a company known for making money off of users' data: Google!

But seriously: yes, it's a bug, but it's not the end of the world.

I am not sure what you are saying. You are literally using a Google account, Google has control over your Google account. It's not "bad" or "good". It's just how it is. It doesn't matter if MicroG sends your Google account password to Google or not, so long as its encrypted during transport.

Storing passwords in plain text in any form, waiting to be extracted, is a big issue however.

ghost commented 3 years ago

Hey guys, I have a workaround for everyone: don't give adb access to anyone you don't trust! adb lets you do all kinds of bad things. Also, if you think leaking the password to adb log is bad, I have even worse news for you. MicroG also sends your password over the internet, to a company known for making money off of users' data: Google! But seriously: yes, it's a bug, but it's not the end of the world.

I am not sure what you are saying. You are literally using a Google account, Google has control over your Google account. It's not "bad" or "good". It's just how it is. It doesn't matter if MicroG sends your Google account password to Google or not, so long as its encrypted during transport.

Storing passwords in plain text in any form, waiting to be extracted, is a big issue however.

Lol they were joking becuase they said but seriously

ghost commented 3 years ago

Lol they were joking becuase they said but seriously @SoupSucker

This isn't the place for jokes. Not productive at all.

fynngodau commented 3 years ago

Regarding the READ_LOGS permission, as this has also recently been a topic regarding Exposure Notification's RPIs, Marvin posted this information to the CCTG chatroom:

I think there is a lot of misconception how privileged permissions work on Android.

  1. Apps must put the permission request directly in a manifest file. Google does not allow apps in Play Store to request privileged permissions without explanation.
  2. Privileged permissions are only granted to apps that are part of the system image and have the permission request in the app version that is on the system image (= updates to system image apps cannot get access to more privileged permissions).
  3. Since Android 4.4, apps that want to get a privileged permission must not only be part of the system image (ROM), but also need to reside in a special folder "priv-app". Manufacturers should not put third-party apps in this folder except if there is a very good reason.
  4. Since Android 8.0, even if a manufacturer would accidentally put an untrusted third-party app in "priv-app", privileged permissions would not be granted as long as the manufacturer does not explicitly allowlist the specific privileged permission to that app through a configuration file in the system image.

The only risk that I personally can see here is that the password is accidentally sent to a vendor through a custom bug report feature, or using the system Bug Report feature to whomever the report is sent.

thestinger commented 3 years ago

Apps aren't supposed to log sensitive data to the system logs primarily due to them often being shared as part of OS bug reports. Many operating systems have a feature for submitting bug report zips which include the system logs. It's a minor issue especially relative to much more serious problems that are present. Should worry about properly enforcing the Play services API security model and transport security rather than this.

READ_LOGS is signature|privileged|development meaning that it can be granted based on having at least one of those 3 things. It's not solely a privileged permission. The development tag means it can be granted dynamically via persistent state normally set via adb shell. It's also relevant in the verified boot threat model since it's stored as persistent state. Platform signature is also another option. The reason for the privileged system requiring explicit whitelisting now is because those may be third party apps and it's undesirable for them to be able to simply add more privileged permissions in updates based on them being a priv-app without explicit approval by the OS.

ghost commented 3 years ago

Thanks @flawedworld for pointing out that this has been around for 7 years.

https://github.com/microg/GmsCore/blob/96cfe2bd9b1798511ea6eb31434049c08b47584a/play-services-core/src/main/java/org/microg/gms/auth/login/LoginActivity.java#L445

Doesn't fix the root of the problem, but it works (kinda)...